Using Bugs to Your Advantage
Some bugs are better than others. In this case, CSS parsing bugs can help us target specific versions of IE using a specially crafted selector:
* for IE7, prepend any rule with *+html,
* for IE6, prepend any rule with * html.
An example of a stylesheet containing rules for IE7 and IE6 compatibility:
1. div.highlight {
2. background: red;
3. float: left;
4. margin-right: 10px;
5. outline: 1px solid blue;
6. }
7.
8. /* IE7 doesn't support outline, use border instead */
9. *+html div.highlight {
10. border: 1px solid blue;
11. margin: -1px;
12. margin-right: 9px;
13. }
14.
15. /* IE6 needs to fix doubled margin bug */
16. * html div.highlight {
17. display: inline;
18. }
So far, there has been no CSS parsing bugs identified that would help us target IE8 using a selector only. What we can do, however, is use declaration parsing bugs to target specific versions:
* to target IE8 in standards mode, use /*\**/ before the colon and apply the \9 suffix to the value declaration,
* to target IE8 and below, use \9 before terminating a CSS value declaration,
* to target IE7 and below, use the * prefix before a CSS property declaration,
* to target IE6, use the _ (underscore) prefix before a CSS property declatarion
To illustrate, let's apply a few of these rules just for fun:
1. .myClass {
2. color: black; /* normal CSS declaration */
3. color /*\**/: red\9; /* IE8 standards mode */
4. color: green\9; /* IE8 and below */
5. *color: blue; /* IE7 and below */
6. _color: purple; /* IE6 */
7. }
Using CSS hacks enables us to apply fixes without the need for conditional comments, but at a cost – hacks usually don't validate, are hard to understand without additional comments and can be confusing for IDEs, depending on their validation and syntax highlighting implementations.
Given the choice between CSS hacks and conditional comments, I always pick the latter as my go-to method when dealing with browser version targeting. It has served me and my clients well in the past and continue to make my code more standards-oriented, readable and future proof – who knows when or if these hacks will start interfering with newer or other vendors' browser parsers. Granted, if all you need is to fix a declaration or two, you can still use this in your existing style sheets, but as soon as that number grows beyond, say, a half a dozen, you should consider creating a separate style sheet.
Hacks vs. conditional comments
So what's the best way to address browser inconsistencies? Well, from my experience, I've decided on a strategy that seems to work best: let the oldest browser carry the burden of compatibility.
Remember, you are building websites that, ideally, should not need periodic check-ups and redevelopment (save for the obligatory redesigns, of course). So why should the browsers of tomorrow carry the burden of the browsers of yesteryear?
The way I've tackled this problem is including the following <head> structure:
1. <link rel="stylesheet" href="bridging.css"/>
2. <!--[if lte IE 8]>
3. <link rel="stylesheet" href="ie8.css"/>
4. <![endif]-->
5. <!--[if lte IE 7]>
6. <link rel="stylesheet" href="ie7.css"/>
7. <![endif]-->
8. <!--[if lte IE 6]>
9. <link rel="stylesheet" href="ie6.css"/>
10. <![endif]-->
In this case, IE6 will load all four style sheets (including additional @imports), and each subsequent version of IE will load one less. The beauty of this is that all CSS bugs are dealt with in a backwardly fashion, meaning rules need not be overridden for posterity. And when support for a specific version is dropped, so can the conditional comment, reducing the CSS code needed to maintain the website.
Click here for more information.
http://www.webdevout.net/css-hacks
1. Conditional comments
2. In-CSS hacks
1. Easy selectors
2. Minimized attribute selectors
3. !important
4. @import "non-ie.css" all;
5. body[class|="page-body"]
3. Unrecommended hacks
1. _property: value and -property: value
2. *property: value
3. body:empty
4. a:link:visited, a:visited:link
5. >body
6. html*
7. !ie
8. !important!
4. Third party translations
No comments:
Post a Comment