In the past days the fragmentation of web technologies was mainly caused by the corporate interests and while it has gone nowhere, it has shown some considerable improvement over the past years (see IE dumping CSS hacks or IE8 to pass Acid2 from 2008). Nevertheless, what we're witnessing today, is of a different kind. Two main open standards bodies involved in HTML5 development, WHATWG and W3C, are struggling to find the common ground.

2 days ago (July 19th 2012) a post in the WHATWG mailing list claimed WHATWG separating their HTML Living Standard specs from W3C's HTML5:

Ian Hickson

A few years ago (around 2007), we started working with the W3C on what we were then unofficially calling "HTML5", and officially calling "Web Applications 1.0". We renamed the specification "HTML5", and the W3C began publishing a copy of it as well. Not long after, the W3C side of this effort decided to split their version of the spec into subspecs (e.g. splitting out the 2D canvas API, server-sent events, postMessage, etc), and for a while we tried to match that on the WHATWG side. The result was an increasing confusion of versions of the spec, so we eventually went back to just having a single spec on the WHATWG side which contains everything I work on, which we now call the "HTML Living Standard". Over the years, this document and the various documents on the W3C side have slowly slightly forked, as documented at the top of the WHATWG spec.

More recently, the goals of the W3C and the WHATWG on the HTML front have diverged a bit as well. The WHATWG effort is focused on developing the canonical description of HTML and related technologies, meaning fixing bugs as we find them [1], adding new features as they become necessary and viable, and generally tracking implementations. The W3C effort, meanwhile, is now focused on creating a snapshot developed according to the venerable W3C process. This led to the chairs of the W3C HTML working group and myself deciding to split the work into two, with a different person responsible for editing the W3C HTML5, canvas, and microdata specifications than is editing the WHATWG specification (me).

Whilst it's surely of the organisational nature, it possesses a threat of creating a viable double standard and further fragmentation. As for a developer, there's a clear correlation between fragmentation and deployment effort.

A realistic illustration for the story is this:

-webkit-render:fast; /* Apple, Google, RIM, KDE WHATWG */
-moz-render:medium; /* Mozilla WHATWG */
-opera-render:medium; /* Opera WHATWG */
-ms-we-render-over-directx:slow; /* Not in WHATWG */
-w3c-render:discussion; /* Lonely blokes on their own */