CSS and Internet Explorer: To Hack or Not To Hack?

[toicontien]

We see discussions every once in a while about table-based layouts versus CSS and DIVs, but I haven't seen a thread about the benefits and disadvantages of using CSS hacks, or filters. Let that be this thread

First and foremost, I want this to be educational and a discussion utilizing facts. Link to articles, studies, etc. If you post something that's not backed up with facts, point out that it's your opinion. And opinions are welcome, but I don't want this to degrade to a fist fight. That said...

What is a CSS hack?

Simply put, a CSS hack, sometimes called a CSS filter, is writing CSS styles that take advantage of browser support for style sheets and bugs in how browsers read style sheets. You give one browser a certain property and value, then use some sort of hack to give another browser a different value. A small example is in order.

.foo {
 color: red;   /* Hide from IE5-Mac: \*/
 color: green; /* End IE5-Mac hiding */
}

This particular hack takes advantage of an Internet Explorer 5/Mac bug where the backslash character escapes the following character. To IE5-Mac, the asterisk after the backslash simply doesn't exist. The CSS comment remains unclosed in IE5-Mac until the next occurrence of "*/" -- effectively hiding the color: green; property and value. IE5-Mac shows red text. All other browsers show green text.

Why are CSS hacks used?

Certain browsers *cough* Internet Explorer *cough* have bugs in how they support cascading style sheets. Sometimes the browser was simply programmed wrong. In either case, a CSS hack is used to correct differences in how certain browsers render the same CSS.

What are the advantages of using CSS hacks?

* Allows you to write one CSS file that works in all browsers

