If you are reading this, please get modern browser.
skip to main content | skip to main navigation | skip to secondary content

Essentials of CSS Hacking For Internet Explorer

~ 16th June 2005. · 13:54 CET · permanent link · printer friendly ~

The summary of our latest project client-side development brought to conclusion that there’re are really just a few essential Internet Explorer hacks. By careful structure planning, I managed to stripe down all hackery to a much less additional rules. Since they are promising IE7 some time soon, more and more I think about secure CSS hacking. We surely don’t want our sites to be a mess in IE7 for it’s quite possibly half-repaired CSS support.

Conditional Comments

The alpha and the omega of IE hacking are IE’s conditional comments. They are IE-only feature and they’re not supported by any other browser. For other browsers they are just an ordinary comments and therefor, they are safe to use.

The typical usage is as follows:

<!--[if IE]>
    do something
<![endif]-->

Untill now I used to write something like above, which applies to all versions of Internet Explorer, i.e. 5.01, 5.5 and 6.0, but since the latest announcements, I started applying the following condition:

<!--[if lte IE 6]>
    do something
<![endif]-->

which means: “if this is Internet Explorer less than or equal to version 6, do something”. My thoughts are—if they keep conditional comments feature in IE7, then the browser will ignore this, since it’s version designation number is 7. On the other hand, if they abandon that feature, the browser will assume that this is just another HTML comment.

When I work on a layout I usually place all hacks for some selector immediately after its’ default rule. This way, changes can be done quickly and without searching for the corresponding hack in other places.

After I’m done with layout, I like to go through all of the CSS files once again and optimize everything from short-hand properties to assigning the same rule for multiple selectors. At that point all hacks are removed to separate file(s), so the main CSS is clean and tidy. This separate file is then called in the header section of a file within conditional comments.

<!--[if lte IE 6]>
    <link rel="stylesheet" type="text/css" href="ie_hacks.css" />
<![endif]-->

While still in main CSS file, hacked selectors start with * html. This is known as the ‘star-HTML’ hack. Standard compliant browsers ignore this selector, because there’s actually no elements above html in a document tree. Luckily, IE doesn’t know that and we’re safe to use this flaw when applying IE specific hacks. Once we move hacks to a separate file and call it in a document with conditional comments, it’s safe to remove the * html part.

Further on in the text, assume that we are dealing with separate file with IE hacks only.

Backslash hack for IE 5.x broken box model

A combination of width and padding on the same element is very well known to produce broken layouts in IE 5.x. Box model hack is widely used and can be stripped down to a few lines.

someselector {
    padding: 10px;
    width: 200px;
    w\idth: 180px;
    height: 200px;
    heigh\t: 180px;
}

This will give as an element which is 200px wide, 200px high and with 10px paddings in both IE 5.x and IE 6.

If floated and with margin, display: inline

Everything that is floated and has any margin larger than zero, should have additional rule display: inline;. Simple as that. More about the ‘Holly hacks’ read at P.I.E..

Overflow problems

Italic font style in any IE version will enlarge parent element horizontally. It’s usually just a few pixels, but it could be nasty and ugly few pixels. Simple solution is in the following rule:

someselector {
    overflow-x: hidden;
}

I tend to apply that rule to every major column in a layout, especially in the period right after site launch. For the first week or two, when the large amounts of content are added and removed day and night by the site’s editors, it’s better to prevent content slips out of it’s boxes. A small digression—editors are sometimes inexperienced, but it’s not their job to know every HTML element and that’s why adequate support in their few first attempts is essential. There’s no worst for the guy who manage the content on his company’s brand new, ultra-modern and expensive web site, than the massive layout breakage when the site is still fresh and under the eyes of CEO. It’s our responsibility to keep his confidence intact.

Font size in tables in IE 5.x

Font rules set in html or body element are ignored in tables in case of IE 5.x. Again, simple addition will take care of it.

body {
    font-size: 62.5%;
}
table {
    font-size: 1em;
}

Later in a process, you can change rules according to a particular table’s needs.

To conclude…

