Re: The IE 6 Equation

Jens Meiert, December 9, 2008.

This entry is filed under Web Development.

Great: 24 ways is active again. Not so great: Their new site design. No, that’s nothing to talk about right now, not after I already offered Drew to explain my concerns after he asked me to; I rather refer to lack of some details to help making informed decisions.

Yesterday’s contribution was about Internet Explorer 6 and whether or not to go for Conditional Comments or Dean’s IE 7 script. Alas, I’m afraid there are three issues (not just the two I briefly mentioned in my comment that never appeared) with Jeremy’s suggestion:

There is at least a third option: Just make sure your styling works in IE 6; either go for alternative solutions that work equally well in all user agents, or, as a last resort, use valid workarounds like e.g. child selectors to target modern browsers except for IE 6 to preserve the maintenance advantage centralized styling usually means (this post is not about workarounds or “hacks” though).
Conditional Comments mean a maintenance hit: No need to renew my concerns about Conditional Comments, however the main issue with Conditional Comments is their implicit hit when it comes to maintainability, as they imply (in this case yet presentational) HTML changes and updates.
The IE script means a performance hit: The IE script is about 30 KB big and means an additional HTTP request, which I may politely suggest not to see as kind of a bad browser tax. No matter that not all users need to download the script, this is still something quite sensible for IE 6 users, the users the entire article is about.

My feeling is that in conjunction with intel on how many site visitors actually use IE 6, these three aspects are vital for an informed decision. Feel free to disagree with me (no comments deleted, usually).

Enjoy the most popular posts, probably including:

Comments

On December 9, 2008, 13:23 CET, Kroc Camen said:

There’s one other method that I’ve realised is possible that as far as I’m aware of, nobody else seems to have twigged, or at least it hasn’t become widely known.

Use mod_rewrite to provide different versions of a “fixes.css” file based on UA.

Basically, write your main stylesheet to conform to the latest browsers, and then write a fixes sheet for IE6. The mod_rewrite detects IE6 and gives a different “fixes.css” than what IE7 or Opera or Safari would receive &c.

And to get rid of a http-request tax on bad browsers, use mod_rewrite to instead redirect the one single stylesheet on the site to the fixes.css *only* for bad browsers, and the fixes.css file @import the main sheet at the top. That way good browsers get only one CSS file, and bad browsers get two, with fixes specific to that browser.

I’m planning on writing a full article on this technique at somepoint.
On December 9, 2008, 15:36 CET, Vladimir Carrer said:

I completely agree about the site redesign, why they need to redesign something beautiful I loved the old site with simple digg like red buttons. About IE6 “problem” I’m working on some possible solution.
On December 9, 2008, 16:41 CET, Srdjan Pejic said:

Kroc,

The problem that I see with your technique is that UA string is a highly unreliable piece of information. Certain browsers will put IE-like information in it, so as to not get blocked from sites.

If you have a way around that, I’d be very interested to read about it.
On December 9, 2008, 18:22 CET, Kroc Camen said:

There’s no UA I can’t get around with regex, it’s very easy. Opera, even when spoofing as IE, still has Opera in the string.

I’ve written a comprehensive browser detection script before and I’m confident that it’s no problem to do accurately – also remember that this is a solution for targetting fixes to legacy browsers and the amount of detection actually needed would be minimal. No UA detection would be done at all for up to date browsers as the mod_rewrite would default to the main sheet if there was no legacy match, that’s the key thing to bear in mind here.
On December 9, 2008, 20:46 CET, Duluoz said:

Jens, once again, I can not disagree and must admire your ability to keep view of the bigger picture.
@Kroc - your solution is actually quite ingenious, I must admit. However, does your solution add to maintenance concerns?
On December 9, 2008, 21:26 CET, Kroc Camen said:

@Duluoz. No, I came up with the idea specifically to keep maintenance to the minimum. No browser-specific moderations need ever go into the main sheet. You can write cutting edge CSS, and just maintain only fixes for specific browsers in separate sheets and they can safely bit-rot unless you’re changing the HTML.

This way, a browser can easily be depreciated too – instead of untangling the hacks used in the CSS, you’d just delete the UA line in the mod_rewrite and delete the relevant fixes.css and that’s it – browser unsupported.

