CSS hacks are starting to break

In a recent article on the IE Blog, Justin Rodgers talks about further CSS improvements in the ever more impatiently awaited IE 7 beta 2. His message is that CSS hacks will start to break in IE 7, and I fully agree.

Nearly two years ago I warned against the excessive use of CSS hacks, because I envisioned a situation like this. Web developers who rely on CSS hacks are going to have serious problems.

The changes

Rodgers announced that IE 7's selector support will change in two ways:

  1. It will support the > selector and the + selector.
  2. It will not support the * html hack any more.

As we all know, these selectors are often used to give different instructions to Explorer Windows than to the other browsers. Using the > selector ensured that styles are not parsed by Explorer, while using the * html hack ensured that styles are parsed only by Explorer.

Incidentally, Rodgers seems to think that these two hacks are usually applied together, the one for applying non-IE styles and the other for applying IE-only styles. In my experience, however, web developers generally use only one of the two hacks.

Rodgers furthermore seems to feel that the two changes to IE's rendering engine cancel each other out. I disagree. Even if these hacks have been applied on the same pages and both stop working, what's going to happen next depends entirely on the exact CSS support of IE 7. If the fundamental IE problem which the hack was supposed to solve has been solved itself, fine. But if it hasn't been solved ... oh boy!

Don't hack that CSS!

Let's be absolutely clear: Microsoft is doing the right thing. The blame for this mess lies squarely with web developers who have relied too much on CSS hacks.

The IE team quite rightly wants to improve the standards support of its browser, so it removes parsing errors and adds new selectors. This has to be done anyway, so why not now?

Now if the IE team would simultaneously solve all other CSS rendering bugs, there would be no problem. The hacks wouldn't work any more, but they wouldn't need to work any more: the bugs they circumvented have been solved.

Unfortunately I am quite sure that the new IE 7 will not solve every single CSS bug that has ever plagued IE 6 and lower. Therefore some special IE styles that are still necessary will not be applied any more, since the CSS hacks that were supposed to add them don't work any more.

I feel the situation will grow rather worse than Rodgers expects, and that breakage of sites created months or years ago, angry phone calls by clients who rightly demand an immediate solution, 120 hour weeks, and frantic mails to CSS lists will become a common feature of life for hack-happy web developers in the first few months after IE 7's final release.

Even if you weather this crisis, it's only a matter of time before other browser vendors start doing the same thing, and you're forced to rewrite your Opera, Mozilla or Safari hacks.

A wonderful mess, isn't it? Take my advice and stop using CSS hacks right now, except for the very few safe ones. It won't help sites you've already delivered, but it will prevent you from having to recode your current sites in a few months.

This is the blog of Peter-Paul Koch, web developer, consultant, and trainer. You can also follow him on Twitter or Mastodon.
Atom RSS

If you like this blog, why not donate a little bit of money to help me pay my bills?



Comments are closed.

1 Posted by Ali P on 6 September 2005 | Permalink

Why oh why oh why not use IE conditional comments for a few IE specific rules? It's sooo easy, and so much neater than slashes and asterisks and other wierd stuff. And the big plus: IE7 is no threat whatsoever.

2 Posted by Keith on 6 September 2005 | Permalink

Unfortunately, the problem I think we're overlooking here is the need to continue to support older versions of IE, which will be necessary for MANY years to come. The hacks -- or some similar workarounds -- will still be needed there, even if not in IE7. If anything, things will only get more complicated now.

As long as Microsoft applies the CSS fixes to strict doctypes only, though, and doesn't change any quirks-mode functionality, the damage shouldn't be *too* bad. I'm fairly sure this is what they'll do, as this is exactly why they didn't fix a lot of these things in IE6 -- fear of breaking way too many sites out there.

3 Posted by Jo on 6 September 2005 | Permalink

For serving specfic styles to IE 5 WIN and up, the IE conditional method is hack free. Using each time a seperate IE conditional for IE 5.0, IE 5.5, IE 6, IE 7.

Also this import hack can be usefull to serve specific styles to IE 5.x MAC. When the browser has become obsolete, the styles wont even be imported. But due to its complex nature, could it harm any other future browsers ??

@import "ie5-mac.css";

4 Posted by 4rn0 on 6 September 2005 | Permalink

