If you look at the features promised by Google Chrome there's precedent for all of them:

• One Box for everything – Opera 9.5 / Firefox 3
• New Tab page – Opera 9.5
• Application shortcuts – Mozilla Prism
• Dynamic tabs – Opera 9.5
• Crash control – Internet Explorer 8
• Incognito mode – Stealther Firefox extension, InPrivate mode in IE8
• Safe browsing – Firefox 2, IE7…
• Instant bookmarks – Firefox 3
• Simpler downloads – Ok, I don't know of a suitable precedent for this.

But that's not really the point. What Google have done is cherry-picked the features to adopt in order to paint a clear picture of the way they see the web developing (and they are probably right, not least because they are pouring money into making it develop that way).

I wrote a webrunner (to borrow terminology from Mozilla) way back in 2001 or thereabouts, embedding the Internet Explorer component CHTMLView in a chromeless frame. The merit of the site-focused approach was obvious then even though my implementation was mainly just an exercise in MFC, and it was merely for a forum I used to frequent. The point is that not all webpages are equal. People don't spend most of their web time "browsing": 90% of the time they are just logged into the same sites and applications. Chrome's user interface, architecture, and selection of features seem better prepared for this than any other browser on the market.

Google Chrome is a leap towards a much more minimal browser that knows you aren't running it so that you can use a browser, you're running it so that you can use websites. This web-centric future has been predicted so often, it comes as a shock to see that this is what it feels like, and that other web browser manufacturers have never taken the initiative to fully deliver on this promise.

Since announcing that IE8's renderer can pass Acid2, it transpires that they have a Catch-22:

To have IE8 conform to standards, you have to use a non-standard workaround.

Wow. I'd assumed Microsoft knew what standards were but couldn't seem to achieve compliance. Not so! Turns out they can achieve compliance but they don't know what web standards are!

Because I had no idea I was unique in being able to experience scripts linked in the RFC-compliant and IANA-approved way, I have used this MIME type on quite a few sites. So it's good news, because I would never have spotted this otherwise. Happily, most of these sites are not yet deployed, and the rest only use Javascript for very trivial polish. There now begins a hunt to replace application/javascript with text/javascript on all my sites.

Obviously, I'm at a loss to explain why Microsoft has failed to offer a consistent platform for development and I feel quite aggrieved about it. If I hadn't already boycotted Internet Explorer this would be a pretty good reason to start.

On the assumption that some other piece of software has by accident or design disabled – or had previously enabled – application/javascript, this is my list of candidates:

1. Microsoft Outlook 2007, installed for the first time on this computer this week.
2. Word 2007, also installed this week for the first time.
3. Some random Windows update I installed last weekend.
4. Access 2007, installed two weeks ago (but I think I would have noticed sooner if that had caused this change).
5. Removing something malicious with Spybot. I think it removed one or two dubious registry entries left over from an infection of Vundo/VirtuMonde last year, so it's unlikely but there's an outside chance of an effect.

Well, we have an interesting opportunity to measure an aspect of that gap. A quick glance at Bugzilla shows that Gecko was able to generate a correct screenshot by 2006-04-17. Internet Explorer claimed correct rendering on 2007-12-12. The gap is 604 days for Gecko, but obviously, greater for other browsers who have been compliant for much longer.

If Internet Explorer 8 progresses anything like Gecko, there will be a large number of bugs still to fix. If Internet Explorer 8 progresses anything like Internet Explorer historically progresses, most of those bugs won't get fixed. In other words, I'll believe it when I see it. That might not be for 20 months and might not be available on Windows XP. In fact, if the same post on the IE blog they are keen to excuse themselves from commitment to specific web standards, offering only a general tone in favour of them but excusing themselves with respect to backward compatibility. Taken as a preamble to a compliant-looking Acid2 rendering, I take this to mean, "we may not deliver this in IE8″. I think everyone hopes they will, but by comparison, some of the Acid2 patches could have been in Firefox 2 but weren't because Firefox 2 was built with a frozen earlier build of Gecko.

Meanwhile, Firefox 3 is drawing closer. My impression is that the gap between 2 and 3 is not huge, which (hear me out!) is because Firefox 2 was excellent and Firefox 3 struggles to improve upon it. The difference for users is relatively minor. Although the new approach to bookmarking is hugely refreshing I think many users, including my parents, just won't get it.

The difference for developers is significantly less marked – the difference between having functional support for a technology that isn't portable to IE and having good support for a technology that isn't portable to IE is not something that will revolutionise the web. In fact, looking at the Firefox 3 for Developers page, the changes are disappointing and even worrying. In some ways it's a return to the browser wars of the late 1990s when competition between browser vendors' extensions demolished the concept of web standards.

