Handling browser differences

Rails
1

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

2

On Oct 31, 1:49 pm, Avram D. [email protected]
wrote:

Avram

Posted viahttp://www.ruby-forum.com/.

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

http://www.quirksmode.org/bugreports/

3

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.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:

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:

– gw

4

gene tani wrote:

On Oct 31, 1:49 pm, Avram D. [email protected]
wrote:

Avram

Posted viahttp://www.ruby-forum.com/.

here’s some good backgrounders about IE (and other browsers too!):
http://www.positioniseverything.net/
Bug Report - Latest reports
http://www.search-this.com/2007/06/19/browser-testing-made-easy/

Browser testing CSS and JavaScript | 456 Berea Street

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.

5

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

6

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?

7

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

Best regards

Peter De Berdt

8

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.

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

9

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