Stop using CSS hacks now

Still using CSS hacks for Internet Explorer? Kick the habit now or you’ll be sorry. Call to action: The demise of CSS hacks and broken pages at the IEBlog confirms what should not come as a surprise: IE7 will fix many of the parsing bugs that CSS hacks rely on. Using conditional comments is the safest way of dealing with CSS bugs in Internet Explorer.

Some of the CSS hacks that will not work in Internet Explorer 7 are these:

Update: Bruce Lawson has more on why you should Future-proof your CSS with Conditional Comments.

Posted on October 13, 2005 in Browsers, CSS, Quicklinks

Comments

  1. I think it is a bit silly to stop using CSS hacks. This is exactly what I was hoping would happen when targetting IE 6 rendering bugs with IE 6 parsing bugs.

    Get rid of the parsing bugs and the rendering bugs, this isn’t an issue. What he was seeing with the slashdot code is a very subtle example of where people weren’t working around bugs in IE, they were working around a flaw in the W3C standard on how to render something.

  2. I think it’s a bit silly too personally…let’s be realistic about how long it will take the market to adopt IE7. We need a gameplan in the mean time, and I don’t think it includes cutting out hack entirely.

  3. I think its just plain stupid: microsoft is telling me now that the workarounds to fix their shortcomings are not how they would like us to fix em??

  4. agree completely with the first comment. if the IE team fix the bugs and inconsistencies in their css parser, then you can safely keep your hacks intact, as IE7 would then get the same css as other compliant browsers and act on it the same way…a non issue.

  5. October 13, 2005 by Roger Johansson (Author comment)

    Hopefully they will fix both parsing and rendering bugs, and old CSS hacks will continue to work.

    I still don’t see the need for CSS hacks though. I think using conditional comments to import an IE-specific CSS file that contains the few height:1px and display:inline declarations needed is so much cleaner. And it’s definitely safer.

  6. Ironically enough, only a few days ago I went through and removed all of our conditional comments, replacing them with CSS hacks. The markup is cleaner, and the CSS that does X is clumped in one place for easier debugging.

  7. October 13, 2005 by Simp's

    I’m not sure I like the idea of these conditional comments… If IE7 supports standards feed it proper CSS. IE6 and under don’t, well let them have the * html workaround. The conditional comment just doesn’t seem right: in that case why not a safari, opera, firefox, or omniweb conditional comment? What’s the point of web standards?

    (and about that slashdot page, what’s the point of an empty legend tag?)

  8. That’s it. I’m moving my MSIE hax to conditional comments like this:

    <!—[if IE]><link rel=”stylesheet” href=”../styles/msiehax.css”><![endif]—>

    That way I hope to avoid major stress when the big switch comes.

    I simply refuse to believe MSIE 7 will be ‘fixed’ enough to make hacking needless.

  9. Hey good call Woolly… Simple as it is - I didn’t think of that today.

  10. I have never used them anyway (and never believed in such shitty approach to standards), but I know lot of people that destroyed standards by using them.

  11. October 14, 2005 by Stefan Ledin

    There is also the small issue of how quickly the visitors to our websites upgrade their browsers. This is probably less of an issue if all of them were computer savvy and keep up to date by downloading the latest, stable version of their preferred browser. However, a significant number of visitors do not download patches or latest versions on a regular basis. One caveat to this observation - this may well reflect the fact that the website I maintain is not aimed at techies.

  12. What about !important in IE7?

  13. The problem, as I described in my comment in the IE blog, with slashdot is that their hack addressed the symptom, not the cause of the problem. Not with hacks in general, and the IE blog’s advice needs to be taken with a grain of salt.

    Good CSS hacks should not continue working in new browser versions, that’s the whole point and what makes them future proof.

    Any unknown browsers (including future versions of current browsers) should be assumed conformant until proven otherwise (i.e. innocent until proven guilty) Thus, you should only include hacks for which you are fairly sure, if not 100% certain, will not apply to such browsers.

    This highlights the major problem with the way many people are using conditional comments, and, unless authors authors take this into consideration, the IE blog’s advice will end up biting more people in the back side than it saves!

    People using conditional comments like <!—[if IE]>IE 5/6 hacks<![endif]—> will get sorely bitten when IE7 comes around and those same hacks intended for buggy browsers get applied, even though many of those bugs have been fixed. If you’re going to use a conditional comment, at least include the version number, as in: [if lte IE 6]

    I think it’s safe to use CSS hacks, as long as you use hacks that are known to be fixed (e.g. * html) for bugs that are also known to be fixed (e.g. min-height, max-height, height and width). That way, when the new browser comes around, it will apply the correct CSS and only current buggy browsers will get the hack.

  14. I don’t think people are reading this carefully enough. Roger touched on it in his comment - They may well be fixing both rendering and parsing bugs. In this case, however, the legend spec does not state whether or not white space should be rendered, so this is not a bug.

    Whereas I think Microsoft should follow in the footsteps of other modern browsers, they are not breaking any standards by rendering white space. Note what Markus says in the original post:

    The HTML 4.01 spec does not specify what should happen in this case. We just do it differently than Firefox and Opera, who do not reserve white space (since we were the first to implement this HTML 4 element back in the day there was no precedent to do it differently).

    Keep in mind that it is much easier for Mozilla to roll out a new bugfix to its relatively small base of computer-savvy users, than it is for Microsoft to fix such an insignificant bug in its worldwide proprietary software (which, by the way, almost all of us used in order to download Firefox).

    I’m tired of bitterness towards Microsoft. They are a for-profit corporation. I’m glad to see the steps the IE team has taken thus far to push standards in the new release. Consider that sometimes the bottom line doesn’t leave room for benevolence. And if you’re looking for a for-profit corporation who truly puts benevolence first, you’ll be looking for a long time, unless you look under Chapter 11.

  15. October 14, 2005 by Roger Johansson (Author comment)

    A couple of more thoughts on this:

    Unnecessary use of different CSS rules: I think many people resort to sending IE specific CSS (by using CSS hacks or conditional comments) far too easily. In most cases taking a close look at what is causing the problem will help you find a solution that works in all browsers. In a fairly large and complex site I am working on right now, I only had to use three rules that only IE/Win 6 and lower should see. One is to compensate for the lack of support for min-width, and the other two are simple “height:1px” rules to fix a couple of minor cosmetic bugs.

    Applying conditional comments: Use the following syntax to make sure IE7 doesn’t also apply the fixes:

    <!--[if lt IE 7]>
        <link rel="stylesheet" type="text/css" href="/css/ie.css" />
    <![endif]-->
    

    I thought I had gone through all sites I’m working on to fix this, but to my embarrassment I just realised I hadn’t done it here. Fixed now.

    Protecting the innocent from invalid CSS: There are situations where IE problems can be fixed by using proprietary CSS. Making sure only browsers that understand those rules get to see them feels safer. You can’t do that with CSS hacks.

  16. October 14, 2005 by James

    Much like Lachlan, I worry that this will come back to cause greater problems. Since each of IE 5.0, 5.5 and 6.0 have bugs and inconsistencies which aren’t present in the other versions, what this is basically saying is that we need to code up a set of rules for IE 5.0, put them in an IE 5.0 comment, code up rules for IE 5.5, put them in an IE 5.5 comment, code up rules for IE 6.0, put them in an IE 6.0 comment… this isn’t really any better, to me, than some of the hacks that exist to accomplish the same task (and some of the hacks can do the same thing in less space and with less code).

  17. October 14, 2005 by Roger Johansson (Author comment)

    James: Could you show me an example of when you really have to do that? In my experience you very rarely need to send different rules to IE 5, 5.5, and 6.

  18. They’re fixing the parsing bus, but they’re also fixing a lot of the CSS bugs that we try to cure via the parsing bugs.

    Hacks are dodgy because you’re sending one bug to fix another. So, if one bug gets fixed in a future release but the other doesn’t, you’re a bit screwed.

    However, the IE team do seems to be putting in a fair bit of effort to cure both parsing bugs and CSS bugs. I agree you’re on dodgy ground with hacks, but for many, many layouts, I really don’t see the alternative, other than settling on sites displaying a bit differently in the browser used by almost 90% of users.

    Try explaining that to a client.

  19. October 14, 2005 by James

    Don’t bother with conditional comments. Use the now safe star selector hack to separate IE5-6 from IE7 and the rest. Use IEs comment bugs combined with the star selector to write different rules for IE 5.1, 5.5, 6 and Mac IE 5.

  20. I’ve always preferred to overcode, like introducing extra DIV elements to get around box model errors, rather than relying on hacks. I will confess to using the child selector to do things like feeding GIFs instead of PNGs, but if they fix the selector and PNG alpha transparency at the same time, it’s all good anyway.

    Part of the problem is that people are still slaves to layout. If more designers (and the people who sign off on their designs) would embrace “rules-based design” a bit more, and worried less about pixel perfection, almost no hacks would be necessary.

  21. Gosh, what the IE team calls “hacks” here are just child and adjacent sibling selectors - per se, these are no hacks! Instead, “conditional comments” are hacks. Or can you find them anywhere in the specs?

  22. “We need a gameplan in the mean time” - you mean the use of conditional comments to target IE?

  23. October 14, 2005 by Sparky Barkalot

    It’s almost comical to believe that there’s any significant difference between a conditional comment to support a buggy browser and CSS hacks to support a buggy browser. They’re both hacks, just hacks of a different order.

  24. Re conditional comments vs. hacks: a ‘hack’ is where you send one bug to defeat another. E.g. Internet Explorer 6 parses * html incorrectly, and also has a float margin bug.

    Under this definition, conditional comments aren’t hacks: they’re a vendor-specific extension to HTML.

    As such, they’re safer. With hacks, you’re assuming future versions of the browser will either cure both bugs, or neither. With extensions, the vendor is less likely to discontinue them, as they’re features, not bugs.

    So I think there is a relevant difference. How significant you think it is is up to you.

  25. Does anyone know what might happen when using this hack going forward? I use this one a lot for curing IE’s lack of inheritance.

    header {

    font_size: 100%;
    _font-size: 90%; /* IE Hack */
    }

  26. October 14, 2005 by James

    Roger: a while back I was hired to do CSS cleanup on a site that used a lot of absolute and relative positioning for its layout, and which was showing all sorts of problems in IE, and I found that one of the content columns was being rendered with different widths in each of IE 5.0, 5.5 and 6.0; I was used to sometimes needing different rules for 5.x and 6.0, but that was the first (and thankfully, only so far) example I’d seen of needing to differentiate all three of them.

    So it’s somewhat rare, but it does happen.

  27. I’ve had my own version of this topic sitting around as a draft for a month. Thanks for getting this together.

  28. Designers will be dealing with IE6 for years to come, regardless of what IE7 fixes. That, my friends, is the bottom line. Almost as much fun as coding Javascript that works in all the major browsers: if this browser then, if this version then, if this other browser then…

  29. Microsoft asking web developers to use proprietary MS code…

    Should we write conditional comments for each and every browser out there? To me using vendor-specific conditional comments resembles code forking. Why would IE be the only browser to use them?

    Also there is no telling that all changes in IE7 will fix at the same time the display bug and the parsing bug on which the hack used for working around that display bug relies.

  30. Right now we don’t know which bugs will be fixed in IE7, which will be left, and which will be introduced. I’m not gonna lose any sleep over this till I know what I’m dealing with. If you’re panicing about how IE7 beta looks, more fool you for downloading it.

    There’s something to be said for coralling all the IE hacks into one place - if you have a lot of them - but for the odd height/width 1% it’s overkill (I don’t worry about IE5.x any more, so no more box model hacks!). The disadvantage of conditional comments is that you have to maintain them in every page.

    The truth is that whenever a major browser is released - by whoever - you’re going to need to review, and maybe adjust or even (horrors!) hack your CSS to cope with it. That’s your job, learn to live with it.

  31. IE is the only browser to use conditional comments because it’s currently the only popular one bad enough at implementing the standards to need hacking.

    All browsers could implement conditional comments: fine. If it’s a reliable way to tell what browser’s what, then it’ll occasionally be useful to get around bugs.

    But naturally, ideally, we prefer the bugs to be fixed.

  32. Ive been using conditinal statements for some while now, I find it far more practical in real life than the CSS hacks since you dont get any validation problems. There are many people it seems who doesnt like to use conditional statements, but CSS hacks are OK? I dont really see the difference, if there is a problem, solving it with a CSS hack or a conditional statement - to me sounds the like the same thing, except that conditional statements have superior handling and looks better. Your solving a particular problem, one way or another.

    And, again, if IE7 indeed fixes most of theese problems, there really isnt’t anything to diquss… CSS hacks has to go… (Atleast for IE)

  33. Personally I am using the html>body hack a lot. However, if IE7 also has the issues of IE6 fixed, that won’t harm anyone, would it?

    as in:

    li{height:1em;} html>body li {height:auto;} to avoid whitespace paddings

    or min-height simulations:

    bla{height:400px;}

    html>body #bla{ min-height:400px; height:auto; }

    A new IE that does support min-height and the selector will do what Firefox does now, and the old one still gets the 400px and can extend them.

    Note that this is a hack that depends on CSS parser support, and not CSS parser bugs, I agree that the voice family malarkey and invalid CSS should be in an own CSS.

  34. October 18, 2005 by Roger Johansson (Author comment)

    I’m a little surprised that so many seem to be using CSS hacks extensively. Whether you use CSS hacks or conditional comments is up to you, but I’d suggest looking for ways of working around the problems before sending different CSS to different browsers. Otherwise you’ll sometimes just be treating the symptoms.

    Chris: Agreed, relying on parser support instead of parser bugs should be reasonably safe.

  35. I’ve been reading all the blogging going on about this issue and, granted I haven’t read every single post, I haven’t seen any mention of the ie specific “hack” that I use all the time (pretty much the only one, besides specifying height:1% whenever anything involving floats goes screwy in ie), and that is use of the !important declaration.

    I love this “hack” because it validates and uses regular old css. It goes like this - if ie has moved something over 3px to the right when all other browsers seem to get it right, I simply say:

    something {margin-left:0 !important;}
    something {margin-left:-3px;}

    Since ie ignores the !important declaration it applies the rules in the second line, while all other browsers apply the rules in the first line.

    Now, if IE7 decides to start following the !important declaration but fails to resolve all the problems that call for me to use it then I’m in big trouble! ;o)

  36. Going off-topic here…

    @Douglas,

    As opposed to getting CSS to behave consistently in every major web browser, it is easy to achieve that with JavaScript; just program using the standardized DOM API offered.

  37. October 21, 2005 by Meredith

    He’s totally right, you know. So much cleaner and easier to work with than silly hacks…

    Thank you for the links. :)

  38. There is a css hack that works for all versions of internet explorer, including ie7. You can read about it here: IE CSS Hack

Comments are disabled for this post (read why), but if you have spotted an error or have additional info that you think should be in this post, feel free to contact me.