• Support for aspects of HTML5 – there isn't even a first working draft of HTML5. Although it was the WHATWG spec before, complying with a specification this early will mean that the implementation may not conform to the final specification, by which time, developers will be relying on the non-standard behaviour.
• APNG – APNG is a Mozilla-sponsored bastardisation of PNG to add animation. It doesn't subscribe to the contract of PNG (which expressly forbids animation) and it isn't negotiable properly because it hijacks PNG's MIME type, extension and magic. This spells very bad news for the PNG format. In future it will be impossible to tell if a PNG is animated or not, and of course all legacy software will believe not. Despite the best efforts of a number of people, myself included, but most particularly Glenn Randers-Pehrson, Mozilla refused to adopt amendments which would resolve the conflicting standards and the PNG group failed to ratify APNG as an official extension. Although APNG was an ad-hoc solution to offer animated UI elements in Mozilla, it is being released and promoted as the new web standard for animation and MNG support, although a superior and established format, has been canned.
• Microformats – Firefox 3 builds-in support for Microformats, which could just as easily be a standalone Javascript library. There's no reason why this should be built-in, except to create a de-facto standard in an API which Mozilla controls. Moreover it promotes microformats as a de-facto standard, which I'm not comfortable with, because I think Microformats are an ugly hack in lieu of a proper solution.

Contemporary GUI development toolkits require an HTML rendering component: Java has javax.swing.JEditorPane; KDE has KHTML; Gtk has GtkHTML. MFC and .NET have Internet Explorer. In this task it is arguably successful: despite being too heavyweight, buggy, and non-portable, it is at least fast and very simple to embed. The applications which use Internet Explorer tend to use it in restricted circumstances so that the largest class of failings – how it measures up to the wild wild web – are not encountered.

With Firefox 3 right around the corner and a total radio silence on a potential IE8, it's worth considering how much Microsoft has to do to maintain its web browser's competitiveness.

Standards

Internet Explorer is of course lacking in standards support. XHTML and SVG are hugely significant formats entirely unsupported by Internet Explorer. That Internet Explorer supports RSS now is immaterial while nobody knows exactly what RSS is for, but at least it's not a misfeature. New standards are coming thick and fast, faster than Microsoft has been implementing them. The formats Internet Explorer does supports are not fully or correctly integrated with one another and as the collection of web formats continues to flourish this integration problem becomes harder and harder.

For example, Internet Explorer boasts a near-perfect XSL implementation. However, it dumps and reparses the result document. Because it doesn't support XHTML anyway, the resulting tree is interpreted as tagsoup. All of this decouples XML processing from the final DOM and introduces an array of bugs.

It would be hard for a non-programmer to imagine how much functionality this kind of integration entails. It's relatively easy to write or licence code which implements individual standards but integrating all of them to form one coherent whole – as is invariably implied in the specifications themselves – is much more work. The following diagram is admittedly somewhat arbitrary in scope, but may illustrate my point:

Bugs

What Internet Explorer does implement is riddled with bugs. These bugs are easy to fix but there are a huge number of them. Whereas the Mozilla project employs Bugzilla to allow users to report bugs, Internet Explorer relies on a testing team, and this is bound to result in fewer bugs being spotted. CSS is most often cited as an example because the bugs here result in immediately visual results, such the striking failure of Internet Explorer to render the Acid2 test, stemming not only from missing features but the incorrect implementations of many.

However, there are similar bugs throughout the software, documented in various sources around the Internet, alas none comprehensive enough to be a first port-of-call. My assertion here is that Microsoft has made some improvement between IE6 and IE7, they are unlikely even to be aware of all of the bugs that their software exhibits.

Misfeatures

In many cases Microsoft has deliberately violated the specifications. This is worse than simple omission: Microsoft has started down some paths from which it would be hard to return to a position of standards compliance. Even if they can appreciate that these features are unnecessary and undesirable, they will be disinclined to remove features which they have previously promoted which can cause existing applications and websites to break. This actually makes Microsoft's work harder, because they have to implement more than just standards compliance; they have to support their own misfeatures too, which are certainly not guaranteed to work interoperable with accepted web standards.

Examples include Moniker, which is an unsolicited part of the Microsoft netcode which guesses resource MIME types rather than obeying the HTTP Content-Type header, and conditional comments, under which CSS and HTML comments are not ignored, but interpreted, and certain statements force Internet Explorer to omit sections of markup.

Embedding

A disproportionate amount of Microsoft's development budget for Internet Explorer has to be spent on continued support of ActiveX. ActiveX connects the browser to arbitrary code. This is useful for the GUI toolkit aspect of Internet Explorer but it is detrimental for websites – not only because it is a source of security vulnerability, but because it is not portable so alternatives have to be found. ActiveX is not in very significant use in the wild, except as a route to browser compromise of course. This is both because of Microsoft's own security restrictions (which have neutered it) and other browsers' refusal to support it (which means it's not portable anyway). Meanwhile Javascript has become much more portable and powerful, such that ActiveX is no longer necessary for most rich web applications.

