{"id":104,"date":"2005-06-16T13:54:28","date_gmt":"2005-06-16T11:54:28","guid":{"rendered":"http:\/\/www.maratz.com\/blog\/archives\/2005\/06\/16\/essentials-of-css-hacking-for-internet-explorer\/"},"modified":"2011-05-19T11:18:43","modified_gmt":"2011-05-19T10:18:43","slug":"essentials-of-css-hacking-for-internet-explorer","status":"publish","type":"post","link":"http:\/\/www.maratz.com\/blog\/archives\/2005\/06\/16\/essentials-of-css-hacking-for-internet-explorer\/","title":{"rendered":"Essentials of CSS Hacking For Internet Explorer"},"content":{"rendered":"

The summary of our<\/a> latest project<\/a> client-side development brought to conclusion that there\u2019re 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<\/a> 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\u2019s quite possibly half-repaired CSS support<\/a>.<\/p>\n

Conditional Comments<\/h3>\n

The alpha and the omega of IE hacking are IE\u2019s conditional comments<\/a>. They are IE-only feature and they\u2019re not supported by any other browser. For other browsers they are just an ordinary comments and therefor, they are safe to use.<\/p>\n

The typical usage is as follows:<\/p>\n

<!--[if IE]>\r\n    do something\r\n<![endif]--><\/pre>\n
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:<\/p>\n
<!--[if lte IE 6]>\r\n    do something\r\n<![endif]--><\/pre>\n
which means: \u201cif this is Internet Explorer less than or equal to version 6<\/strong>, do something\u201d. My thoughts are\u2013if they keep conditional comments feature in IE7, then the browser will ignore this, since it\u2019s 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.<\/p>\n
When I work on a layout I usually place all hacks for some selector immediately after its\u2019 default rule. This way, changes can be done quickly and without searching for the corresponding hack in other places.<\/p>\n
After I\u2019m 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.<\/p>\n
<!--[if lte IE 6]>\r\n    <link rel=\"stylesheet\" type=\"text\/css\" href=\"ie_hacks.css\" \/>\r\n<![endif]--><\/pre>\n
While still in main CSS file, hacked selectors start with * html<\/code>. This is known as the \u2018star-HTML\u2019 hack. Standard compliant browsers ignore this selector, because there\u2019s actually  no elements above html<\/code> in a document tree. Luckily, IE doesn\u2019t know that and we\u2019re 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\u2019s safe to remove the * html<\/code> part.<\/p>\n
Further on in the text, assume that we are dealing with separate file with IE hacks only.<\/p>\n
Backslash hack for IE 5.x broken box model<\/h3>\n
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.<\/p>\n
someselector {\r\n    padding: 10px;\r\n    width: 200px;\r\n    w\idth: 180px;\r\n    height: 200px;\r\n    heigh\t: 180px;\r\n}<\/pre>\n
This will give as an element which is 200px wide, 200px high and with 10px paddings in both IE 5.x and IE 6.<\/p>\n
If floated and with margin, display: inline<\/h3>\n
Everything that is floated and has any margin larger than zero, should have additional rule display: inline;<\/code>. Simple as that.  More about the \u2018Holly hacks\u2019 read at P.I.E.<\/a>.<\/p>\n
Overflow problems<\/h3>\n
Italic font style in any IE version will enlarge parent element horizontally. It\u2019s usually just a few pixels, but it could be nasty and ugly few pixels. Simple solution is in the following rule:<\/p>\n
someselector {\r\n    overflow-x: hidden;\r\n}<\/pre>\n
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\u2019s editors, it\u2019s better to prevent content slips out of it\u2019s boxes. A small digression\u2013editors are sometimes inexperienced, but it\u2019s not their job to know every HTML element and that\u2019s why adequate support in their few first attempts is essential. There\u2019s no worst for the guy who manage the content on his company\u2019s 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\u2019s our responsibility to keep his confidence intact.<\/p>\n
Font size in tables in IE 5.x<\/h3>\n
Font rules set in html<\/code> or body<\/code> element are ignored in tables in case of IE 5.x. Again, simple addition will take care of it.<\/p>\n
body {\r\n    font-size: 62.5%;\r\n}\r\ntable {\r\n    font-size: 1em;\r\n}<\/pre>\n
Later in a process, you can change rules according to a particular table\u2019s needs.<\/p>\n
To conclude…<\/h3>\n
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?<\/p>\n
Related Reading<\/h3>\n