标签：
In defense of CSS hacks — introducing “safe CSS hacks”Published 19th May 2011 · tagged with CSS, HTML
How do you target Internet Explorer in your CSS? Do you use CSS hacks, conditional stylesheets or something else?
It’s the perfect trollbait. There have been plenty of discussions about this, and I don’t mean to start a new one. Everyone’s entitled to their own opinion, but the thing is that it’s not purely a philosophical matter. I am writing this article because I noticed there’s a lot of misunderstanding on the subject of CSS hacks.
People have been advocating three different approaches: conditional stylesheets, CSS hacks, or conditional classnames. All these techniques have their pros and cons. Let’s take a look.
Conditional comments make it very easy to specify stylesheets that should only be loaded in Internet Explorer, or even in specific versions of that browser. Non-IE browsers treat conditional comments as any other HTML comment. Here’s an example:
<!--[if lte IE 8]><link rel="stylesheet" href="lte-ie-8.css"><![endif]-->
<!--[if lte IE 7]><link rel="stylesheet" href="lte-ie-7.css"><![endif]-->
<!--[if lte IE 6]><link rel="stylesheet" href="lte-ie-6.css"><![endif]-->This snippet will cause lte-ie-8.css to be loaded in IE8, IE7, IE6 and even in IE5. (Older IE versions don’t support conditional comments.) In IE7 and older versions, lte-ie-7.css will be loaded as well. In IE6 all three additional stylesheets will be loaded.
If you want to use this technique to style an element differently in specific versions of Internet Explorer, it’d look something like this:
/* Main stylesheet */
.foo { color: black; }
/* lte-ie-8.css, for IE8 and older */
.foo { color: green; }
/* lte-ie-7.css, for IE7 and older */
.foo { color: blue; }
/* lte-ie-6.css, for IE6 and older */
.foo { color: red; }The conditional comments snippet is valid HTML.
Since there’s no need to use CSS hacks, you can even write valid CSS if you want to.
Performance decreases due to the multiple additional HTTP requests, depending on the browser.
Conditional comments block downloads in IE unless another (possibly empty) conditional comment is included earlier in the source.
The total file size increases, since the conditional comments have to be repeated for every HTML single document, and you’ll have to repeat the selector in every CSS file. More typing work!
Maintainability is negatively affected. You now have to maintain four separate stylesheets instead of just one. Whenever you make changes to your main CSS file, you need to remember to change the IE-specific CSS files if necessary.
Those not willing to use CSS hacks can always apply conditional classnames to the <html> or <body>element. This approach allows you to write clean and hack-free CSS at the cost of adding hacksconditional comments to your HTML.
<!--[if lt IE 7]><html class="ie6"><![endif]-->
<!--[if IE 7]> <html class="ie7"><![endif]-->
<!--[if IE 8]> <html class="ie8"><![endif]-->
<!--[if gt IE 8]><!--><html><!--<![endif]-->This allows you to keep your browser-specific CSS in the same file:
.foo { color: black; }
.ie8 .foo { color: green; } /* IE8 */
.ie7 .foo { color: blue; } /* IE7 */
.ie6 .foo { color: red; } /* IE6 and IE5 (but who cares, right?) */The conditional classes snippet is valid HTML. (Prior to HTML5, you would have to add the classes to the <body> element instead.)
Since there’s no need to use CSS hacks, you can even write valid CSS if you want to.
No additional HTTP requests are being issued to get the IE-specific styles.
In this particular case, the conditional comments don’t block downloads.
This technique increases the file size of every HTML document you use it for.
The use of the IE-specific classnames automatically increases the specificity of your selectors, which may not be what you want.
Since you’ll need the classnames in the selectors, you’ll have to use separate CSS rules for IE-specific styles.
The character encoding declaration (e.g. <meta charset="utf-8">) should be placed within the first 1024 bytes of the HTML document. Using this technique, you may cross this limit, especially if you’re adding lots of other attributes to the <html> element (since you’ll have to repeat them inside every conditional comment).
Using conditional comments around the opening <html> tag throws IE into compatibility view unless you set the X-UA-Compatible header in a server-side config.
Simon Pieters reports that using conditional comments before <meta http-equiv="X-UA-Compatible"> causes IE to ignore the <meta>. So again, you’ll need to set the X-UA-Compatibleheader in a server-side config.
Paul Irish maintains a comprehensive list of CSS hacks for various browsers. In reality, you’ll rarely need to specifically target anything but IE. Here’s an overview of the three most popular CSS hacks and which browsers they’re supposed to target:
.foo {
color: black;
color: green\9; /* IE8 and older, but there’s more… */
*color: blue; /* IE7 and older */
_color: red; /* IE6 and older */
}Note the use of the \9 CSS hack. Web developers noticed it could be used to easily target IE8 and older versions, so that’s what they did. But then there was IE9, and as it turned out, the final IE9 release was still affected by this hack (despite my bug report on the matter). All those CSS declarations that were meant to be for IE8 and earlier versions only, now got interpreted by IE9 as well. Needless to say, stuff broke, since IE9 doesn’t need most of the IE8-specific CSS fixes.
This is the perfect example of an unsafe CSS hack.
So what constitutes a “safe” CSS hack? What makes me even think there is such a thing?
Let’s face it — CSS hacks are still hacks. There’s no way to accurately predict how future browser versions will parse these rules. But we can make an educated guess — some hacks are less hacky than others. A safe CSS hack is a CSS hack that:
works in specific versions of a given web browser;
is unlikely to be parsed by all other browsers, including future versions.
Take the _property: value hack, for example. The CSS 2.1 spec says the following:
Keywords and property names beginning with
-or_are reserved for vendor-specific extensions.
A property name is an identifier.
In CSS, identifiers (including element names, classes, and IDs in selectors) can contain only the characters
[a-zA-Z0-9]and ISO 10646 charactersU+00A0and higher, plus the hyphen (-) and the underscore (_); they cannot start with a digit, two hyphens, or a hyphen followed by a digit.
So who’s to say there will never be a property name starting with an underscore character? To quote the CSS3 spec:
Although [the underscore] is a valid start character, the CSS Working Group believes it will never define any identifiers that start with that character.
Both the _property: value and *property: value hacks (as seen in the above code block) are examples of safe CSS hacks. They were discovered, identified as bugs, and patched in a browser update. Since then, it’s very likely that Microsoft and other browser vendors added checks for these CSS hacks to their layout tests, to make sure no new browser version is shipped with a regression this significant.
If you discover a CSS hack in the latest version of a certain browser, it won’t be a safe hack until an updated version of that browser is released where the parser bug is fixed. For example, some people (myself included) have been looking for an IE9-specific CSS hack. Recently, one was found, but we’ll have to wait at least until the final IE10 release to use it, because IE10 may or may not be shipped with the same CSS parser bug. We can’t risk repeating the history of the \9 hack.
You don’t have to add conditional comments to every single HTML page.
No additional HTTP requests are being issued to get the IE-specific styles.
The specificity of your CSS selectors is preserved.
There’s no need to repeat CSS rules — you can just add extra declarations (with the hacks) to the declaration block.
They’re called CSS hacks for a reason — only use safe CSS hacks.
There’s no safe CSS hack for IE8 (yet?).
Contrary to conditional comments, most CSS hacks don’t validate. But then again, CSS3 properties and vendor-prefixed properties don’t validate either.
Safe CSS hacks are preferable to conditional stylesheets or classnames, but what if you have to write IE9-specific styles? By definition, there won’t be a safe CSS hack for IE9 at least until IE10 is released. Also, what about IE8? There is no safe CSS hack (that I know of) that targets IE8 but not IE9. What to do?
In the HTML, we can use a minimal version of the conditional classnames technique, like so:
<!--[if lt IE 9]><html class="lte-ie8"><![endif]-->
<!--[if gt IE 8]><!--><html><!--<![endif]-->We can then use .lte-ie8 as a styling hook in CSS selectors to target IE8 and older versions. Combined with safe CSS hacks, we can finally target IE8 and older versions without also affecting IE9:
.foo {
color: black;
}
.lte-ie8 .foo {
color: green; /* IE8 and older */
*color: blue; /* IE7 and older */
_color: red; /* IE6 and older */
}This technique combines all the advantages of safe CSS hacks and conditional classnames, while minimizing the drawbacks.
Hi there! I’m Mathias, a web standards enthusiast from Belgium. HTML, CSS, JavaScript, Unicode, performance, and security get me excited. If you managed to read this far without falling asleep, you should follow me on Twitter and GitHub.
Nicolas Gallagher wrote on 19th May 2011 at 11:23:
Great summary! The last option is quite interesting.
There are a couple of other ways that people might use conditional stylesheets (not significantly different to the example you included, but with slightly different pros/cons).
One is wrapping conditional comments around stylesheets aimed at specific versions of IE to reduce the amount of overriding needed. IE6/7 are pretty similar so they can often get the same stylesheet. Not important (but still possible) to have valid CSS in a stylesheet that only two, stable and well documented browsers will ever see.
<!--[if IE 8]><link rel="stylesheet" href="ie-8.css"><![endif]-->
<!--[if lt IE 8]><link rel="stylesheet" href="ie-6-7.css"><![endif]-->The other approach (brought to my attention by @bricecarpentier) requires a build script. It wraps every stylesheet in a conditional comment and serves IEs a CSS file that combines the default CSS with the IE-specific CSS. This means you don’t incur an extra HTTP request in old IE.
<!--[if gt IE 7]><!--><link rel="stylesheet" href="style.css"><!--<![endif]-->
<!--[if IE 7]><link rel="stylesheet" href="style.ie-7.css"><![endif]-->
<!--[if IE 6]><link rel="stylesheet" href="style.ie-6.css"><![endif]-->But both these approaches have the same issues around making maintenance harder.
Thomas Deceuninck wrote on 19th May 2011 at 11:52:
Interesting article Mathias! But what to do when you want to set a property specific for one browser? For example:
.foo {
color: red;
}
.ie7 .foo {
color: green;
}If you use the * prefix for it instead, IE6 will also be affected, right?
Nicolas Gallagher wrote on 19th May 2011 at 11:53:
Oh, and one more problem with using conditional comments around the <html> tag is that it throws IE into compatibility view unless you set the X-UA-Compatible header in a server-side config:https://github.com/h5bp/html5-boilerplate/issues/378
Luc De Brouwer wrote on 19th May 2011 at 12:04:
I kind of disagree on the cons with the conditional stylesheets solutions.
The performance of the browser due to additional HTTP requests is something you can limit by targeting the specific browser instead of using the ‘lte‘ method. I find that maintainability increases with the different stylesheets because you can keep all CSS ‘hacks‘ clearly separated. Of course you shouldn‘t need to go apeshit with the amount of needed ‘hacks‘, if that‘s the case you did a rubbish job setting up the CSS framework etc. Also the solution Stoyan Stefanov suggested ( the empty conditional statement ) works like a charm.
However, this is an excellent write up!
标签：
原文地址：http://my.oschina.net/yonghan/blog/468721
