…or… <html> ’s conditional classes

From what I’ve seen a good number of developers these days are split between conditional stylesheets and css hacks.

You’re used to seeing this:

1 2 3 <link rel= "stylesheet" type= "text/css" media= "screen" href= "css/style.css" /> <!--[if IE 7]><link rel="stylesheet" type="text/css" media="screen" href="css/ie7.css" />< ![endif]--> <!--[if IE 6]><link rel="stylesheet" type="text/css" media="screen" href="css/ie6.css" />< ![endif]-->

But probably also plenty of this:

1 div .infoBox { float : left ; margin-left : 10px ; _margin - left : 5px ; }

CSS hacks to target specific browsers stay where the rest of your styles are, but they certainly don’t validate. For sometime now, the standards community has rallied around conditional stylesheets as a solution to the validation problem.

There are a few problems with it though:

Conditional stylesheets mean 1 or 2 additional HTTP requests to download

As they are in the the <head>, the rendering of the page waits until they’re totally loaded.

Also - Yahoo’s internal coding best practices do not recommend conditional stylesheets

It can separate a single CSS rule into multiple files. I’ve spent a lot of time wondering “Where the eff is that rule coming from!?” when it turned out to be tucked away in a conditional stylesheet.

Here’s my proposed solution:

1 2 3 4 <!--[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]-->

Using the same conditional comments, we’re just conditionally adding an extra class onto the html tag. This allows us to keep our browser-specific css in the same file:

1 2 div .foo { color : inherit ;} .ie6 div .foo { color : #ff8000 ; }

Plus it totally validates and works in all browsers.

(Hat tip to Paul Hammond and Adam McIntyre for being s-m-r-t.)

1 2 3 4 5 6 <!--[if lt IE 7]> <html class="ie ie6 lte9 lte8 lte7"> <![endif]--> <!--[if IE 7]> <html class="ie ie7 lte9 lte8 lte7"> <![endif]--> <!--[if IE 8]> <html class="ie ie8 lte9 lte8"> <![endif]--> <!--[if IE 9]> <html class="ie ie9 lte9"> <![endif]--> <!--[if gt IE 9]> <html> <![endif]--> <!--[if !IE]><!--> <html> <!--<![endif]-->

Doug Avery of Viget points out he prefers to use this technique on the HTML tag, freeing the body tag for dynamic classes. That works just fine. I later changed all my sites to use it on HTML instead of body, actually… Also it combo’s really well with the Avoiding the FOUC v3.0 technique as well as Modernizr.

You fancy something different?

Throw it on the html tag

Here is the new recommendation, and the one that’s in use in the HTML5 Boilerplate.

1 2 3 4 5 <!--[if lt IE 7 ]> <html class="ie6"> <![endif]--> <!--[if IE 7 ]> <html class="ie7"> <![endif]--> <!--[if IE 8 ]> <html class="ie8"> <![endif]--> <!--[if IE 9 ]> <html class="ie9"> <![endif]--> <!--[if (gt IE 9)|!(IE)]><!--> <html class= "" > <!--<![endif]-->

Why?

This fixes a file blocking issue discovered by Stoyan Stefanov and Markus Leptien.

It avoids an empty comment that also fixes the above issue.

CMSes like Wordpress and Drupal use the body class more heavily. This makes integrating there a touch simpler

It doesn’t validate in html4 but is fine in html5. Deal with it.

It plays nicely with a technique to kick off your page-specific javascript based on your markup.

It uses the same element as Modernizr (and Dojo). That feels nice.

I left an empty class in there because you’ll probably be putting a no-js in there or something else. If not, delete. Also if the extra comments around that last tag look weird to you, blame Dreamweaver, which chokes on normal !IE conditional comments.

This solution tends to encourage developers to largely ignore IE during development, and just hack it into submission at the end. That’s actually the worst thing you can do when writing your CSS, because it will force you to use hacks or workarounds that aren’t necessary. Many hacks and workarounds can be avoided by just coding things to work in IE from the start. If you test IE early in development, you should do your best to use good, standards-compliant code that is optimized for performance and future maintenance. Style forking creates code that’s less optimized in both those areas. Although IE can often be difficult to work with, it is possible to get it to work in most circumstances using good code – it just takes some forethought.

It’s very smart.

In reply to his post I said..

When you are addressing IE’s inconsistencies, attempt to first fix them without singling out IE in particular. In many cases, this is a matter of adding a width or height .. or some overflow:hidden . In general, being more explicit about how the element should appear helps IE6 and IE7 greatly.

Something to keep in mind. :)





2011.04.11: The HTML5 Boilerplate community dug into this and



2011.05.18: Updated the main snippet to match the syntax tricks we used in h5bp. See above link for more crazy details. 2011.03.18: Rachel Moore left a really nice comment exploring the pros and cons of this technique2011.04.11: The HTML5 Boilerplate community dug into this and figured out a lot more details around the syntax. Hopefully I’ll get a chance to update this post with those learning, but until then.. click through!2011.05.18: Updated the main snippet to match the syntax tricks we used in h5bp. See above link for more crazy details.

2011.09.02: Starting a list of languages this technique has been ported to

Conditional classes, ported

2011.11: Leif Halvard Silli, an awesome web standards hacker from Norway wrote in to say…

An earlier presentation of the idea that this page builds on, can be found at Big John’s classic IE hacking web site positioniseverything.net, in a guest article from February 2007 by Hiroki Chalfant entitled “#IEroot — Targeting IE Using Conditional Comments and Just One Stylesheet”.