Tag Archives: w3c

WHATWG to accelerate work on HTML5 “Living Standard”, diverge further from W3C HTML5

Google’s Ian Hickson, who is the editor of HTML5 at the WHATWG group, has announced an “Update on the relationship between the WHATWG HTML living standard and the W3C HTML5 specification” in a message that seems to express frustration at the slow pace of the W3C standards body.

There have long been two versions of HTML5, one managed by WHATWG, and the other by the W3C. When the W3C embraced HTML5 in 2007 it used the WHATWG work as its starting point. However, rather than folding its work into the W3C, the WHATWG continued to develop a separate specification of its own.

Hickson now says:

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).

A practical consequence of the split is that there will no longer be a single bugtracking system for bugs that apply to both the WHATWG and W3C specifications. These will now be managed independently.

Hickson adds:

The changes described above are unrelated to the change announced in April regarding the WHATWG’s adoption of the W3C Community Group mechanism, but together they mean we are now independent of the W3C HTML Working Group again, while still maintaining a working relationship with the W3C. [4] My hope is that the net effect of all this will be that work on the HTML Living Standard will accelerate again, resuming the pace it had before we started working with the W3C working group.

The outcome appears to be greater divergence between the two standards, with new specifications drawn up by WHATWG that may not be adopted for a long time, or may never be adopted, by the W3C. There is increasing risk of incompatibility as well, though Hickson says there will still be a “working relationship”.

One of the browser vendors most affected is Microsoft, which supports the W3C but is not a member of WHATWG.

WebKit dominance threatens mobile web standards – but who will care?

Daniel Glazman, co-chairman of the W3C CSS working group, has written a strongly-worded post describing how the “over-dominance” of the WebKit rendering engine threatens web standards.

Everyone loves the open source WebKit, so how is this so? The issue is a complex one. Those who make web browsers do not want to be tied only to those standards already ratified by the W3C as part of HTML or CSS. Therefore, they add features, sometimes in the hope that they will become standards, but use a vendor-specific prefix such as -webkit-,-moz- or -ms-. If you use those features in your markup, you do so in the awareness that they will only work on that specific vendor’s browser. The idea is that the best vendor-specific extensions become standard, in which case the prefix is dropped; or are replaced by an equivalent standard, in which case the prefix is also dropped. This has become an accepted part of the way standards are formed.

The issue now is that WebKit dominates the mobile web to the extent that web authors can assume its use without losing many users. WebKit is used in Apple iOS, Google Android, RIM BlackBerry 6 and higher, as well as on the desktop in Apple Safari and Google Chrome. Amazon also uses WebKit in the Kindle and of course the Android-based Kindle Fire.

The consequence, says Glazman, is that:

technically, the mobile Web is full of works-only-in-WebKit web sites while other browsers and their users are crying.

The further consequence, and this is Glazman’s strongest point, is that other browsers will have to pretend to be WebKit and support its extensions in order to give users a good experience – even if they have their own vendor-specific extensions that support the same features:

All browser vendors let us officially know it WILL happen, and rather sooner than later because they have, I quote, "no other option".

Glazman says “all browser vendors” which suggests that even Microsoft will do this, though that would be a surprising development.

This would mean that the -webkit- vendor-specific extensions were no longer vendor-specific. It would also meant that WebKit is in effect able to create web standards without the bother of going through the W3C:

It will turn a market share into a de facto standard, a single implementation into a world-wide monopoly. Again. It will kill our standardization process. That’s not a question of if, that’s a question of when.

says Glazman, suggesting that there is a risk of a return to the bad days when the dominance Microsoft’s IE6 prevented standards from evolving.

The parallel with IE6 is weak. IE6 was not an open source project, and the damage it did was in part because Microsoft deliberately chose not to invest in advancing HTML, preferring to drive users towards rich internet-connected Windows applications. It is difficult to see how that can happen to WebKit.

Nevertheless, the situation with WebKit is making it difficult for other mobile browsers to compete and does undermine the standards process. This is not really the fault of the WebKit team, though the W3C would like to see support for obsolete vendor-specific extensions dropped more quickly to discourage their use. Rather, it is a consequence of web authors seeing little value in adding support for other browsers that have little actual use on the mobile web.

It is worth observing that Glazman is a Mozilla guy, and his company Disruptive Innovations makes Mozilla extensions.