Developers, Developers, Developers

Web developers want standalone and even cross-platform versions of Internet Explorer. This is getting less likely: Microsoft is aiming to make new software compatible only with Windows Vista. Microsoft may be entitled not to want to play catch up in this area, but the approach could start to alienate them from web developers (a demographic skewed towards Linux), designers (whose demographic is skewed towards Mac), and everyone else (skewed towards Windows XP… for the moment).

The internal inconsistencies in Internet Explorer also rule out an extension for developers as good as Firebug, for the foreseeable future. There is an Internet Explorer developer toolbar which looks similar but which is vastly inferior and only serves to highlight Internet Explorer's bugginess.

Failing to cater to developers doesn't overcome the requirement for developers to target Internet Explorer… yet. But it has an effect. Personally, I have converted more than 25 people to Firefox.

Conclusions

Until we can gauge the rate of progress being made towards Internet Explorer 8, it's hard to assess if Microsoft is taking their web browser seriously. Five years of neglect leaves a lot of ground to make up, as described above. But I'd go so far as to predict that Microsoft won't keep up with the competition. They don't have the inclination, and although they have the money it's impossible to instantly convert money into good software (especially when you've got no experience at doing so… . Internet Explorer 7 is really not all that different to Internet Explorer 6.

If the gulf does continue to widen, some sites – at first intranet sites, and sites developed by Firefoxies and non-Windows users – may drop Internet Explorer support to focus on real browsers. At that moment, Internet Explorer's days as a desktop web browser really will be numbered.

It is common practice to test a web site in various web browsers, but this testing can give a false impression of the compatibility regarding different default settings. This is because almost all browsers have settled on a common out-of-the-box set of defaults. The user is allowed to override these defaults. Fail to anticipate this and your website risks visual problems for some users (perhaps 1% or so, to take a wild guess). Problems include:

• Character set issues, such as £ or the opposite, a broken character symbol (the question mark diamond in Firefox) rather than £.
• Specifying a font colour but not a background colour, causing clashes or even invisible text. Perhaps 10% of websites fail to specify a page background colour but assume that it will default to white.
• Linking images which are intended to composite onto white. This looks dreadful onto most other colours.
• Copy looking illegible due to tiny serif fonts (sans-serif is more legible on low-resolution screens).
• Body font clashing with image-based buttons and titles: serif and sans-serif fonts rarely mix.
• Pale-coloured boxouts. What appears pale is in fact a function of the background colour. A light pink box appears pale on a white background, but very bright on a black background, for which the corresponding effect would be a dark red box.

The browser defaults which you may want to change include

• Character set
• Background colour
• Text colour
• Font style
• Font size, although in theory you should avoid specifying this for accessibility reasons.

Misconfiguring a web browser is an art. It is perfectly acceptable to use the defaults a user specifies, as long as all of them are respected. While you should feel free to wholly b0rk a browser which you use purely for testing, it is more beneficial to misconfigure the web browser that you use for primary development. For me, this is the same web browser that I use for everything else, Firefox. Therefore the misconfiguration has to be something that isn't wholly unusable to me. More importantly, the new defaults have to be ones that I would be unlikely to use for a website, otherwise I could still rely on my defaults.

Because I tend to use sans-serif fonts, white backgrounds and black, grey or blue text, and UTF-8 character set, my browser is set to default to serif, coppery-orange text on a mid-grey background. I'm experimenting with ISO-8859-11 (Thai) as my default character set, because this isn't compatible with UTF-8 nor ISO-8859-15 for the most common problem area: £ and € symbols. It is compatible for ASCII-range symbols, so try UTF-16 if you are aiming for perfect incompatibility. I don't specify font-size but I Ctrl-roll my mousewheel on occasion to watch how the site changes at different font sizes.

So my default browser settings look like this. If I ever see these styles on a page, I know I've failed to specify something.

IE doesn't render table row elements <tr> unless they are added to an explicit <tbody> element. (The HTML and XHTML DTDs allow <tbody> to be optional/implicit.)

IE doesn't accept XHTML attribute names as XML DOM setAttribute() keys, requiring instead HTML DOM HTMLElement member variable names. (The HTML DOM is defined as subclassing the XML DOM without overriding these methods.)

I'm now using the Internet Explorer Developer Toolbar, which comprises a few of the features of Firefox's Web Developer Toolbar and Firebug extensions. It's really helpful in diagnosing these IE issues.

Looking through some of the unofficial bug lists for Internet Explorer, you start to get an idea of just how far behind Internet Explorer still is.