* Fewer CSS files to download means fewer trips to a busy server, which means the page will load faster (and it's less stress on a busy server).

* With care, hacks can be written to prevent problems with future versions of a browser.

* One CSS file is easier to update.

What are the disadvantages of using CSS hacks?

* You may run into problems with future versions of a browser.

* Sometimes the hacks use proprietary CSS properties.

* A hack for one browser may be recognized by a future version of a different browser, effectively breaking the style sheet.

* Hacks can add unneeded bulk to a style sheet.

* Multiple hacks can be a nightmare to interpret in the future.

What are the alternatives to using CSS hacks?

Since hacks are almost always written to get Internet Explorer to behave properly, a good alternative is using conditional comments that are only recognized by Internet Explorer, and allow you to import IE-only style sheets that contain the styles needed to get Internet Explorer working.

Then you've got your main style sheets that all browsers import. CSS is written to specification. The style sheets imported using conditional comments contain all the incorrect values that IE needs in order to function. But then you've got two style sheets where there only used to be one.

My thoughts on CSS hacks

Hooray for hacks. I don't like going hack crazy, mind you. But I won't shy away from a hack if it gets the job done. My prefered method is to use as few hacks as possible. Since most IE-Win bugs can be cured by invoking the hasLayout property, I tend to give things set widths and not just relying on a block element taking up the correct width. If a width doesn't work, I use the proprietary Internet Explorer property and value zoom: 1;

I admit. I used to employ the Holly Hack quite a bit, but with Internet Explorer 7 not supporting the star-html hack, and supporting the child selector, the Holly Hack will become useless. In hindsite, I wish I hadn't used it. But zoom: 1; seems harmless, and probably always will be. Right? Right? Tough decision.

Now, I'd like to know all of your thoughts.

[felgall]

There is definitely no longer a need for Mac IE5 hacks. Microsoft stopped updating that browser back in the dark ages and then killed it off completely back in 2003. There are so many things with modern web page design that IE5 can't handle that there is often no way to get modern web pages to display properly in that long dead browser even with hacks.

[toicontien]

I used the IE5-Mac hack as an easy example, not that we should support an old browser that isn't developed anymore. It was just the easiest hack I could come up with.

[Vladdy]

I wrote a css preprocessor that puts out browser targeted CSS.
I found it cuts my development time since I can use a more readable syntax and not worry about how hacks will be interpreted by future releases. My source file looks like this: http://klproductions.com/styles/screen.xcss
and after preprocessor takes care of it:
http://klproductions.com/klcsspp/klc...es/screen.xcss
As you can see from the profiling data, the processing time is negligible

The way the preprocessor directives are structured, the compliant CSS is put out by default (if browser is not recognized). The special branches are made for misbehaving clients.

Also, even though I did not use that feature much with this particular stylesheet, the preprocessor allows me to do defines so that things like colors can be easily changed on a single line without having to go through the code:
$define _PRIMARYCOLOR #cef
$define _SECONDARYCOLOR #123

#block1
{ border: solid 3px _PRIMARYCOLOR;
background: _SECONDARYCOLOR;
}

#block2
{ backgroung: _PRIMARYCOLOR;
}

... but that is going a bit off topic

[Stephen Philbin]

I don't really use hacks for fear of them having an adverse effect is future browsers. I also considered preprocessing css too, but gave up on the idea about 6 seconds in to having the thought when I remembered IE pretty much ignores the http protocol and so would probably wig out as soon as you presented it with a file that didn't end in .exe|.html|.pmg|.css etc., regardless of you telling it directly that the file is text/css.

So I just tend to avoid using margins as much as possible and try to make IE's incompetence look more like a design "feature" than a ****up.

[Jeff Mott]

I've come to prefer hacks over conditional comments, mainly for the "one CSS file is easier to update" reason. It's much easier to keep styles organized in a single place rather than spread out over multiple files. The underscore hack is quick and easy and affects only IE6. e.g.,

.some-selector {
	background-image: url(/images/semi-transparent-pic.png);
	_background-image: none;
	_filter: progid:DXImageTransform.Microsoft.AlphaImageLoader(src="/images/semi-transparent-pic.png");
}

The * + html selector will target only IE7. This one is a little less convenient since you need a separate rule set, though it's rarely needed. Usually the only issue with IE7 is hasLayout, and as toicontien pointed out, zoom: 1 takes care of that, and it's harmless to any other browser.

The only decent argument to not use hacks is that some future browser may regress and have the same underscore bug as IE6, or the same mysterious root element as IE7. But if we step out of the theory room, I'm sure we'll all know how extremely unlikely that is. I don't think we need to sacrifice code clarity or organization for something that will likely never happen.

[Jeff Mott]

Hahaha. I followed a link to this thread but I didn't check the dates of the posts. Looks like I'm a couple years too late to this discussion.

[felgall]

Does anyone still use the Netscape 4 hack

.foo {
 color: red;   /*/*/
 color: green; /* */
}

where Netscape 4 will display red text and all other browsers will display green?

[toicontien]

Does anyone still use Netscape 4?

But if you want to support Netscape 4, import your advanced style sheets using the @import directive in the STYLE tag, and then import the NS4 style sheet using a LINK tag. NS4 doesn't supporting importing style sheets using the @import directive.

<link rel="stylesheet" type="text/css" href="ns4.css">

<style type="text/css" media="screen">
<!--
@import "advanced.css";
-->
</style>

Of course in all your other style sheets, you need to override the styles declared in ns4.css.

[felgall]

Does anyone still use Netscape 4?

But if you want to support Netscape 4, import your advanced style sheets using the @import directive in the STYLE tag, and then import the NS4 style sheet using a LINK tag. NS4 doesn't supporting importing style sheets using the @import directive.

<link rel="stylesheet" type="text/css" href="ns4.css">

<style type="text/css" media="screen">
<!--
@import "advanced.css";
-->
</style>

Of course in all your other style sheets, you need to override the styles declared in ns4.css.

I know that. The /*/*/ to /* */ NS4 comment hack is a lot simpler though particularly if you just want to make sure that your styles don't stop the content from still being viewable by the couple of people who still use that browser.

Hacking for browsers that predate the browsers that mostly support the standards was the easiest way to get the page to work in all of them. Now that the least compliant browser with any significant use is IE6 using conditional comments is just as easy as the alternatives.

[ehime]

To beat a dead horse, what I do with my webpage is create a custom PHP script
that returns user unique code depending on browser, format, screen depth. This
ensures that EVERY user has a unique experience, and also can guarantee that
each viewer will see exactly what they are supposed to see. This has the benefit
of identifying a browser, version, and client with out becoming obstructive. It
also allows us with custom tailored code server end to make sure we don't have
to send extra information if its not needed, keeping things relatively lightweight
and server intensive, not end user intensive. my 2c.

This is a great idea IMHO until there is one browser to rule them all which
is likely never.

[toicontien]

Unfortunately with this approach, you rely on the user agent string of the browser, which can be spoofed. Safari, Opera and I believe Firefox allow you to do this. The browser ID'd by the user agent string might not actually be the browser the user is using. Furthermore, what happens when a totally new browser or operating system is released? You've got to change your browser detection algorithm, and this becomes unmaintainable very fast.

Instead, you want to use conditional comments for IE hacks. Above all else, write CSS and HTML to W3C spec's. Then you only need to deal with browser bugs and not code bugs too. Specify the media for which a style sheet should be used.That way you can have completely different web site layouts for screen (desktop computer), handheld (Opera Mobile, Safari on iPhone), print, and many more media.

[aj_nsc]

In my opinion, designs that are complex enough that absolutely require hacks/conditional comments can probably be made simple enough so that they don't. It takes a bit of work, and it may take some very slight compromise, but from my experience, with a little bit of time neither hacks nor conditional comments are needed to get a design to render properly in all (i.e. IE6-8, FF2-3, Opera and Safari) browsers.

[toicontien]

In my opinion, designs that are complex enough that absolutely require hacks/conditional comments can probably be made simple enough so that they don't. It takes a bit of work, and it may take some very slight compromise, but from my experience, with a little bit of time neither hacks nor conditional comments are needed to get a design to render properly in all (i.e. IE6-8, FF2-3, Opera and Safari) browsers.

Try to get Motortopia.com to render correctly in IE without hacks.

And every design element should be exactly the same and function exactly the same.

[slaughters]

...it may take some very slight compromise...

Ahhh the word *not* found in most Art Director's (or Marketing Manager's) vocabulary !