A rebuttal to the Universal IE6 Stylesheet

Dev

A rebuttal to the Universal IE6 Stylesheet

//

I spent some time today reading and considering the ideas in two different blog posts online. The first, Universal Internet Explorer 6 CSS by Andy Clarke, and the second, The Elephant in the Room by Jonathan Snook, which was somewhat of a reply to the first.

As a web designer and developer, my first reaction is to applaud the idea. The web browser market has grown from 2 or 3 players to at least a half dozen these days. And if a design doesn’t work in one of them, a client will figure that out and perceive that their site is broken. Every time a new browser is released, we designers and developers must add that to the list of things to test. I’ve faced that frustration as much as anyone, and the thought of removing a browser from the list of items to test is appealing. But my theory is that once IE6 is officially off the map, we’ll just turn on the next lowest common denominator, and it will become the new whipping boy.

We’d like to ignore the facts. The facts are that around 20% of web users are still using IE6. It’s going to be THAT number that determines the end of IE6. For our clients that use IE6, there is no amount of explaining that will change their perception that a design is “broken” in their browser. In their rationale, if THEY are using IE6, surely there are quite a few others using it as well. And they’re right. Based solely on that, I feel the need to argue against Andy Clarke’s simplistic approach to the problem. He advocates a stylesheet that strips all but the most basic of formatting from the page. While it certainly guarantees that the information will be delivered, it’s not a practical idea to push on a client. Even if you can convince them that it’s a good idea, they’ll still be muttering to themselves that the site is “broken”. And even worse, they’ll be fielding questions from their colleagues about why their website doesn’t work right.

My personally preferred approach is a combination of numbers one and two on Andy’s list. Number one suggests designing for newer browsers, and then developing alternate design solutions for bugs in IE6. Approach number two suggests using a stylesheet specific to IE6 to render an identical design. IE6 is always the last browser I test in, and I can think of very few designs that didn’t need some IE6 tweaking. I’m not advocating that the design should be pixel-perfect between browsers. But I’ve never had many problems at least getting IE6 in the neighborhood of the way the design looks in newer browsers. Most of the time, that only entails a half a dozen or so overrides in an IE6 specific stylesheet. Most of those involve setting custom margins, padding and height, or maybe implementing transparent PNG support. Sure, it’s an extra step in the development process, but I think clients would be happy to pay for that hour of work just so they don’t need to answer to their colleagues who are also using IE6.

If it’s taking you more than an hour or two to create those overrides, maybe you should be examining the way your site is built rather than singling out IE6 for ridicule. I like to follow the golden rule of “Keep it Simple” when building my HTML and CSS. Is it really necessary to float and absolutely position every element on the page? Probably not. Does the client think all of those AJAX effects are as cool as you do? Probably not.

I’m all about bashing the lowest common denominator when I’m talking shop with my designer and developer friends. But shouldn’t we be insulating our clients from that conversation? It seems like we are trying to push the problem off on them. I don’t see any problems with informing them that some time will need to be spent on IE6 support. But suggesting that they upgrade their browser, or even worse, forcing them to look at a white page with black text, seems a bit selfish. The underlying impetus of that suggestion is simply to make the job of a designer or developer easier. I can think of very few benefits it actually has for the client.

More About the Author

Matt Mueggenborg

Lead Web Developer
Don’t Take NULL for an Answer – Make Tableau’s ‘getWorkbook()’ and ‘getActiveSheet()’ Functions Behave Correctly NULL errors have cropped up twice in recent development projects utilizing Tableau’s JavaScript API. In one instance, getWorkbook() ...
The BURNING Question: What was HOT at DrupalCon 2013? As a web developer, you were faced with a unique decision this year. Should you get your ultimate geek on at the 2013 DrupalCon in ...

See more from this author →

InterWorks uses cookies to allow us to better understand how the site is used. By continuing to use this site, you consent to this policy. Review Policy OK

×

Interworks GmbH
Ratinger Straße 9
40213 Düsseldorf
Germany
Geschäftsführer: Mel Stephenson

Kontaktaufnahme: markus@interworks.eu
Telefon: +49 (0)211 5408 5301

Amtsgericht Düsseldorf HRB 79752
UstldNr: DE 313 353 072

×

Love our blog? You should see our emails. Sign up for our newsletter!