Scoble points to Paul Thurott's thoughts on IE6.

Microsoft presumably can't justify further development or expense on IE6 development. They are a money-making business and they've moved on. The idiosyncrasies of the browser are well known, or at least should be given how long its been out, to the development community. Changing IE6 now would break these code workarounds, making people angry at MSFT.

There are a few UI enhancements that wouldn't break the DHTML code rendering and would only improve the "browsing experience". Tabbed browsing and pop-up blocking are probably the two that are most requested.

I don't think Microsoft will add tabbed browsing for two reasons: 1) is that it's not intuitive GUI, as I said in my comments last week and 2) it would require a major rewrite of IE. You can't mash in something major like tabs. It's like adding browser support for frames: instead of dealing with one thing you are dealing with n things.

Pop-up blocking is a code interpretation hack because popups are perfectly valid DHTML. It works in Mozilla because Mozilla users know what a pop-up is on a technical level. Most users of IE6 don't and as a result could miss important web site functionality because of it -- especially on (corporate intranet) web sites that use pop-ups as a way to simulate modal dialogs on web applications. Yes, gross.

I think Paul missed part of what the Microsoft employee meant by "Further improvements to IE will require enhancements to the underlying OS." They aren't just talking about eye-candy GUI improvements. They are talking about having access to Longhorn's (still rumoured? I can't keep up) SQL Server-based file system for easier file system searching and other low-level technical enhancements. These additions to the underlying OS will improve the next IE's UI experience by adding the possibility for unique features not possible on WinXP. The flying and fluttering windows are just gravy .... I guess.

Forget about the browser GUI. If you want to talk about zeniths, then DHTML has reached its practical zenith. People are doing UI things with browsers today that just seem unnatural -- and I'm not talking web pages here (though there are many weird ones out there), I'm talking corporate web applications. Sure it's easier to maintain so-called "thin" client application (or easier to break it, depending on who you ask) but if the UI tools (DHTML) you have available to you don't measure up, use something else -- don't kludge it.

Update 12:12 Tim Bray adds to his comments that CSS ain't Rocket Science. I agree with a lot of what he says, but I'm going to explain my earlier statement about using DHTML improperly to add to his arguments.

You can't control what people will do with your UI toolkit. VB programmers suck at making GUIs because they generally have no formal training -- you can't help this. Web pages solve the problem in one dimension by limiting what you can do on one page ... and as a result web applications are cleaner but sometimes require more clicks. Usability improves on look and feel, but suffers when speed is important.

Some WinForm widgets are more dense and complex. The slider, for example, does something you'd never be able to do well on a web site. Same with tabs. You can kludge tabs in DHTML, but in WinForms they are just there. Managing that density is a job that requires skill and is generally not something a programmer can do well without help from someone with usability training.

The other side of the coin is when you want your application to be GUI dense and client-server. You can't have it both ways -- in that case you must use WinForms or you will suffer in browser development hell. Believe me, I've been there.