Blogless

We all know the scenario. Some movie protagonist is facing some movie antagonist, and the antagonist tells him to choose who dies, his (insert family member) or his (insert other family member). Always, always our good-hearted protagonist offers himself first. Only very rarely does this work.

Donnie Darko, because his enemy is metaphysical, chooses himself. Ontic enemies rarely allow this.

The rest of the time, our insidious villain makes some smart comment, and we’re back to square one. The Internet Explorer team’s smart response to our valiant attempt to save all our users was to provide us the conditional comments specification. Please note, the villain will never just decide to give up his evil ways at this point. Never.

Ostensibly, what Microsoft suggests is that CSS/HTML creators stop using IE Hacks in the body of their main style sheets, and instead, in the HTML, create a conditional comment which serves up an IE-specific stylesheet if the user-agent is in fact Internet Explorer. Like this:

<!--[if IE 5]>
<link rel="stylesheet" type="text/css" href="ie5.css" />
<![endif]-->

Ok. So there are obviously a lot of good reasons to Stop CSS Hacking, including CSS validation, sustainability, and pragmatics. They have been discussed in detail, often eloquently, and won’t be repeated. Here’s a little excerpt from the above article:

Instead of specifically exploiting bugs in a browser, bugs that will obviously one day get fixed, conditional comments are an officially-sanctioned feature of the browser that won’t ever go away. They validate, and even though they’re proprietary, when used with discretion they allow us to accomplish exactly the same thing as CSS hacks.

There are also eloquent and accurate rebuttals from a camp that enjoins that conditional comments are not only an affront to HTML standards, but also maintainability, and the common sense of keeping your hacks in one MIME type:

While "Conditional Comments" are syntactically valid, they are not standards compliant: Information that appears between comments has no special meaning, and comments will be ignored by the parser.

Given the fact that both approaches require some give in terms of maintaining your standards-integrity, and that both have pros and cons in the long-term column, and some pragmatics, I consider all these categories a bit of a wash.

Here, I thought I’d try a little thought experiment that starts with the numbers.

The Argument from Statistics

Imagine a test sample of 100 total website users. On average, you’re going to have a breakdown of user agents that looks like this (grouping browser versions):

• 53 Internet Explorer users
• 38 Firefox/Mozilla users
• 2 Safari users
• 1 Opera user

This means that 41 of your users are dealing with a browser that is reasonably standards-compliant, and 57 of them "may require hacks".

Now let’s imagine you have to hack a conservative number (say five or so) CSS definitions to get all versions of IE rendering the page right. Let’s assume that including comments for organizational and explanatory purposes, we’ve got about 40 lines of css, and about 550 bytes total. The conditional comment above adds 84 bytes to our html page.

So, in the case where you are using the conditional comment above, you’re serving 84 unnecessary bytes to 57 users, for a grand total of roughly 4.8kb of wasted bytes served. In the case where you keep your hacks inline, you’re serving 550 unnecessary bytes to 41 users, for a grand total of 22.6kb.

To put this in perspective, multiply by a few thousand users a day. Let’s say your client’s website gets 5,000 users a day instead of 100. That works out like this:

• The conditional comments approach serves ~2.4mb of throwaway bytes a day.
• The inline hacks approach serves ~11.3mb of throwaway bytes a day.

Now, 9mb a day distributed over 5000 users is not exactly what I’d call a "huge ordeal" for the users, but I think it does give some compelling evidence that conditional comments, on the balance, are actually better for users. Which, especially with all other things being more or less equal, is good enough for me.