IE CSS Parser Bugs

Posted on by

There’s an article on the IE Blog about the CSS parser bugs they’ve fixed for IE 7. It’s interesting that they are having to choose which parser bugs to fix, and in which modes, because people rely on those bugs as ways to “detect” particular CSS problems which only occurred in IE 6. Worse, there isn’t generally a 1:1 match between parser bug and CSS bug (although there are some objections, such as the Box Model Hack).

Why is taking advantage of particular parser bugs any better than conditional comments, or user agent sniffing, which has long been considered harmful?

6 thoughts on “IE CSS Parser Bugs”

  1. I’ve been working on webpages for almost a year now, so I think I have something to say.

    1) You can’t really avoid browser bugs. If you have a really simple CSS layout, like the one on this blog, mabye – but as soon as you try to use anything more complicated like floats, IE’s hasLayout is right there to screw around with you and give you all sorts of trouble.

    2) User agent sniffing is bad. It probably has some cases were it is the best solution, but those are few and in between. The biggest problems are that User Agents Strings are rather complicated things, and changing all the time, so your going to have somewhat unmaintainable mess.

    3) Conditional comments are actually quite good, but they have two problems. For one only IE (AFAIK) supports them. While it is true that 95% of the bugs a web developer encounters are IE’s fault, Opera, KHTML, and the Gecko browsers all have their set of bugs too (and if you have to support the old Netscapes there’s no hope for you). The second problem is that they can become a bit of a mess to maintain too. For example you can have one that applies to all versions of IE, but then you have to update them when ever an new version comes out, you will also have to keep separate files for all the older vesions too, that’s a fair amount of css files to maintain, quite a pain. Also you have to put extra code in your HTML, for each IE version.

    4) CSS hacks, while they aren’t perfect do have there advantages. For one thing they don’t require another css file specifically for another browser. This simplifies things quite a bit, because you don’t have to be tabbing all over the place trying to find out what rule applies to what thing (inheritance and cascading can get quite complex). While there isn’t generally a 1:1 match between parser bugs and CSS bugs, it’s usually not that bad. It’s usually at least as good as having to write another css file for every browser.

    5) I’ve just been talking about css bugs. There’s also javascript bugs which is quite another thing. Usually you can just do object sniffing ( like the classic “if(document.all)” for IE ), which makes for a pretty ideal situation.

    Also, a last note. I don’t think that fixing the * html is actually that bad. For one thing they’ve fixed several problems with the box model so this may have actually been quite a good thing.

  2. Isn’t the problem with abusing CSS parsing bugs, relying on user agent strings and doing non-related object sniffing that you’ll never know whether a newer browser is going to break any one of these.

    We’ve already seen it for user agent strings, where IE considers itself Mozilla “compatible” and Konqueror and Safari even claim to be “like Gecko”. Now we’re seeing it in a lesser way for the CSS parsing bugs, where IE 7 doesn’t support them any longer – fortunately, it’s only in strict mode and many CSS bugs which made these hacks necessary should be gone. Eventually we might run into the problem again for non-related object sniffing, where document.all might mean something different to a new browser than it means to IE (related object sniffing should be OK, since no new browser should provide document.getElementById for anything else than intended by the W3C).

    One way to go would indeed be conditional comments. These gracefully degrade for non-supported browsers, are pretty transparent to use and even allow you to work around version specific bugs (which is necessary when using a strict doctype and supporting IE 5 and IE 6). Unfortunately there won’t be any CSS conditional comments, but as long as you get over the (irrational) desire to have all CSS in one file (as I occasionally see it for myself), you’ve already got a standard solution for IE/non-IE differences.

    As you see, I wouldn’t put conditional comments into the same category as CSS parsing hacks or user agent sniffing, on the contrary. I’d even go as far as calling conditional comments an ingenious feature, since they are pretty simple to use and allow transparently for upwards and downwards compatibility (and even work without JavaScript) – and they got introduced as far back as 1998. Interestingly Mozilla won’t support them and proposes to parse the unreliable user agent string instead (cf. bug 124751). And the CSS version seems to have lost in time, as well (cf. bug 95866).

    Therefore with IE you can at least work around bugs in a future proof way, whereas with all other browsers (AFAIK) you just have to rely on that they are bug-free (which most certainly isn’t the case for any one of them). Fortunately, I haven’t found any CSS bug that severe – on the other hand the browsers I usually support aren’t older than two or three years (except IE 5/5.5/6). But I’d have been glad several times already to have had such capabilities for Konqueror, Safari and Opera (knocking on wood for Firefox).

    Most interesting however is the fact that conditional comments never really got used in mainstream code samples and never got promoted instead of the (somewhat even hyped) CSS parsing hacks. Why might that have been? Disliking Microsoft’s innovations? Ignorance about their existence or their functioning? Or were they really that bad an idea?

  3. The big problem with using conditional comments to correct bugs is that you can’t predict whether the bug will be present in future versions of the browser. So if you send a special rule for IE6 users only, you could get burned if, say, IE7 came out with the same CSS engine as IE6 (which we now know it won’t, but 2-3 years ago we had no idea) as the bugs will still be there but the conditional comments will break.

    I do not want to go back to sites completed three years ago just to update the conditional comments.

    CSS hacks on the other hand puts the problem back into the hands of the browser maker. In a way it is a challenge we’re putting to them: Make your CSS engine behave like the other browsers or risk shipping a new browser that will choke on sites when it worked fine before. Microsoft have a lot more to lose than I if they fail to meet this challenge.

    But, by the looks of that blog post, Microsoft have chosen to accept that challenge, so IMHO it looks like this is a victory for the CSS hack camp more than anything else.

  4. I don’t think there’s a good solution to this, unless browsers start shipping with support for conditional comments that are based not on browser version, but on specific bugs :)

    For example, IE could have:

    /*IFBUG[double_margin_size_for_no_reason]
    …
    ENDIF*/

    :)

    Gecko also needs a few of these… maybe I should file it as a bugzilla request… or maybe not :>

    More seriously, it would actually be possible to implement this if you have defined ‘standard compliance bug’ codes, allocate them to manufacturer/browser using the first few letters (e.g. IE45657 for IE, GK4673 for Gecko), and then assume that any unknown bug code relating to your browser is in fact a bug that exists.

    When you issue official technical support information – a Bugzilla report for Mozilla, a Knowledge Base article for IE – about the browser bug, you assign it one of these official codes – for Gecko, the code might just be the Bugzilla number of the most relevant bug report. After fixing the bug, you add that code to the list the browser knows about, and the conditionals stop happening. Neat, hrm? Isn’t it time to accept that standards bugs happen and implement a system like this rather than just pretending every browser is perfect and nobody needs to distinguish between them in order to get working layout for users of their web sites?

    Anyway, really I think conditional comments are the nicest way to do it; unfortunately I believe these aren’t actually provided for use in CSS files (you can only use them in the HTML that includes the CSS, which I don’t want to do), so I’ve been using CSS hacks.

    I think the fuss about ‘but what if they fix it in IE7? ur s1te w1ll br4ke!!!’ is fairly exaggerated, really; a site that isn’t updated every year or so has much worse problems than b0rked layout in a new IE version.