# Handling browser differences

**URL:** <https://www.ruby-forum.com/t/handling-browser-differences/118877>\
**Category:** Rails\
**Created:** [October 31, 2007, 9:49pm UTC](https://www.ruby-forum.com/t/handling-browser-differences/118877 "2007-10-31T21:49:02Z")\
**Posts on this page:** 9\
**Page:** 1

<div class="post-metadata">

**Author:** ![avramd](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/aca169/32.png) [@avramd](https://www.ruby-forum.com/u/avramd)\
**Post date:** [October 31, 2007, 9:49pm UTC](https://www.ruby-forum.com/t/handling-browser-differences/118877/1 "2007-10-31T21:49:02Z")

</div>

Hello,

Are there any resources or tutorials on how to handle browser  
differences in Rails? I’m mainly talking about when they render HTML  
and/or CSS differently.

Do people set up groups of partials that are browser specific, and and  
have the template swap in the appropriate partial?

Thanks,  
Avram

---

<div class="post-metadata">

**Author:** ![avramd](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/aca169/32.png) [@avramd](https://www.ruby-forum.com/u/avramd)\
**Post date:** [October 31, 2007, 10:05pm UTC](https://www.ruby-forum.com/t/handling-browser-differences/118877/2 "2007-10-31T22:05:02Z")

</div>

On Oct 31, 1:49 pm, Avram D. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)  
wrote:

> ## Avram
> 
> Posted viahttp://www.ruby-forum.com/.

here’s some good backgrounders about IE (and other browsers too!):

> **[Position Is Everything - Coding and Computing Tips & Tutorials. Learn...](https://www.positioniseverything.net/)**
>
> Coding and Computing Tips & Tutorials. Learn & Build: CSS,JavaScript,HTML,PHP,C++ and MYSQL.

[http://www.quirksmode.org/bugreports/](http://www.quirksmode.org/bugreports/)

> **[search-this.com](http://ww38.search-this.com/2007/06/19/browser-testing-made-easy/)**
>
> This domain may be for sale!

> **[Browser testing CSS and JavaScript | 456 Berea Street](https://www.456bereastreet.com/archive/200702/browser_testing_css_and_javascript/)**
>
> My preferred CSS and JavaScript browser testing order.

---

<div class="post-metadata">

**Author:** ![avramd](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/aca169/32.png) [@avramd](https://www.ruby-forum.com/u/avramd)\
**Post date:** [October 31, 2007, 10:52pm UTC](https://www.ruby-forum.com/t/handling-browser-differences/118877/3 "2007-10-31T22:52:59Z")

</div>

On Oct 31, 2007, at 2:30 PM, Avram D. wrote:

> > [http://www.search-this.com/2007/06/19/browser-testing-made-easy/](http://www.search-this.com/2007/06/19/browser-testing-made-easy/)
> > 
> > [http://www.456bereastreet.com/archive/200702/](http://www.456bereastreet.com/archive/200702/)  
> > browser\_testing\_css\_and\_javascript/
> 
> Thank you, I appreciate those references, they will be helpful.  
> However,  
> what I meant was looking for was good techniques for feeding tweaked  
> output to different browsers - that is, good DRY ways to do it, and  
> avoid having completely separate sets of templates for each type of  
> browser.

If you stick to using valide XHTML and you push all formating and  
styling to CSS, then 99% of the time you don’t need to render HTML  
specific to any browser (there’s some edge cases where you do, but I  
don’t think they’re common).

The challenge is getting your CSS definitions to work universally.  
Most of the time Safari and FireFox agree, and the challenge is  
getting IE to work.

So, the best approach is do your HTML and CSS so that it is “correct”  
and what you’d expect to work for Firefox/Safari, then check it in IE  
(all versions you expect to support) and start applying the CSS hacks  
that are known workarounds for IE. It can a long time to find those  
hacks, that’s the aggravating part of web design.

If you can keep IE in standards mode, it mostly does OK, but you’re  
goinng to have to do some reading about IE CSS hacks. Those sites  
above are a good start.

There’s a few mainstream techniques for telling CSS to apply things  
only to IE. Each has some pros & cons.

This is MS’s official take on it:

> **[About conditional comments (Internet Explorer)](https://learn.microsoft.com/en-us/previous-versions/windows/internet-explorer/ie-developer/compatibility/ms537512(v=vs.85)?redirectedfrom=MSDN)**

however, that method fails when someone has more than one version of  
IE installed in their system. Not too common for sure, and generally  
only affects the browser nerds, but if you have a nerdy site, that’s  
a big deal.

Here’s some other techniques:

> **[CSS Hacks](http://www.webdevout.net/css-hacks#unrecommended)**
>
> Descriptions of the most effective CSS hacks for select web browsers.

– gw

---

<div class="post-metadata">

**Author:** ![avramd](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/aca169/32.png) [@avramd](https://www.ruby-forum.com/u/avramd)\
**Post date:** [October 31, 2007, 10:30pm UTC](https://www.ruby-forum.com/t/handling-browser-differences/118877/4 "2007-10-31T22:30:31Z")

</div>

gene tani wrote:

> On Oct 31, 1:49 pm, Avram D. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)  
> wrote:
> 
> > ## Avram
> > 
> > Posted viahttp://www.ruby-forum.com/.
> 
> here’s some good backgrounders about IE (and other browsers too!):  
> [http://www.positioniseverything.net/](http://www.positioniseverything.net/)  
> [Bug Report - Latest reports](http://www.quirksmode.org/bugreports/)  
> [http://www.search-this.com/2007/06/19/browser-testing-made-easy/](http://www.search-this.com/2007/06/19/browser-testing-made-easy/)
> 
> [Browser testing CSS and JavaScript | 456 Berea Street](http://www.456bereastreet.com/archive/200702/browser_testing_css_and_javascript/)

Thank you, I appreciate those references, they will be helpful. However,  
what I meant was looking for was good techniques for feeding tweaked  
output to different browsers - that is, good DRY ways to do it, and  
avoid having completely separate sets of templates for each type of  
browser.

---

<div class="post-metadata">

**Author:** ![avramd](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/aca169/32.png) [@avramd](https://www.ruby-forum.com/u/avramd)\
**Post date:** [November 1, 2007, 12:06am UTC](https://www.ruby-forum.com/t/handling-browser-differences/118877/5 "2007-11-01T00:06:38Z")

</div>

On Oct 31, 2007, at 3:52 PM, Avram D. wrote:

> Does anyone out there do anything like this?

I have done it where I use scripting logic (i/e/ ruby or whatever  
language is involved) to determine the browser, and then serve CSS  
files tuned for that browser. This approach can be used for serving  
user-selected skins too.

Now, you don’t need to do whole CSS definitions that way as 90% of it  
is all identical, but you can do a base sheet, then based on the  
browser supplement it with ie\_overrides.css, ffx\_overrides,  
opera\_overrides, and even treo\_overrides, etc. Same with skins. A  
base plus the parts that vary per skin.

Depending on how many browsers you do active testing for, or just how  
much of the CSS has to be different, separate files can make sense.  
If you’re really only bothering to test for IE 6+, FFx 1.5+ and  
Safari 2+ and you have a relatively simple design, then really  
there’s likely to be so few differences that the CSS hacks in one  
file is probably best. But if you fine tune for a dozen browsers, or  
you have some tricky stuff that requires quite a lot of overrides,  
then it starts to become easier to compartmentalize IMO and use  
separate files (if you’re clean about the separations), but it’s a  
matter of preference IMO.

– gw

---

<div class="post-metadata">

**Author:** ![avramd](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/aca169/32.png) [@avramd](https://www.ruby-forum.com/u/avramd)\
**Post date:** [October 31, 2007, 11:52pm UTC](https://www.ruby-forum.com/t/handling-browser-differences/118877/6 "2007-10-31T23:52:18Z")

</div>

Ok, cool. Sounds like you’re saying most people don’t code their rails  
apps to pay attention to the browser type and feed customized files. Not  
needing to do that w/ XHMTL make sense, it’s the CSS differences I was  
wondering about.

One thing I was thinking of was pushing the specific CSS elements  
browsers treat differently into a set of stylesheets, and then feed the  
user the stylesheet that goes with his browser.

Does anyone out there do anything like this?

---

<div class="post-metadata">

**Author:** ![avramd](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/aca169/32.png) [@avramd](https://www.ruby-forum.com/u/avramd)\
**Post date:** [November 1, 2007, 2:02am UTC](https://www.ruby-forum.com/t/handling-browser-differences/118877/7 "2007-11-01T02:02:54Z")

</div>

On 31 Oct 2007, at 23:52, Avram D. wrote:

> Does anyone out there do anything like this?

You could use this: [CSS Browser Selector](http://rafael.adm.br/css_browser_selector/)

Best regards

Peter De Berdt

---

<div class="post-metadata">

**Author:** ![avramd](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/aca169/32.png) [@avramd](https://www.ruby-forum.com/u/avramd)\
**Post date:** [November 5, 2007, 2:00pm UTC](https://www.ruby-forum.com/t/handling-browser-differences/118877/8 "2007-11-05T14:00:30Z")

</div>

There are fewer portability problems with HTML 4.01 Strict than with  
XHTML, so that’s what a lot of authors use. These days you have to  
send XHTML as text/html anyway so you don’t get the advantages that  
xhtml could someday provide. When IE8 comes out and has replaced IE7  
and IE6 in the field, then you may be able to generally send xhtml as  
‘xhtml+xml’, permitting use of a real XML parser in the client. Until  
then, XHTML is still handled as tag soup, not XML.

Rails works fine with HTML 4.01 Strict, even though it occasionally  
produces trailing slashes to close tags (like link tags).

See also [http://www.hixie.ch/advocacy/xhtml](http://www.hixie.ch/advocacy/xhtml).

Using a template language other than erb might give us a point of  
control that will allow us to make changes automatically. Such as  
HAML, Markaby, or Malline.

In any case, in the controller and the layout, the hash request.env  
has a name-value pair like this:  
HTTP\_USER\_AGENT =\> ‘Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:  
1.8.1.9) Gecko/20071025 Firefox/2.0.0.9’

For IE it would be different. You can display this string on a test  
page with:

HTTP\_USER\_AGENT: \<%= request.env["HTTP\_USER\_AGENT"] %\>

And figure out how to parse it. Or you could dump it using logger. Then write a method to return the header code you like.

There is also an request.env[“HTTP\_ACCEPT”], which includes weird but  
interesting stuff.

fredistic

---

<div class="post-metadata">

**Author:** ![avramd](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/aca169/32.png) [@avramd](https://www.ruby-forum.com/u/avramd)\
**Post date:** [November 5, 2007, 3:38pm UTC](https://www.ruby-forum.com/t/handling-browser-differences/118877/9 "2007-11-05T15:38:42Z")

</div>

Avram D. wrote:

> Do people set up groups of partials that are browser specific, and and  
> have the template swap in the appropriate partial?
> 
> Thanks,  
> Avram

I feel your pain. I’m relatively new to this game, and am going through  
this with my first major Rails app which is also my first  
commercial-grade website attempt.

On the one hand I have to say that I’ve felt the need for something like  
you’ve described – some sort of DRYer way to deal with these issues –  
but I’ve decided to just wait it out. I find IE7 to be much much closer  
to Safari and FF. IE6 is dead except for corporate users who’s IT  
departments are trying to solve all of the various problems encountered  
with moving their legacy internal intranet stuff to IE7. That work  
couldn’t start until IE7 was released, and is ongoing now. As soon as  
large numbers of companies start to adopt IE7, we can all breathe a sigh  
of relief as this major PITA drops back to just a minor nuisance.

I think for any new project starting after the first of the year, there  
is a strong case to be made for just including a startup check for IE6  
(and earlier) that politely suggests the user join the new millennium.  
By the time such a new project is ready to launch IE6 should be down  
below 20 percent and dropping fast. This is especially true for social  
networking and other such sites that theoretically should have most of  
their users outside of the workplace (I said theoretically).

With IE6 out of the way, dealing with browser issues won’t go away, but  
will likely drop back to just an hour or two of tweaking some  
positioning compared to the nightmare it is today. Then web development  
will be fun.

jp
