OpenIDThe underscore hack
Via Web-Graphics, Petr Pisar’s Underscore Hack provides a new way of targetting CSS rules specifically at Internet Explorer on Windows. As with all such hacks, the pros and cons of using this approach need to be closely examined before deploying it. The hack takes advantage of the fact that adding an underscore to the start of a property name causes that declaration to be ignored by every browser except IE for Windows. However, the hack takes the dangerous step of using one bug to solve another. Peter-Paul Koch explained why this is a risky thing to do in a recent column for Digital Web magazine:
A certain browser has a certain CSS bug. Good to know. This same browser has another bug, usually in its parsing of CSS selectors or comments. This, too, is important information. However, a CSS hacker proceeds to use the second bug to “solve” the first one.
Solving one bug by another is not my idea of keeping Web development simple, but the matter goes beyond bad coding style. These hacks are inherently unsafe.
In an ideal world the next release of the browser would solve both bugs. In an uncaring world the next release of the browser would solve neither. In the uncertain world we live in the next release could solve one bug but not the other!
Therefore you could end up with a hack that applies an extra rule you no longer need, or with a necessary extra rule that isn’t applied any more.
In my opinion, hacks like this are safe for use on sites that are being actively maintained. If you use them in a “fire and forget” project you could well find it breaking in new browsers in a few years time, when the site is no longer being maintained but remains online and broken for all to see. If on the other hand you use it for a living, breathing site such as a constantly changing commercial project or a personal weblog errors that crop up in future browsers can be taken on as and when they appear.
When all is said and done, a large proportion of hacks in use today exist to combat the infamous box model problem—and the best advice for coping with that can be found on Dave Shea’s CSS Crib Sheet: Try to avoid applying padding/borders and a fixed width to an element
. Do that, and box model hacks just stop being necessary.
I have always avoided using CSS hacks, including those that solve box model issues. Rather than resorting to hacks, I would rather add a non-semantic element (like an extra
div) to control widths, for example.The best approach, presumably, is to try and convince clients of the value of rules-based design, like that proposed by Jeffrey Zeldman. Trying to make a document look identical in all browsers is bound to cause headaches, but clients still demand it. Maybe I'm foolish to hope for a change, but I will continue doing my best to promote it anyway.
Simon Jessey - 23rd November 2003 04:19 - #
I like the active maintenance argument. Yes, in your personal site you can probably get away with CSS hacks, as long as you remember them all, and their purposes.
You're probably right that most CSS hacks serve to solve box model problems. Nonetheless I'm not so sure that leaving out either padding/border or width is desirable from a design point of view. A well designed block needs both.
ppk - 23rd November 2003 14:10 - #
In most cases, you can avoid the issue by simply wrapping the block in another. Use one block to control the padding/border and the other to control the width. To my mind, this is a less painful compromise than using one of the box model hacks.
Simon - I tried putting the above quote into a
blockquoteelement, but your comment system barfed on it, saying it contained raw character data. It has no such trouble when I wrap it in aqelement. Is it supposed to do that?Simon Jessey - 23rd November 2003 14:25 - #
Well, according to the HTML 4.01 DTD, blockquote may not contain raw character data as direct children - it may only contain block elements or the script element.
<!ELEMENT BLOCKQUOTE - - (%block;|SCRIPT)+ -- long quotation -->As for the hack, why use an invalid hack that relies on a browser bug when you can use valid css instead, using * html? Or why not use the fact that iew doesn't support advanced CSS2/2.1/3 selectors?
Finally, as for when to use hacks, my personal opinion is that there is a difference between hacks - some use invalid css, some use browser bugs with valid css, and some use valid css that is not yet supported by a browser. These are as I see it mentioned in a worse to better order - a "hack" that neither is invalid nor relies on the client to not handle the css grammar correctly, is pretty well built considering future compatibility, because if the one feature has been added, there is a large potential of the other feature to have been added as well. You can usually single out browsers by feature support alone, instead of by browser bug. A hack targetted at a browser that will not evolve, such as a former version of a browser still being developed, or any version of a browser that is discontinued, can be relied upon, but a hack targetted at a current browser on which development is still being made is not a good idea...
liorean - 23rd November 2003 21:13 - #
stylo~ - 24th November 2003 03:44 - #
jdfjf - 3rd May 2005 15:25 - #
Cathy - 24th July 2005 15:27 - #
I just got this site URL from a designer who args that hacks allows him to got same presentation through different browsers and that hacks are perfect CSS syntax.....
Unfortunately, it does'ny work properly. And what could be acceptable for a personal site is completely unacceptable from a professional point of view.
WMaintenance and consistency are more important for a client compared to some minors différences between all browsers. And finally Standard CSS solutions exist but pro designers take that in account in web site architecture.
Many web designers start coding first and finaly discover at the end that their design gives problems with different browsers. And to avoid redesign prefer to use hacks.
Claude - 21st March 2006 17:26 - #