I often find myself in a room with web developers and at least one of them proclaiming that IE6 sucks because it doesn’t support web standards while others nod in agreement.

This has bothered me enough to contemplate having a talk at BarCamp Ljubljana . I didn’t, but this is what I would say.

Internet Explorer 6 was released on 27th August 2001, when twin towers were still standing in NY.

7 years is a long time to remember, but what did we work with back then? There was no Safari and Firefox was still in its infacy, far from 1.0 release coming 3 years later. It was changing so often most developers simply ignored it. Opera was at version 5 (version 6 came out in November of that year) and I am sure I am not alone in remembering how awful it was at least until version 7 in 2003. Mozilla was at version 0.6 and although showing great promise, IE6 definitely was the browser we hoped others would match.

Back then no browser supported CSS2 in a meaningful capacity. Opera had the best support for CSS until then, but IE6 surpassed it. It didn’t support DOM Level 2, which was standardized only 4 months before first beta of IE6. Good excuse not available anymore to IE7 and IE8. Apart from that it supported more or less everything web developer could want back then and then some. IE6 problem isn’t so much that it didn’t support standards of its time as it is that it doesn’t support standards of today.

So why the hostility?

Lancia Delta Integrale , which dominated rally competitions in eighties, is today an obsolete car, but car aficionados still have a soft sport for it. You don’t hear them go around complaining how it doesn’t meet standards of todays cars.

Well, as I’ve said, 7 years is a long time and most web developers are not old gits like me, so the historic context isn’t there. We also have to live with its real shortcomings today. But I think there’s more to this.

Complaining about IE6 standards deficiencies is declaring who you are and where you stand. It’s a simple and very recognizable way of declaring you are a member of web-standards tribe. IE6 bitching has at least as much to do with proclaimer as with proclamation’s subject. Trashing IE6 isn’t so much talking about the browser as it is talking about you.

However it is not unreasonable to ask why IE6 doesn’t better support standards that were released or updated after its initial release.

Certainly more could be done through software updates, but are standards themselves forward looking in a way that would avoid updating browser internals with every new version of a particular standard?

I am quite certain that this isn’t always possible. I don’t see how you could add a video object from HTML5 to a browser without explicit support from browser’s developers. But not all changes are such as John Allsopp has recently pointed out.

I have mixed feelings about HTML5. It’s bringing much needed new capabilities and lots of goodies, but I also think Sam Ruby has a point. New, simple, DOCTYPE is reduced to a switch between standards and quirks mode and unless it will become more complicated in later revisions, it won’t offer an easy way to distinguish between HTML5 documents and other HTML versions. This isn’t a particular problem if newer revisions will be backwards compatible with older, but this isn’t true even of HTML5. Why would we think this is the last version where we will make a major misstep that needs backwards-incompatible correction?

There are other things I don’t like about HTML5, but if I would have to pick one thing I would like to see changed, is to make it more extendable.

To sum it up, IE6 is indeed a problem in todays development, but it’s also at least at fault for this. It was an excellent browser when it came out and is remarkably solid one for software so old. There are many reasons, completely untouched in this post, why its users don’t migrate to something newer, but we, web developers, are also to blame, because we tend to standardize only current practice and leave few doors open for future development which invariably comes.

As I am leaving on a short vacation that will probably take me off grid for few days, there is still a time for a hopefully short, but definitely last post of this year. I don’t like how registration forms ask me twice for password and I think I can offer a better way.

Most registration forms these days still want you to type password of your choice twice. They probably do it to reduce risk of mistyping it. I deeply dislike Facebook, but I think this is one thing it got right . You only have to do it once. Those with FB accounts can see this in action if they log out for a moment and visit front page.

There are several reasons why once is enough. First one is that every decent page provides a way to reset password in case you have forgotten it. So even if password was mistyped, it’s easy to reset it again to a different value. Second reason is that by now it’s quite well known that most people use a low single-digit number of passwords and don’t come up with a new one each time they are asked to do so. Hence it’s quite unlikely they’ll make an error now after so much practice.

Third reason is that in most cases you can help them .

When registration forms first appeared internet access was rare and expensive enough that most common environment in which it was used was work or school. It was therefore likely that when you were registering for a service, you weren’t alone and entered password had to be hidden from people around you. Today it’s probably opposite. Most of the time I am quite private and could see what I type with no additional security risk.

So as in demo we could offer a switch that let visitors see what they are typing if they choose to do so. It should still be hidden by default, since we can’t really tell the environment visitor is in or if Javascript is available. It is always better to err on side of safety.

As a side note for those who might have peaked at implementation. I’m replacing password input field because of Internet Explorer, which doesn’t tolerate type attribute change on input fields. Every other browser tested (FF, Opera, Safari and Chrome) would work perfectly fine by just switching field type from password to text.

Anyhow, that’s it for this year. If you leave a comment, which I hope you will, and I don’t answer, it’s because I lack Internet access.

There’s an HTML pattern that has been bugging me for a while even though I’m guilty of using it too. It’s even present on page you are reading right now.

Almost every page has a navigation bar and chances are that strip is presented as some kind of a list of links. Just as it should be. What bothers me is that when you actually are on page listed in navigation, its navigation item will still contain a link to it.

This reference to itself is like having a door in a room which leads you back in. Not very useful and certainly misleading.

Better approach is to simply not have a link when that link would point to page itself. Such HTML is also more semantic, since it’s clear which item was selected and where we are even without a style sheet.

When discussing this observation it was pointed out to me that with proliferation of Javascript and AJAX you might want to give your visitors a way to bring a page to a known state by reloading it. I think this is more than adequately solved by reload button that every browser has and most users know, but if you find having a link a better solution, why not try a compromise. Just add the missing link with Javascript in spirit of this demo .

This way you won’t polute content markup with behavior that should sit on top of it.