CSS hacks are necessary evil, but with defensive approach, we can make sure they safely co-exist with default CSS rules, even in future browsers. What are your thoughts?

Related Reading

30 Comments

  1. gg!1
    very nice summary, i think i’m gonna use your permalink :)

  2. Isn’t this a sweet post folks? Thanks.

  3. Nice summary marko. I’ve never come across the overflow issue, so will definitely be aware of that one. Thanks!

    I have tended to stick to pretty much the same rules, though IE 5.01 at times can be a lost cause!!

    Btw, about the rule display: inline. Have you ever had problems with divs that have a float and margin top, right or bottom applied?

    I have only ever experienced that problem with a float: left and margin-left applied to a div, and thats when I tend to apply display: inline.

  4. Up until yesterday, I used to be concerned with IE hacks. But after I read this, I decided not to care. Do I worry about what clients will say when I tell them I don’t support IE in my designs? Yes, I did the analysis and decided “it was worth it.”

  5. @ medo: IE 5.01 has one extremely annoying bug and that is unsupported padding for inline elements.

    According to P.I.E.’s The IE Doubled Float-Margin Bug explanation, display: inline; is only needed if we have margin at the same side where the element is floated to, but in a few multi column layouts with several nested floating elements I have experienced weird behaviors if I missed to set display: inline; workaround, even if there was just the bottom or top margin.

  6. Thanks for clearing that one up Marko.

  7. That display:inline hack is a real life saver. I find that it hs cut down my need for the * html hack significantly, as I no longer have to feed different different margins to IE. And how many divs do you float with side margins? I’ll sometimes have 5-6 on a single page!

  8. Thank you! This is great man, I’ll definitely be coming back to check this out again.

    I posted this on my blog.

  9. Indeed, a nice summary. Off to the bookmarks! Thnx!

  10. Very concise and useful writeup Marko! I’ll be linking. Thanks!

  11. Your write up on the “Backslash hack for IE 5.x broken box model” doesn’t mention that IE6 when given a correct doctype will actually use the correct box model and this hack will break it.

    Also as far as I was aware you can’t put the backslash before an “i” - there are certain letters that mean something else when escaped.

    Plus I thought the backslash hack only worked in IE6 and the underscore hack worked in IE5+.

    I would be greatful for some user tests and clarification on these things. I don’t have IE5 so I can’t check it.

  12. @Jon B: IE 5.x will render width: 200px;, but will fail to recognize w\idth: 180px;. IE 6 on the other hand doesn’t have problems with backslashes inside property name, so it will render 180 pixels, since it’s the last rule for width property.

    I never worked in quirks mode, so I wouldn’t really know.

    Underscore hack is not valid CSS. Backslash is.

    User testing is usually for usability issues, browser testing is for browser issues.

    You can download standalone versions of Internet Explorer from skyzyx.com.

  13. I usually use * html .mystyle { } for IE specific styles.

  14. I rather use the Shaun Inman’s trick with the div[id=idname] (that IE does not support) to write the non-IE code, and then adding !important instruction to make non-IE instructions prevail with the other browsers :) it’s nice and cool, because IE does not support also the !important instruction so he reads only the “standard” instructions. :) clear? Try it at: http://www.csszengarden.com/?cssfile=057%2F057%2Ecss

  15. @Tunnuz: IE does support !important rules.

  16. I was always under the impression that IE did not support !important rules.

  17. Nice summary. Any argument on backslash hack vs underscore hack ?

  18. @Wayne M: IE don’t support !important in the following scenario:
    someselector {
    property: value !important;
    same-property: another-value;
    }
    It will always take the last value set for the same property within same set of rules. Apologies for not being precise.

  19. Marko, Jon B and Ozh: underscore hack

    The underscore hack fails the W3C CSS validator, but in spite of that, it IS valid CSS. According to the CSS 2.1 specification (clause 4.1.3) the initial underscore is permissible in identifiers:

    “In CSS 2.1, identifiers (including element names, classes, and IDs in selectors) can contain only the characters [A-Za-z0-9] and ISO 10646 characters U+00A1 and higher, plus the hyphen (-) and the underscore (_); they cannot start with a digit, or a hyphen followed by a digit. Only properties, values, units, pseudo-classes, pseudo-elements, and at-rules may start with a hyphen (-); other identifiers (e.g. element names, classes, or IDs) may not.”

    This freedom allows for the creation of vendor-specific extensions, as in clause 4.1.2.1 of the specification, which is likely why the validator does not recognise the construction even though it is permitted by the spec.

    The hack is explained neatly here.

    As always, there are considerations when using one browser bug to solve another, as Simon Willison points out here.

  20. Keith, thanks for you insight. However, I must disagree that _property: value; is correct, because then the p_r_o_p_e_r_t_y: value; would be correct also, and IE wouldn’t ignore it.

    From what you have quoted, it does’n say we can write CSS properties whatever way we want, it just says about which characters certain elements can contain of. This means that property -moz-radius has correct charset, even though it’s not w3c recommended property.

  21. !important is supported by IE, just not in the way that it should be and hence it can be exploited. Also the underscore hack is valid but only with the _ at the beginning as I understand it.

  22. Marko, Jon B: underscore hack

    In practice, Jon B is correct. Bear in mind that, for example, _width: 100px is not the same as width: 100px. When writing _width: 100px, you are in effect creating a new property, _width, following rules allowed by the specification for valid characters and their position. But as it is neither standard CSS nor a recognised vendor-specific property, it is simply ignored by compliant browsers. However due to a bug in IE5+/Win, it does not “see” the initial underscore, and reads it as width: 100px instead of _width: 100px and sets the width of the element accordingly.

    Another salient part of the CSS 2.1 spec, from clause 4.1.2:

    “An initial dash or underscore is guaranteed never to be used in a property or keyword by any current or future level of CSS. Thus typical CSS implementations may not recognize such properties and may ignore them according to the rules for handling parsing errors. However, because the initial dash or underscore is part of the grammar, CSS2.1 implementers should always be able to use a CSS-conforming parser, whether or not they support any vendor-specific extensions.”

  23. Keith, thanks for clearing things out.

  24. Conditional comments really have been a lifesaver for me. Another very helpful technique, is the mid-pass filter. You can put the one for IE5/Win inside of the document you reference in your conditional comment for “lte IE 6″, and save a little space in your HTML document, and the one for IE5/Mac is the only way to go for that browser.

  25. Nice summary :)

    IE’s support of !important is for overwriting inline styles, so as long as u have separated all the css, IE won’t ever appear to take any notice of !important.

  26. I’d just like to say a big thank you! I think this is definately the best and easiest to understand summary of hacks I’ve read.

  27. I know, and that’s the trick! Try displaying the page I provided to you and see by yourself how it works!

  28. The write-up is excellent. (My last comment sounded cynical, but was not intended to be negative.) I’ve fixed one of my IE bugs using the “magic bullet” described here (I know I said I would “boycott", IE…but I was just exaggerating.) Your post could not have come at the most opportune time! Thank you!

  29. A really useful concise article. Looking ahead, it would be helpful to add a follow-up when we have had a chance to play with the first preview versions of Internet Explorer 7, seeing as the arrival of this product will transform the landscape of hacks.(The ‘hackscape’? Would that be a useful new coinage?)

  30. Thanks, I’ve been looking for such a summary for a loooooong time now. I am willing to add it to my “Web-Dev-Bookmarks”. Thanks!

Sorry, the comment form is closed at this time, but if you have anything to say, please send me a message.

* Please keep in mind that this is a personal web site and it does not reflect the position or opinion of my respective employers, organizations or partners.

Typetester – compare screen type Supported by Veer.

What is this?

A web log of Marko Dugonjić, web professional from Croatia. Topics covered:

Translate this site

German, Spanish, Italian, French or Japanese (via).

See you there!

Feel like buying a book?

Try with maratz.com aStore

Personal Network

.HR Community

Public profiles

mi3, QBN, Flickr, Last.fm, LinkedIn, Coolinarika, Croportal

Worth visiting

top of the page | skip to main content | skip to main navigation | skip to secondary content