"Unfortunately I am quite sure that the new IE 7 will not solve every single CSS bug that has ever plagued IE 6 and lower."

Let's keep our fingers crossed, hoping they did fix most of them... Or otherwise this will get really ugly when IE7 is ready for public!

5 Posted by Adrian D. on 7 September 2005 | Permalink

And so what if they do break? If Microsoft releases a browser that is up to par with the rest then there won't be a problem. If they don't, it is their PR problem when sites suddenly don't work when users upgrade their browser.

6 Posted by 4rn0 on 7 September 2005 | Permalink

@Adrian D.
That sounds nice and there is some truth in there, but I'm probably gonna have a hard time explaining to my clients that it's Microsoft's fault...

7 Posted by Ingo Chao on 7 September 2005 | Permalink

I don't think it's the end of the world, like predicted for the Y2K issue, only because IE7 is approaching with the ability to break hacks.

We have to wait and see what bugs are fixed, what bugs are partly addressed, and what bugs remained unfixed. The fact that they have unplugged the * htm hack might be a vague sign that they are convinced that they have fixed most head bangers. Good.

These hacks weren't developed for fun.

Even if the web developer has used conditional comments for years, he will have to check the effects of his "if lte IE6" or "if IE" rules anyway.

Partly this is true for the web developers who code their pages "hack-free", because they have to check if they relied on implicit hacks.

8 Posted by ppk on 7 September 2005 | Permalink

> If they don't, it is their PR problem when sites suddenly don't work when users upgrade their browser.

Ah, but the breakage will *only* occur in advanced CSS sites, and not in old-fashioned table-based sites. So it's also a PR problem for CSS, since tables are "more reliable".

> These hacks weren't developed for fun.

I disagree. Creating CSS hacks was very fashionable for a while, and I'm afraid there were quite a few hacks developed for fun.

9 Posted by Adrian D. on 7 September 2005 | Permalink

Well, unless you have a contract that says your client's site will work in all major browsers x years into the future, I don't see how the client could possibly lay the blame on anybody but Microsoft... especially when, for about two-three years, Microsoft gave us absolutely no information on the future direction IE7 would take (for a while there it even looked like there would be no IE7).

Microsoft don't exactly have the best reputation when it comes to reliability, so I would have thought it would be pretty easy to convince clients that Microsoft is to blame. Even as a precedent you could explain that many games that worked in Windows 98 stopped working when users upgraded to Windows 2000.

But anyway, I don't think Microsoft can take the PR hit that a problematic IE7 would bring, so I'm willing to risk that they'll get CSS up to par in the coming versions. Anyway, what other choice do we have? Conditional comments still require maintenance...

10 Posted by Mark Priestap on 7 September 2005 | Permalink

"Why oh why oh why not use IE conditional comments for a few IE specific rules? It's sooo easy, and so much neater than slashes and asterisks and other wierd stuff. And the big plus: IE7 is no threat whatsoever."

Exactly. Use conditional statements and there is no problem with IE7 OR with supporting older versions of IE. Problem solved.

About conditional statements: http://msdn.microsoft.com/workshop/author/dhtml/overview/ccomment_ovw.asp

11 Posted by Jamison on 7 September 2005 | Permalink

That's why i've always used IE 5.5 as my target.

Standards are nice, however i'm not about to create "hacks" so I can force the dominant browser to do what some standard says it should do.

Of course I hope IE 7 is more compiant to standards. I'm sure transitional pages will still be rendered in the old manner.

12 Posted by Small Paul on 8 September 2005 | Permalink

Look, guys, this is all simply a spin problem. Here's what we do.

1. Call clients. Tell them Microsoft is coming out with a new browser, with new technologies, that may be incompatible with their old websites.

2. Tell them we've come up to speed on these changes, and can make their websites IE7-compliant, for a reasonable fee.

3. Take a holiday, perhaps in the Cayman Islands, with the proceeds.

13 Posted by Big E on 12 September 2005 | Permalink

I disagree. The star selector hack is now a "safe" hack if you have been or are using strict mode. No need for conditional comments any more. The star selector now separates IE 4-6/IE 7

14 Posted by Paul D on 12 September 2005 | Permalink

Good point, Big E. Chances are the * html hack, which I use because it's easy and keeps my code in one file, will keep doing its job as a fix for IE 6.