How can this be resolved? Glazman and others are right to raise awareness of the issue, but I doubt that many outside the standards community or browser vendors themselves will see this as a major problem.

The best fix would be for non-WebKit browsers to become more popular on the mobile web. Growing use of Windows Phone, for example, would give web authors more incentive to fix their markup. Another route to improving standards is via tools which do the right thing. Adobe’s strong support for CSS in Dreamweaver, for example, gave a significant boost to its use and helped to rescue us from font tags and the like.

Finally, it seems to me that the distinction between the “mobile” web and the “full” web is blurring, and rightly so. Users on mobile devices often tap the “full site” link where available since they have big enough screens to benefit. WebKit does not yet dominate the desktop Web. 

The two specifications of HTML 5.0: WHAT WG vs W3C

I’m just back from a workshop on HTML 5, led by web standards advocate and CSS expert Molly Holzschlag. It proved an illuminating session, though not quite in the way I had expected. Holzschlag, who works for Opera, was keen to convey the ideology behind HTML 5 rather than giving us a blow-by-blow tour of its features (though she did a little of that). She was also open about its problems, explaining that the spec is in flux and everything may change – “we make it up as we go along” – and talking about the politics as well as the technical aspects.

In her view, Microsoft is now fully on-board with IE, and committed to implementing the W3C HTML spec as it evolves. So too are Mozilla and Opera. She is less warm in this respect towards Apple, Google and Adobe, who she described as the “new Microsoft”, meaning I think that their business interests may be detrimental to their work on progressing the standard.

It is surprising to see Google mentioned in this context, since it is the company most obviously concerned to advance the browser’s capabilities, thus increasing the capabilities of its web-based platform. Ian Hickson, who is the editor of the HTML 5 specification, works for Google. Still, HTML 5 is a subject full of contradictions. One of its most curious aspects is that there are two HTML 5 specifications, one at WHAT WG, and one at the W3C, both edited by Hickson.

The history is that at one time the W3C, the official body in charge of the HTML specification, decided to replace HTML with a stricter XML-compliant language called XHTML. Real-world adoption was limited, and WHAT WG was set up by Google and browser vendors as a renegade group to work on a new version of HTML outside the W3C. When it became clear that XHTML was not achieving its goals, and that HTML 5.0 was meeting real needs, the W3C changed direction, stopped working on XHTML, and adopted the WHAT WG spec.

At this point you would have thought that WHAT WG might have closed itself down, job done. That is not the case though; it continues to work on its own version of the spec. I asked Holzschlag why this is, given that the existence of two HTML 5 specifications seems on the face of it to be destructive:

I think it’s very destructive. It’s very problematic. The WHAT working group is into innovation, and pushing the envelope, where they can’t do that in the W3C. The reason why the W3C’s stuff is important … is because it’s about open standards. The WHAT working group has no validation or validity or standing as an organisation other than its own self-involvement. The W3C is clearly the authority for most of these things.

Holzschlag emphasized that the W3C is a cross-industry body, with every browser maker and other interested parties such as Adobe represented.

Get us all round the table, and once we’ve spilt enough blood [laughs] we get on with the work and that actually goes through a very rigorous process, which a lot of people criticise and I feel it could be streamlined as well, but the bottom line is to ensure that it stays open, and it’s open standards, whereas the WHAT working group can decide any day that they want to close that door. At the W3C that can’t happen. That’s why if you’re really going to commit to anything in HTML 5, go with the W3C specs not with WHAT WG.

It’s a political issue in part, and in part it’s an ego issue. I think that Ian and his mates are great, very bright people but they are not totally mature yet … and I think that there’s a sense of self-importance going on, to be perfectly honest … I’m a little concerned about the monoculture that HTML 5 has created. So that exists and is a known factor. Everything I’ve said is nothing that hasn’t been said before publicly.

Strong words; yet overall Holzschlag conveys great enthusiasm for HTML 5 and its potential. She says that the mere fact of having all the leading browser vendors on board and talking to one another is of great significance.

But does HTML 5 exist? In some ways it does not; it is work in progress and not implemented consistently across browsers yet. That said, Holzschlag noted that the latest versions of the main browsers already implement significant parts of HTML 5; we will no doubt see more of it in Internet Explorer 9, for example. Even though Hickson said HTML 5 might not be done until 2022, it will be usable long before that.