I wonder if anyone else has spotted this; it seems triflingly minor, but the client is so keen on tab order working correctly that they want me to rewrite the <iframe/> with AJAX polling.

Obviously, this means that for any site that IE7 breaks, it is failing on the standards-compliant CSS. But equally, as I noted before, not as many sites break as was expected. So that's pretty good news.

But for the sites that do break, and future sites in general, the situation is a mess. It's now necessary to split IE7 styles into different, conditionally included files, either by selecting on UA (which is unreliable) or use a gut-wrenchingly sickening IE misfeature called "conditional comments". IE6 rules need to be moved too, as IE7 will have significant common ground with IE6 and you don't want to have to maintain two copied of any rule that is shared.

Having rules split between different files makes it harder to work with, because in CSS you need to literally compare selectors to work out the precedence. * html is much easier to work with because you can place your IE rule right next to your real browser rule, and easily cross-reference the differences. Or if you change the real-browser rule, you can also amend the IE rule at the same time. More annoyingly, if you already have a tidy collection of CSS stylesheets importing one another with the @import statement, you have to either collect your IE styles in one file, or duplicate the tree for IE. Neither is very maintainable. The @import statement is not very useful anyway though, because CSS's precedence rules don't allow CSS to be modularised in an elegant way.

In Microsoft's defence, they are looking for a painless route to standards compliance that in all honestly does not exist. But I apportion the blame entirely to them, for two reasons. First, it was they who let the situation regarding standards compliance get so out of hand first; in effect, they are five years too late in starting to take this course of action. Secondly, bundling IE with Windows is one of the most devastatingly damaging things they have ever done. The cost to businesses worldwide could run into hundreds of millions, if not billions of dollars, and this money is not even paying Microsoft shareholders: it's being flushed down the toilet. Web designers to some extent profit from it at the expense of other businesses, but even so, we would rather not have to do it because we would then simply be able to achieve more. We would probably charge more or less the same, but all sites would be stunningly beautiful with rich interactivity.

CSS, has its own problems, of course, but these would have been very hard to predict all that time ago when it was drawn up:

• Selector-based stylesheets cannot be refactored without reference to a schema for the source document.
• CSS cannot deal with varying capabilities across implementations.
• CSS cannot be modularised, because selectors can very easily collide and supercede each other, dependent on the way the selector is described rather than the structure of the module. For modularised HTML/CSS 'components', you really need to prevent styles being overriden unless explicitly requested.
• CSS units cannot be specified as an arithmetic operation on unknowns, such as '(1em-3px)'. This means dimensions measured in ems (useful for text) are incompatible with lengths measured in pixels (useful for images).
• CSS has insufficient control of vertical positioning. The basic operations available are "the vertical order is the same as the document order", "x is at this vertical position", and with a bit of creativity with floating blocks, "x follows all of these", plus one modifier, "all my descendants lay out relative to me".
• CSS doesn't allow constants. This means that you have to repeat constants, say colour codes or border styles, and change them in more than one place.
• CSS has some bizarre quirks. For example, it doesn't include padding in the width and height dimensions, so if you increase the padding, you have to decrease the width correspondingly. IE for years did the opposite, which is totally wrong but much more intuitive.
• CSS selectors are lacking tidy disjunctions and assertions, things that exist nicely in XPath. It's possible to work around these, but not necessarily succinctly.

It's code for creating multiple recipient email fields with Javascript, such that creates as many as necessary and keeps the last field spare. Specifically this code is for deleting fields, which happens when you backspace or delete from a field which you've already emptied. This is modelled on how Thunderbird/Icedove's compose window behaves.

function autoCompleteContact(e)
{
    var event=(window.event)?window.event:e;
    var target=(window.event)?window.event.srcElement:e.target;

    //catch backspace or delete on an empty field as deleting the field
    if (target.value == '' && (e.keyCode == 8 || e.keyCode == 46))
    {
        //don't delete the last field if it's empty
        if (target == recips[recips.length -1])
            return;

        //find the container element for all recipient input fields
        var recips_container=document.getElementById('recipients');
        if (!recips_container) return;

        //Javascript doesn't seem to provide an array remove()
        //so do effectively newrecips=recips.remove(target) manually
        var newrecips=new Array;
        for (var i=0; i < recips.length; i++)
        {
            if (recips[i] != target)
                newrecips.push(recips[i]);
        }

        //Don't remove the last field
        if (newrecips.length > 0)
        {
            recips_container.removeChild(target);
            recips=newrecips;
        }

        //Focus the last field
        recips[recips.length-1].focus();
    }

    ...

IE7 does it perfectly, FF2's layout breaks and it starts showing the contents of the INPUT elements in the wrong place.