If IE 7 still has rendering problems, we can adopt conditional comments for that or find a new hack.

I'm not sure why people place the blame on web designers for the IE hack situation. Microsoft's made their bed - crappy CSS support - and they're going to end up lying in it when people upgrade to IE 7 and realize their favourite sites don't work. People tend to blame the latest change for any problems that show up, so I think it'll be Microsoft, and not designers, taking the heat.

15 Posted by jedaffra on 13 September 2005 | Permalink

What about Tantek Çelik's IE5.0/Windows Band Pass Filter and IE5.5/Windows Band Pass Filter ( http://tantek.com/CSS/Examples/ )?

Plunk these bits of code into an external style sheet and point them to your IE5.0 and IE5.5 specific style sheet files - they work fantastic.

His site basically says that the filters will pass your external browser specific style sheets to version 5.0 & 5.5 Internet Explorer for Windows browsers, but not to earlier/older browsers, nor to newer / more modern browsers. The way I see it, IE7 shouldn't be an issue if everyone ported their hacks to these filters... am I missing something?

By the way, hats off to Peter-Paul Koch - this is very resource filled site.

16 Posted by Small Paul on 13 September 2005 | Permalink

You're missing the fact that Tantek doesn't know if the filters will pass code to IE7, because IE7 isn't out yet. He also doesn't know if they'll pass it to IE8, Mozilla 2.6, or any other future browsers.

That's the problem with hacks: you're sending one bug to fix another, and thus assuming that the two bugs will only ever appear together.

17 Posted by Jo on 14 September 2005 | Permalink

"You're missing the fact that Tantek doesn't know if the filters will pass code to IE7, because IE7 isn't out yet. He also doesn't know if they'll pass it to IE8, Mozilla 2.6, or any other future browsers."

That is why seperate IE conditional comments for eg IE 5.0 and IE 5.5 will prevent that any hacks or any CSS rules in the IE conditional comments will be interpreted by any future versions of IE. Therefore Tantek stylesheet import IE 5.0 and IE 5.5 hacks are simply not needed.

18 Posted by Scott Johnson on 25 September 2005 | Permalink

I fully support Microsoft in breaking these hacks. Sort of.

Microsoft shouldn't have to support hacks like this. Instead, they should fix the problems that cause us to use these hacks. For example, I often use the > selector to specify different widths for IE. That's because IE renders these widths differently than all of the other browsers. If MS would fix the width rendering, reading my non-IE CSS would not be a big deal at all.

The problem comes in when MS uses a list of hacks as their list of bugs to fix and doesn't go out and fix *everything*.

As much as it sucks to use CSS hacks, we will probably just have to find new hacks to use now.

19 Posted by Ted Drake on 29 September 2005 | Permalink

Is there a way to insert a conditional comment into the CSS file instead of the html file?

20 Posted by Dustin Diaz on 1 October 2005 | Permalink

This really speaks out there to the CSS novices who have yet to figure out how to do things right the first time. As Peter warned, keep hacks to a minimum. In the rare occassion of actually having to use a CSS filter, I couldn't imagine throwing it in an entirely separate file just to contain one single rule.

Not to mention, when a site breaks, it breaks. When someone tells me, I'll go fix it. No big deal.

21 Posted by Shelly on 2 October 2005 | Permalink

I understand the idea that IE7 will cause some sites to break. But, as a web designer who *does* use hacks, my thoughts are along this line:

1) I *always* code my sites *first* in a standards-compliant browser (hello Mozilla!). Because of doing this *first* it minimizes the need for hacking. And quite honestly I usually only end up hacking for IE, because it sucks at standards-compliance.

2) If IE is *honestly* getting their asses into gear, then the sites I've built - based on a standards-compliant browser - should *not* break, because Microsoft has finally gotten up to speed and made themselves standards-compliant. In other words, if they're really gonna do what they say they are, then their new standards-compliant browser should already read my standards-compliant designs just fine.

3) I'm still gonna need those hacks for IE6 and older. Just because IE comes out with a new version doesn't mean the rest of the world will race to upgrade.

That's my stand. I don't understand how this is such a big deal - because - again, referring to #2 - if they're *truly* gonna get with the program, then the good coding I've done for compliant browsers *should* be rendered just fine, and the hacks for older browsers will be ignored.