Also, imagine a new version of a browser comes out, and it breaks some of your design. Normally you’d have to franticly do random guesswork and hacking to get both supported using the same CSS sheet. (*cough*For example unexpected breakage between Firefox 3 and Firefox 3.1*cough*) My method means you can easily add a new UA-specific (even version-specific) stylesheet to quickly work around that problem.
On December 9, 2008, 21:48 CET, Duluoz said:

@Kroc - I understand your point - however, the concern hints at #2 in the article. You’re still maintaining “something” weather it be a conditional comment or a mod_rewrite. Your solution, though brilliantly simple, replaces maintenance task X for Y.
On December 9, 2008, 21:59 CET, Kroc Camen said:

@Duluoz If you can’t avoid IE, avoid it in the most elegant way
On December 9, 2008, 22:12 CET, Pesla said:

This discussion will fade away if people start serving their CSS based on which User Agent is visiting the website.

We are currently busy with front-end optimalisation, and rewriting the way we serve our CSS- and JS-files to the various User Agents around. This means that users with a rather incapable browser get the necessary files to view the website as it is meant to be viewed. Proper browsers won’t load the unnecessary files - no extra hits, no lost performance. This also means: no maintanance hits.

In the end, you’d need no more than 2 stylesheets for every browser - a print.css and a (merged) stylesheet which is served depending on which User Agent is used.

In my opinion this discussion got way too much attention!
On December 10, 2008, 12:13 CET, Thomas Eilander said:

The new design isn’t that bad in my opinion. Could be worse, could be better.

I agree to point 1. Just try to make everyting work in ie6. As I already mentioned on 24ways, I’ll constantly check ie6 when building, and solve problems on the fly. If you first build the whole site and check it in ie6 afterwards it’ll take much more time to solve problems.
On December 10, 2008, 16:47 CET, Jens Meiert said:

Kroc, rewriting would certainly be more elegant, yes (and let me give this thought a minute). Looking forward to your article.

Vladimir, above all, the old site design will have worked better, measurably. Anyway.

David, thank you.

Pesla (and somehow touching the UA detection discussion), the vision is not to come up with something that reliably tracks user agents and delivers different files, but have one file (style sheet) rule them all. Don’t fall for current implementation problems. Pure CSS redesigns done by updating a single file (ideally) are what we want.

Thomas, fair enough, the process is important too. Doing a more or less complex project to act all surprised when testing in IE 6 five minutes prior to launch’s probably not … wise.
On December 10, 2008, 22:30 CET, Pesla said:

Hi Jens,

I agree with you - in an ideal situation, all developers would use on CSS-file for every client visiting the website.
This isn’t very realistic, the need for IE specific bugfixes heavily depends on the kind of project you’re working on.

A simple layout like your own website (simple != negative ), is more likely to be a cross-browser success based on a single CSS-file than a complicated extranet design. It depends on your user-base, framework, html-output, etc.

In an ideal situation, every browser would behave the same. But for now, depending on the project, in my opinion serving files based on the UA is really the way to go instead of using conditional comments or other techniques.

@The 24ways redesign: i completely agree with you.
On December 10, 2008, 23:16 CET, Defs said:

IE6 is really big trouble for any projects. If someone (who became great-man after that of course) release any complete universal solvation for IE6.. Any loader or something, that would work for any website. It can be controlled via .htaccess, or java-script etc. Let be posted a little link to script autor url, if IE6 used by guest (as a credit for this script). Is it possible at all?
On December 11, 2008, 2:29 CET, Nice said:

IE6??? It’s very old… Now IE8!
On December 16, 2008, 21:04 CET, Kroc Camen said:

To those following the discussion, I’ve now posted my article:

http://camendesign.com/code/mod_rewrite-css-targeting

Thanks to Jens, and everybody here for influencing the writing!
On February 15, 2009, 18:05 CET, Jeremy Keith said:

You say that my article is about “whether or not to go for Conditional Comments or Dean’s IE 7 script.” It isn’t. Read it again. It is about using conditional comments *together with* Dean’s IE7 script. That’s kinda the whole point: the performance hit you refer to would only be felt by IE6, hence “bad browser tax.”
On February 15, 2009, 18:29 CET, Jens Meiert said:

Jeremy, better read my post again too.

Jens Meiert

Re: The IE 6 Equation

Read More

Comments

Leave a Comment