Time to drop IE6
Feeling inspired by Dan Rubin's recent post, entitled The Final Word on IE6, I just finished writing this email to coworkers, reiterating why I think it's time to drop support for Internet Explorer 6. Realistically, we have already stopped doing anything with IE6 in mind, we're just talking through making it our "official" stance not to support it. Anyway, I thought it would make for a good blog post, since I've been neglecting to write as of late.
As requested, here's a run down of what it takes to support IE6. First off, here are a few lists of IE6 bugs, not all of which are major (totaling over 120)…
Just off the top of my head though, here are 8 bugs that I have repeatedly dealt with in the past…
#1 — A CSS filter fix for every single PNG file, including foreground and background images. That means, anything with slight transparency needs it. In so doing, links within those areas cease to work, if that element has both the PNG filter and absolute positioning. We could use a GIF instead, in which case the presentation looks like 8-bit Nintendo. More here:
#2 — No using min-width, max-width, min-height, or max-height. Meaning, we can't define semi-fluid layouts for views, that disallow themselves from going too small or too large. We'd have to substitute a filter, doing JS within CSS. It's possible to do, just time consuming. Plus, by using these CSS expressions, we have to make sure we're doing it right, because IE6 and IE7(Internet Explorer 7) understand them, but IE8(Internet Explorer 8) drops support for them (in standards mode, but retains in quirks mode). That means coding things three times, once for all good browsers, once for IE6, and another time for IE7 & IE8, to make sure they're not incorrectly applying what is only meant for IE6. More here:
#3 — IE6 is notorious for not making block-level links click-able. Meaning, it's more tedious to create buttons that have more than just their text click-able. To fix it, you have to go in and set either width:1% and/or height:1%, or know the exact pixel dimensions of a link beforehand, and set it verbatim.
#4 — IE6 will not allow the re-definition of a style using a combination of an ID, selector, class name, added to another class name. It's a bit wordy to explain, but basically #my_id.class_name will render the same as #my_id, completely ignoring the fact that an extra class has been added. I documented this particular bug a few years ago…
#5 — IE6 doubles the margin of any element that is floated. Meaning, if I have a row of 4 boxes, each one 200 pixels wide, with 10px of margin-right, then in good browsers, the total width would be (200 * 4) + (10 * 4) = 840. IE6, however, would double that margin, giving each element 20px margin-right, for a total of 880 pixels, causing the right-most element to drop to the next line. This is remedied by setting display:inline to the floated elements, but some times you really do need them to be display:block. For instance, transforming a normally inline element such as a link or span.
#6 — IE6 doesn't support the :hover pseudo-class on anything but links. This means that many of the techniques I have employed such as hovering over label or span to create interface changes would all need to be either re-coded into dead links (href="#") so that we can style them with CSS, or re-coded with mouseover + mouseout events to handle via JavaScript.
#7 — IE6 adds inexplicable width to italicized text. Meaning, if you have a content area with a block quote set in italics, this will cause your content area to be wider, pushing your sidebar below the content, because the floats get too big to fit side-by-side. One way around it is to set overflow:hidden to every single text element that could possibly contain italicized text.
#8 — IE6 mis-interprets height to mean min-height. So, if you set something to be 500px tall, and want it to stay that way, if your content happens to be taller than that, it will expand to accommodate, whereas other browsers take the height literally, and simply let the content spill over. This isn't a huge issue, but does make it more tedious, having to re-define a separate height for everything that needs min-height, in a separate CSS file.
#9 — IE6 lacks support for the :first-child selector, meaning you cannot grab the first element of a particular tag name, and instead have to resort to giving it a class name in the markup. Not a huge deal, but being able to reliably use this selector makes coding navigation lists go so much smoother.
#10 — IE6 misinterprets position:fixed, making it impossible to have elements stay in a particular area as a page is scrolled, without some serious hacking. It can be done, with considerable re-working of the html and body tags are handled. I did a demo of how this this works a few years ago.
Basically, it's not impossible to support IE6. Heck, front-end developers have all had to do so for the past few years. It does, however, add another 1/3 to 1/2 development time, depending on how many fancy graphics are in a page. If I had to estimate, I'd say if something takes 6 weeks to complete for good browsers, that project will take 8 to 9 weeks total, to support IE6.
Or, we could design very plainly with IE6 in mind, but that would just make our site look like Basecamp does now. Yet, even 37signals wants to move forward, which is why (in my opinion) they're dropping IE6 support on October 1st.