The future of CSS hacking

In an article at the recently launched Vitamin, Dave Shea brings up the potential dangers of using CSS hacks. Stop Hacking, or be Stopped is Dave’s first article for Vitamin, which looks like it will be a great resource for web designers, developers and entrepreneurs.

In the article Dave uses the upcoming release of IE7 to point out that relying on browser bugs to send different CSS to different browsers has always been risky, and that it is proving to be increasingly difficult to keep track of and test various hacks in specific versions of specific browsers. He ends the article by suggesting a few possible ways of dealing with browser discrepancies in the future.

As I have stated before, I have never felt very comfortable with using CSS hacks. Opening somebody else’s CSS file to find hacks and filtering provided for just about every browser that can be targeted with CSS hacks is really scary. Some people seem to use hacking as their first course of action when they encounter rendering differences between browsers. I am quite the opposite: only if I can find no other way do I resort to hacking. Or maybe I shouldn’t even call it hacking, since the only browser that tends to need different CSS rules is Internet Explorer, and most of the time I use conditional comments for that. Filtering is probably a better term.

Some would be surprised by how often you can manage without hacks.

Posted on May 19, 2006 in Browsers, CSS, Quicklinks


  1. It certainly seems that the reason a lot of people use hacks is either out of laziness or an incomplete knowledge of CSS. I’ve just completed a highly complex magazine layout and although it was time consuming and a bit painstaking, I managed to iron everything out with just one hack (the peekabo bug was the problem).

  2. Thanks for having such a wonderful and valuable site!

    I also feel its best to design without hacks or workarounds of any kind, but I know that design requirements sometimes collide with that principle. What’s your take on the number and kind of hacks that will be necessary with IE 7?

  3. Yeah Roj, I’m with you on this.

    Filters are nasty — they just seem like such a “flimsy” way to increase support in browsers .. and MOST of the time .. changing the XHTML layout of your CSS approach (positioning vs floating) is sometimes all you need to do.

    I have found a “style” of css’ing(?) that seems to be well supported and most often broswer friendly.

    But things like clearfix I seem to abuse at times. But I don’t know if I would consider that a filter(hack)

  4. I agree with you Webster, although the article makes some good points. I’m also against hacking your CSS to match -as always- a correct view of a page in IE… I really hate IE, but I have managed to avoid using hacks and get around 98% of compatibility on my sites… example:

  5. Virginia: IE7 has some issues with the width and height properties fixed and has fixed some float bugs and some other stuff, but it also introduced a few new bugs and left a massive amount of things unfixed. It looks like hacks will still be necessary in a lot of cases. I much prefer IE conditional comments over CSS hacks, but IE7 also has the *+html{} hack if all else fails. It works just like the * html{} hack, but it works in IE7 (and not in IE6 or below).

  6. May 19, 2006 by fartikus

    authors feel compelled to code hacks out of a misguided notion that the “just right” presentation of their site will make it a success. it won’t. no one uses your site because of the way it looks.

  7. I also like to avoid using hacks and mostly just need to add some hacks for IE.

    However I am not a bit scared about using the * html hack (which is the only filter I ever use). I think it’s just as save as using conditional comments to target IE5-6. It’s used so much that no browser will ever ‘implement’ this bug.

  8. May 19, 2006 by Ryan

    In my opinion use of hacks is just part of the learning proces and understanding of css, I’d say 99% of (web standards concerned) designs use them at some point in their time.

    I used to use them quite often but as my knowledge developed so did my coding and use of hacks. These days (and for quite a while now) I use conditional comments since almost all hacks are directed at IE anyway.

  9. I managed to write CSS without any hacks or filters in my last few project, lucky me, but i will encounter maybe in the future some project that will give me no other way. I hope not, butt you never know.

  10. If a hack would be defined as anything added to the code that is not required — because the CSS specification says it should work instantly, out of the box, as per spec — but it breaks in some browsers without this addition, then authors who claim to code hack-free or nearly hack-less would realize they are hacking all the time.

    So better don’t make such a broad definition, better tell them to stop hacking and use CC’s instead, because that would be valid and the future.

    The CC is not a hack because we say, deliberately, that this is not a hack. Adding a width to a link in a list to stop the white space bug is not a hack because we did not need a star html. Adding position:relative to prevent a negative margined float from being clipped is not a hack, because we hope we are free to add position:relative wherever we want.

    Uh, and the easyclearing is full of hacks, yes, but we need a clearing method without a markup change, so these hacks are necessary per definition. And we do just use hacks when it’s unavoidable, only the others who use hacks just don’t understand how to code CSS the intelligent way.

    Because we do have this understanding, we do not use percentage margins anymore, and we have stopped thinking of how useful display:inline-block would be, and we do not use any display:table- anyway.

    And with all our believe in standards, we proclaim that there is a need for something like a Conditional-CSS-Comment.

  11. I’ve managed to keep my hacks down to a minimum so far. Their strictly last resort to me. Whenever I do use a hack I’m usually left with a sence of defeat. That nagging feeling there’s a hack-free solution which I just missed…

  12. I use the “avoid if you can” strategy when it comes to filters and hacks, but I won’t let IE/win, or any of the new browsers, prevent me from using perfectly valid solutions.

    I most often prefer to filter in some corrective measures if a ‘non-supporting’ or ‘buggy’ browser prevents me from using CSS to its full potential. The offending browser gets whatever it needs, and the good browsers get it all.

    It is nonsense when someone says that those who use filters and hacks are lazy or have incomplete knowledge of CSS. Some of us may actually have a better knowledge about CSS specs and browsers rendering-engines than those who avoid all filters and hacks, and parts of CSS specs, and call ‘conditional comments’ a non-hacky solution.

    The future for ‘solid hack strategies’ looks brighter than ever.

  13. Word. Hacks = maintenance nightmare. If you code for money, it ain’t just you who’ll be working on your code.

  14. I’ve been thinking about this a lot recently, and completely re-did a couple of web sites without using hacks in the main style sheets.

    I did try not to use hacks for IE 5-6, or IE7, but both required them for those designs (although the IE 7 one was much smaller than IE6’s).

    My worry for future is on two points:

    1. How many different style sheets will we have to link to from every page (e.g. IE 5-6, 7, 7.5, 8…)
    2. How do you get around differences in standards savvy browsers that have ‘fixed’ the (valid) filters we have previously used?

    I think a possible answer is a CSS version of the conditional comments, but it would need to be extended to other browsers as well: CSS conditional comments

    (Skip down to “New CSS setup”, people here probably know the history ;)

  15. How many different style sheets will we have to link to from every page (e.g. IE 5-6, 7, 7.5, 8…)

    One, single, stylesheet for IE/win. Old versions keep their bugs, so we can filter them in one stylesheet - without any fear of breaking. If that stylesheet is linked in via a ‘conditional comment’, then there’s the extra freedom of being allowed to use every non-valid CSS-hack in the book for discontinued versions.

    How do you get around differences in standards savvy browsers that have ‘fixed’ the (valid) filters we have previously used?

    The validity of filters don’t make them any safer - as you have probably noticed. Valid selectors should only be used for progressive enhancement, and not as filters to show/hide styles.

    Keep all ‘unsafe’ filters (that’s nearly all of them) in one, single, stylesheet, and only a comment about (each of) them in the main(s) one(s). One should not need to use more than a few filters/hacks for standards savvy browsers anyway - even for the most complex layout, so updating them shouldn’t be much of an effort.

  16. May 21, 2006 by gary turner

    Ah, leave it to Ingo and Georg to clear much of the smoke.

    I prefer the programmers’ definition of a hack,, especially the second, where IE is concerned (tnx to ESR):

    1. n. Originally, a quick job that produces what is needed, but not well.

    2. n. An incredibly good, and perhaps very time-consuming, piece of work that produces exactly what is needed.

    Hacks of one kind or another will be with us for a long time, and IE7 won’t stop the need. Thanks to the the incredibly good and time consuming work by Big John, Holly, Ingo, Georg, Bruno and all those who went before, we use their hacks without thought. (I should mention Tony Aslett, whose modified easy clearing/clearfix hack we all use.) And as a few of my tests have concluded, we’ll need those same hacks to make IE7 work. We just need to find new filters. Tantek, we have more work for you and the other css pioneers.

    The idea of browser sniffing via conditional comments is abominable. It’s a hack of the first type. Filters like the “* html” also leave me feeling a bit queasy, but are somehow easier to stomach because I can leave them physically close to the elements being ‘hacked’, so they are more easily maintained.

    Speaking of hacks, I want to give props to Ingo Chao, building on Bruno Fasino’s work, for a truly ugly hack that is an elegant solution to IE’s lack of support for css2. While modern browsers easily rendered as desired, using the table related values of the display property, IE6 could not. IE7 will also be impotent to render properly, but the * html filters we used won’t work. We may be forced into CCs, but I won’t like it.

    Even if CC’d, it’s still a hack, and we will continue to need hacks as long as a major browser is so far behind the curve on support, and as long as that browser continues with the evils of hasLayout.



  17. Filters like the “* html” also leave me feeling a bit queasy, but are somehow easier to stomach because I can leave them physically close to the elements being ‘hacked’, so they are more easily maintained.

    Hi Gary,

    That is how I used to us them, but using that method seems to actually break IE7’s rendering, sometimes in very bad ways (like not showing any content).

    Apart from that, I agreed with what you said, and I think we are now (with IE7 beta being released to the public) in a position where we are forced to use CCs.

    Once in that position, I think it’s time to use the advantages of that approach, except that for future it needs to be a CSS method to prevent unnecessary complications in the HTML.

    At least conditional comments are browser specific, and are only downloaded by that browser. Sure you you can group browsers (like IE5, 5.5 and 6 if you have it in quirks mode), but the filters don’t work on new browsers.

    More and more we are going to find situations where we need to differentiate between good browsers. Compare the main content image on this page between FF 1.0 and 1.5.

  18. More and more we are going to find situations where we need to differentiate between good browsers.

    I think it’s going a bit too far if someone wants all versions of all browsers to render web pages identical. What’s the use of improvements in browsers with each new version, if we are either to pull it down to a previous level, or drag the older versions “kicking and screaming” up to the level of the new, improved, version?

    No! Get the design optimized for the latest, and hopefully best, version, and keep it well-working and good-looking in the slightly older versions until they can be safely forgotten. New versions will arrive all the time, and the need for hacks and filtering should become lower, not higher, over time.

    • Non-hacky solutions across browser-versions are those that’ll work flawless in older versions - and provide nothing new for the new versions. No progress in that.
    • Hacks/filtering across browser-versions will create a maintenance-mess that’ll only get worse as new browser-versions arrive. No progress in that either.
    • Absolute minimal use of hacks/filtering for older browser-versions just to keep things working, may be acceptable - but only if the solution is well tested. That’s what I call a ‘solid hack strategy’, and it should only be applied for discontinued versions that we know still are widely used.

    The good browsers have built-in differences. Let them keep them, since no-one but over-eager designers compare rendering-details between browsers.
    As a user: I would be disappointed if my latest downloaded browser-version(s) rendered everything exactly the same as the old one(s) from a year ago. Where are the improvements?

    IE6 and older are definitely discontinued, so anyone who like may hack them to death - just for fun if nothing else. Better leave the other browsers alone with their upgrades and improvements - unless someone are willing to pay you a ridiculous amount of money for creating and updating the maintenance-mess. Maybe ask them “why” first…

  19. no-one but over-eager designers compare rendering-details between browsers.

    Unfortunately clients do as well, if it’s the slightest bit obvious.

    As a user: I would be disappointed if my latest downloaded browser-version(s) rendered everything exactly the same as the old one(s) from a year ago.

    I don’t think regular users consider that sites might look different. For a regular user to upgrade their browser, they tend to expect interface, speed or security improvements.

    Also, how do you reconcile David Shea’s example with text-shadow from the referenced article? Without some mechanism to differentiate between modern browsers, there a situations where you just can’t add a new (CSS 3 for example) property.

    Would it not be best to have one (set) of CSS that is the base level, cross browser code that no browser has an excuse to screw up; then add hacks/enhancements separately, targeted appropriately?

  20. Unfortunately clients do as well, if it’s the slightest bit obvious.

    Have you asked clients “why” they think similarities beyond the basics are important? Have you told them “why” there may be slight differences, and what it may cost to level out those differences? I’m not just meaning money here, but also the general regression that often is the result of leveling out minor differences across browser-land.

    Not that I think all clients would care to listen, but some just might. You’ll probably have to give the rest what they ask for/demand - regardless of whether it makes sense or not, so I hope they pay well.

    Maybe I’m not a regular user. Regular users tend to not update their browser until they have to. When they do, then some will expect all web sites to look the same as before, while others will be pleasantly surprised by progressive changes revealed by their new browser.

    The text-shadow example wouldn’t end up as white-on-white anyway from my hand, but that’s not because not all browsers support text-shadow. I would find the readability too low with just the shadow to lift the text, so I would choose another combination for simple accessibility-reasons. One factor I always try to check in all available browsers, is that I’m not needlessly messing with accessibility options that some may need. That will probably weigh heavily in the direction of a better choice of colors in a case like that.
    I haven’t applied text-shadow commercially yet - only been testing it in Safari, so I can’t say exactly what I would end up at.

    The only excuse any browser has for screwing up standards, is that the browser/version is too old and/or discontinued. Hacking the dead is a legitimate activity IMO, as long as new and standard-compliant browsers/versions are not being disturbed by the activity.
    So, my baseline is the browsers with the best support for standards at any one time.

    As mentioned earlier: ‘absolute minimal use of hacks/filtering for older browser-versions just to keep things working, may be acceptable’. I know the bug-house and lack of standard-support too well to say otherwise, and I hack old and weak browsers all the time. Minimally and carefully on commercial work, but quite excessively on my own site.

    General ‘versioning’ - HTML or CSS - is ‘a trap’ I rather not see being pushed forward. Versioning will simply be too easy to use, so having versioning in a “standardized form” will leave the scene wide open for careless use and abuse.
    I’ve started “shutting down” the use of ‘conditional comments’ for IE/win, which I call “an ugly hack”, as often as I can - which means almost always in my own work. I prefer to hack/filter (call it what you like) the discontinued versions through both valid and non-valid CSS.
    Non-valid CSS-filtering is especially useful, since both the validator and other web designers can point out such filters for me if I forget what I did, where :-) Non-valid CSS-filters also tend to disappear/be fixed in later versions, which is an added safeguard against failure.

    Since this is an article about the future of CSS hacking, I have to say once again that the future looks brighter than ever for ‘solid hack strategies’. Other ‘hack/filtering’, ‘non-hack’ or ‘all valid’ strategies may not be that ‘solid’ though, as they will always be subject to a larger degree of changes in order to keep up with progress in browsers and standards.
    Guess the ‘solid’ part has to do with the level of knowledge about standards and User Agents, and I hope no-one stop learning more, regardless of which strategy they choose to follow. Hacking browsers is a dirty job, but I think we’ll have to keep on adding some of those carefully selected hacks at times, for as long as there are such a thing as browsers.

    Let’s just call a ‘hack’ a ‘hack’, and stop purifying some of them by calling them something else.

  21. I’ll give up my “* html” when they prise it from my cold, dead hands. Well, maybe not that extreme, but I’ve yet to see an argument that convinces me it’s worth cluttering up every page of my site with CCs and splitting my CSS up into multiple files just to sort a few bugs in an soon-to-be-outdated browser in the currently fashionable manner.

    I don’t need to serve up a great deal extra to IE5/6, just the odd tweak here or there. When I do, “* html” remains a great way to target those browsers.

    IE7 will ignore “* html”, so it gets the same CSS as the grown-ups. Can it handle it? Nobody knows, as it hasn’t been finished yet. I’m not losing any sleep - still less restructuring my whole approach to CSS - over a piece of beta software. When it gets close to release, I’ll see what (if anything) needs doing.

  22. IE7 is apparently ‘layout complete’: “I was also happy to announce that we are now layout complete with the release of the MIX build” Annouced on the IE blog

    Yes it will ignore * html, in fact it matches FF/Safari/Opera on all the filters on Centrical’s list.

    However, I’m still getting peekaboo bugs (not so often, but enough). How do you fix that without a CC?

  23. Regarding IE7 and its remaining bugs…

    How do you fix that without a CC?

    If IE7 is as ‘layout complete’ as they say, then the *+html is an option. There’s also the @import hack which is nice for serving whole stylesheets to all Trident-based browsers.

    Whether or not these hacks are reliable “tomorrow” is another matter. Anyway, it looks like IE is as buggy as ever, so we’ll either have to use the CC hack or some other hack to get around it.

  24. Just like the original article says, most 21st Century browsers don’t need any hacks for layout provided you keep their limitations in mind. Learning these limitations comes with experience.

    Browsers with worse implementations than IE5.5/Win are too poor to handle modern CSS layouts. IE4.01/Win can go mental even with simple presentational properties. These 20th Century browsers don’t support enough of CSS for it to be useful in them. Giving them an unstyled page is probably the best you can do with them. By using semantically meaningful markup, users will still have an entirely usable and accessible experience.

    When you begin to code a layout, you should test in as many browsers as possible right from the start. Each time you find a non-trivial difference, investigate it methodically to find out its exact cause. You can then try alternative methods of producing the same effect until you find some which work. You can then test each of these methods in other browsers, eventually finding one which works well in them all.

    Each time you do this, you gain priceless experience about how 21st Century browsers handle CSS layouts and presentation. This experience means you will find cross-browser solutions more easily next time.

    Complicated layouts can be produced by intelligently nesting simple layout techniques. If you have enough time to be methodical enough, the article is right: It really is surprising how rarely you need to hack. :)

  25. May 23, 2006 by gary turner

    However, I’m still getting peekaboo bugs (not so often, but enough). How do you fix that without a CC?

    Actually the Peekaboo bug is very manageable without any sort of filter. Making the parent and the float position relative is generally the most stable fix. There are other fixes that don’t require any filtering.

    I’ve stolen Big John’s example and applied the various fixes. See Peekaboo tests.

    Were I you, I’d check to see which fix you’ve applied inadvertantly in those cases where it doesn’t rear its ugly head. So that’s one that didn’t get fixed in IE7?

    Just because various hacks are necessary does not mean they all must be hidden or somehow filtered.



  26. Well, now that IE7 is almost out I can safely say that CSS hacks aren’t going away anytime soon. Thankfully, they will finally be down to a bare minimum once IE6 starts to disappear and we can justify our sites looking worse in IE5/6 (like with Netscape 4).

    Unfortunately, IE7’s Quirks mode is basically IE6, so some authors might find the need to continue on with CSS hacks; let’s just hope that no one uses this as an excuse to just lazily keep developing IE6-centric pages! That would certainly be tragic.. it’s far too easy to drop IE7 into Quirks mode, just use an SGML comment at the top of the markup.. that is a far simpler “fix” for lazy developers than properly testing in IE7 and making their sites more compliant :(

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.