Big Red Tin » ie6

How we do IE Hacks

Peter Wilson — Wed, 14 Sep 2011 01:30:50 +0000

We recently changed the way we do IE hacks at Soupgiant. For years we used conditional comments to load separate CSS files.

For a few sites, we used Paul Irish’s conditional HTML classes hacks. Without workarounds, this puts IE in compatibility mode.

Recently, we decided to go back to attribute hacks.

Using LESS CSS and compiling with less.app, it’s possible to store the hacks in a single location and remove them once the browsers die.

The hacks we use are:

/* IE6 */
#something {
  _color: blue;
}

/* IE6, IE7 */
#something {
  *color: blue;
}

Around the time we switched, Mathias Bynens wrote a post detailing much the same conclusions we reached. I won’t rehash them here.

Excuse the dull and highly unfashionable post. It’s main purpose is so we can go to bigredtin.com/iehacks when memory fails us. We use this blog a resource.

Euthenasing Internet Explorer 6

Peter Wilson — Wed, 06 Jul 2011 20:30:30 +0000

I think, much of the time, when website owners and developers decide to drop support for IE6, we go about it the wrong way.

For a not-for-profit, like WordPress.org, the decision can be simple. The project is free and the cost is resources. To no longer support IE6 in their admin means the WordPress team can develop more efficiently. When a website makes a profit, however, I think the decision is black and white.

Many of us, are bastardising Microsoft’s advice for users to upgrade. Once enough people have upgraded, sites can then safely drop support for IE6.

Website owners and web developers who drop support for IE6 before their users upgrade, forget a key tenet of customer service: it has to be focused on the customer! My perception — and it’s nothing more — is the larger the project, the more willingness there is to drop support for IE6 without regard for the user. A larger project has larger development costs, and the larger development costs increase the cost of supporting IE6.

If I ask someone why they’re dropping support for a particular browser, the answer I look for is: “The extra dev costs outweigh the profits from the browser segment”. When people list percentage of visitors as their justification, I’m reminded of a conversation I had with Matthew Curry on Twitter.

Matt is the head of ecommerce for British sex toy retailer Lovehoney (this link may not be safe for work). He wrote: hmmmm, IE6 Lovehoney users have now dropped to 0.8% – decisions decisions……. – Source

Some suggested he drop support for IE6. Matt’s background is statistics so I knew he’d follow the numbers. Instead, we spoke about conversion rates for IE6 users on Lovehoney. They were lower than for other browsers but not statistically significant.

To my mind, Lovehoney’s decision to drop IE6 or not boils down to this question: “Are development costs for IE6 greater than 1% of profit?” If the answer is yes, drop that browser like a hot potato. If the answer is no, support the browser until the answer changes. I’d be surprised if Matt’s question was much different.

There are things web developers can do to encourage dropping IE6. A prominent message, like the one on IE6 countdown is one way. However, the question at the front of the website owner’s mind should always be about return on investment.

If you’ve decided to drop IE6 support your website, I’d love to hear your reasons in the comments.

Why I will not be dropping support for IE6

Peter Wilson — Wed, 07 Jan 2009 01:30:58 +0000

Increasingly I’m reading of web developers deciding to drop IE6 from their list of supported browsers, usually, because of its creative interpretation of CSS standards, besides IE7 is over a year old, and, IE8 about to be released.

I’ve decided to continue support for IE6 as it’s still in wide use – especially in corporate environments – and, I don’t think it needs to take a lot of work to develop for. I’ll say that again, I don’t think IE6 is as bad it’s sometimes made out to be.

IE6 is the difficult child of the browser family – but like most difficult children, with the right tools it can be made to behave. IE7 is better behaved than IE6, but let’s not fool ourselves, it’s not the glowing example of a perfect browser, and requires hacks of its own.

Standards Mode

The best tool to reduce IE6‘s development time is to move the browser out of quirks mode and into standards mode using an appropriate DOCTYPE, and, leaving off the XML declaration; I code in XHTML Strict, so my files begin:

In standards mode the browser will inherit font styles within tables, use the W3C box model and vertical alignment defaults.

Comments

Create a standard comment format for your main CSS file which you can use when you know you’re going to have to write a hack for the IE6 style sheet, such as /*HACK ie6 ... */; rather than flicking between your main and IE6 style sheets during standards development, you can just search for hack comments during non-standards development.

#someDiv {
min-height: 300px; /* HACK ie6 - height: 300px */
float: left; /* HACK ie6 - 3px jog (adjacent), zoom: 1 */
}

Surprises

Once you’ve specified the DOCTYPE, and, repaired known hacks, IE6 is likely to surprise you with a few more creative problems, positioning, an extra few pixels here and there and other little tricks; but by ruling out the obvious in advanced, overall debugging will become less time consuming.

As I said above, IE7 requires its own set of hacks. If browser specific debugging is required anyway, I don’t think it’s overly time consuming to continue support for IE6.