To use the new web applications, make sure you have one of these browsers: Safari 3, Internet Explorer 7, or Firefox 2 or later.

37signals is now doing the same, and will be dropping IE 6 support.

For most things that I’m in developing, IE 6 still has to much market share to ignore. That said, I can’t wait until the day we can kill IE 6. It’s from a previous generation of web browsers. It’s time for it to go.

Considering IE 7 is a free upgrade, or you could download the awesome Firefox 3, or Safari 3 it’s about time. I suspect we’ll see more and more sites start to do this, and likely in 2009 see some larger mainstream products no longer support IE 6.

It’s great to see the process starting. I can’t even begin to estimate the hours I’ve wasted getting IE 6 to work with something trivial on all other browsers.

The advantage of killing some old browser support is that it’s easier to take advantage of some of the features in more modern browsers that have much more robust features and better CSS support. Not to mention PNG transparency that doesn’t suck.

Modern web browsers like Firefox invest a lot into features to allow for a better web experience. Killing support for old browsers means they can be used. It’s the start of a better web.

David Baron has a must read blog post. Since the bulk of these older sites are on intranets, why not just allow administrators to enable compatibility mode on intranets? Seems like a perfectly logical solution that doesn’t hold back the web, and allows them to achieve their goals.

Daniel Glazman has another idea that I think is very valid.

• Microsoft should freeze, and I really mean it, its current IE6/IE7 HTML 4 engines, and drop that META tag idea.

Ditto. That needs to be a very deep and reliable freeze though.

Essentially the argument by the IE team is this: Rather than fix the problem, lets create a larger problem so the smaller one isn’t very noticeable.

Yea, that’s how I parsed the blog post. For anyone who disagrees, perhaps I interpreted it wrong because they didn’t select the correct parser because they didn’t include the following:

<meta http-equiv="X-UA-Compatible" content="IE=8;FF=3;raccettura=serious;OtherUA=4" />

All joking aside it’s an insane idea guaranteed to set things back.

The problems web developers face are pretty simple:

• Archaic html/js often written by Java/C++ developers in the late 90′s early 00′s who knew nothing of html/js but wrote the backend and by definition were expected to figure out the frontend. Code is massively FUBAR and was designed for IE exclusively. Those currently maintaining it have no idea what to do to fix it and don’t want to bother.
• Genuine attempts to keep up with standards but growing frustrated with lack of good browser support for them (looking at you IE 6, and partially at IE 7).
• Half hearted attempt to keep up with standards, but figure all the cool kids use an XHTML 1.1 doctype, so why not?

There are others, but most fall into these 3 categories. Microsoft’s fix doesn’t help anyone of them. It just means more broken sites and more knowledge of different issues in various versions is needed. Let IE 6 die already. Mozilla put Firefox 1.x to sleep already. Encourage it to die. IE 6 was released in 2001. It’s perfectly acceptable at this point to EOL it. There’s a viable alternative for Windows XP which is still supported. IE 7, Firefox, Safari. All of which are free. Killing IE 6 once and for all is the first step to fixing the problem. It will get rid of lots of ugly “hacks” on the web and let developers start to move on. And on towards getting ready for IE 8.

What happens if my page is set to use 1 rendering engine, but I want to include a “widget” designed for another? In the age of embedded content this raises a whole new set of issues. Not everything is Flash. What if this JS widget is designed for IE 7 and my page is designed for IE 6? The web right now is at least encouraging people to keep up, and providing incentives (better cross browser compatibility, reduced QA and triaging issues). This new scheme just fragments the web. Many of those embedding these days don’t know a thing about html, js, or web standards and compatibility. How do you explain what they need to know? Or does my code really need to be able to handle all cases an embedder might throw? Does anyone else see the burden this creates?

As Robert O’Callahan so awesomely points out, it can’t be easy for Microsoft to maintain either. If they have so much time/resources on hand, why not just work on fixing bugs, furthering the web standards work, and starting an evangelism team to contact problematic sites and encourage them to start fixing issues. Worked for little old Mozilla with < 5% market share at the time. I’m guessing with Microsoft’s market share, they could likely do better.

Why not do like WebKit, Mozilla, and Opera do and start providing nightlies so developers can actively track issues? Why are web developers left in the dark through most of the process? It doesn’t seem like anything is really a closely guarded secret. You can keep the UI stuff private and just release updates to the rendering engine. That’s essentially what WebKit does. CSS3 isn’t exactly a business secret. Then once things are late in the game, web developers are shown what they need to deal with. The model the other players use is so much better from a developer perspective. I regularly test sites I take care of in nightlies. Not every day or even every week, but I keep up on it. Web developers have had over 1 year to see what Firefox 3.0 was cooking up. Various blogs have covered changes, as well. IE 8? Radio silence for the most part. Exceptions for things like this.

There must be a better way. Come on Microsoft, help fix the web.