Half of the Web Development community appears to have managed to go screaming round the twist.

First (In order of “Things Aquarion saw”) was Opera’s decision to file proceedings with the European Union for Microsoft’s failure to adhere to web standards. I’ve got more to say on this, but I’ll do so later.

Second, we have Malarkey’s call to disband the CSS committee on the basis that browser vendors don’t want CSS to be a quantum leap forward.

Third, there’s a mess about default codecs in HTML5.

Let us deal, first, with the second option, because consistency of options is for sissies. In the rest of the world, that bit not concerned with technology, the way Standards work is that there is an idea for a standard that would make everyone able to work with everybody else’s work. Then a standards body puts together a complete spec, which gets discussed a bit, then ratified, then things are implemented based upon it.

In the web world, which because it moves faster sees itself above such staid systems, innovations go into the spec. The example people give for how well this works is the XMLResponseObject stuff that started in IE and then spread out. The counterexample is the IE Filter system, which requires a DirectX interface – difficult in non-microsoft controlled applications, impossible on non-Windows systems. These two examples are pretty good because they demonstrate a defined, simple expansion that can be implemented by other people; and a complicated expansion that cannot be done by anyone else.

Other examples include the Canvas object, Wiimote javascript events, search engine addition objects, conditional comments, blink, marquee, and various other bits, plus the forthcoming native comet object I’m sure will happen soon.

Mostly these things happen not because of companies intentionally fucking up the web, but because a) They need the functionality for something else the web engine does (XRef Canvas, Filter, Wiimote) or b) to try out forthcoming functionality.

An example of (b) would be Mozilla & Opera’s implementation of CSS 3 things like rounded corners and opacity, which are well-implemented with a distinct namespace.

The bits where we get into trouble are when we start implementing or using a specification before it’s been finalised, as we enter a new set of dark days where your implementation of CSS3 depends on which point-release of it you read.

So, you need give and take. The browser vendors are going to innovate, and some of those innovations are going to be good and useful enough to go into specs, but innovations should be kept in their own namespaces, far away from where you expect the eventual specified method to be, so that when the final method is implemented it can be done so in the right place, with the right methods, and we don’t spend the next decade with backwards compatibility issues, and the only people who suffer are the ones who relied on unfinished functionality who have to rework their code to do things the right way. (This is Acceptable, the penalty for being on the bleeding edge is occasional paper cuts).

The web developers have to step back a bit and see the difference between a standard, an implementation, and a useful hack. The first is the only thing we should rely on.

Specification bodies need to move forward, release a hard specification that things can be built to, and then work towards the next point release. Remember to let developers specify which versions we’re relying on, and help us fall back gracefully if it isn’t there.

And everyone needs to stop overreacting, or we’re going to lose.