The following was originally written in an email to Molly Holzschlag on 2007-05-11 to explain the current situation in the HTMLWG. It is being published here by request (with minor editorial corrections) to have a public record of it.
The work on HTML5 is one of the largest and most important endeavours in the history of web standards. From the beginning, it has been essential to the development of the spec that it be done with the support of both implementers and the wider community; and with the support of 3 of the 4 major browser vendors and a rather large, open community, the WHATWG has successfully achieved as much for the development of HTML5.
Moving to the W3C
The prospect of the work being adopted by the W3C in the new HTMLWG is, in general, exciting. It’s not only proof that the WHATWG took the right course of action when it did, but rather satisfying that the W3C finally took notice and started listening.
Initially, the HTML WG wasn’t particularly productive. There seems to be a lot of new and/or inexperienced participants who are among the most active on the list, and most of the threads have been rather mundane. I considered this to be inital growing pains for the group, particularly because there was not yet an official spec to work on.
I suspected we would have an official spec fairly quickly — the WHATWG’s HTML5 spec — but the delays in getting Microsoft to join, particularly Chris Wilson, didn’t help.
Eventually, the proposal to adopt the spec was posted and the majority of the comments were quite positive, at least initially. But before the spec was adopted, the list erupted into several massive debates, that were extremely difficult to keep up with, simply due to the excessive volume of mail on the list — over 3,500 mails since the list began 2½ months ago!
Versioning Debate
Around the time Chris Wilson started participating, there was a major debate about whether or not HTML5 should include versioning for documents. The initial plan was to completely remove versioning from HTML, so effectively, there would only be one continuously evolving language that browsers could progressively implement. However, there are those that, for whatever reason, feel that versioning is essential, despite the evidence presented that showed it was harmful.
The surprising issue about this debate was Chris Wilson’s opinion about versioning and Microsoft’s apparent need to require author’s to opt-in to the latest standards mode, which has the potential to undermine the goals of achieving interoperability. The proponents of versioning were pushing for a system where they would implement HTML5 in a separate mode from HTML4 and when it was sufficiently well supported, they would freeze it’s development. Afterwards, they would repeat the process for HTML6 in yet another separate mode.
However, it turns out that what the proponents really want when you get to the bottom of their issue, is not specifically versioning for HTML, but rather require UA specific opt-ins more closely tied to the browser version than the language version. Effectively, after some arbitrary length of time when a significant portion of sites used HTML5, they would introduce frozen bug states (or bug modes) and require authors to explicitly opt-in to the latest mode yet again with a new opt-in.
The basic aim is to maintain bugs in perpetuity, rather than risk fixing any bugs out of fear of potentially break any sites that rely on them.
The problem with this approach is not only that it requires authors to use non-standard opt-ins, it becomes prohibitively expensive for browser vendors to maintain an unbounded number of distinct rendering engines, introduces more surface area for security risks, and makes interoperability between browsers even more difficult to achieve.
Luckily, 3 major browser vendors are opposed to this method. But unfortunately, that is what Chris Wilson plans to do with IE! It is unfortunate that IE’s near-monopoly market share puts Microsoft in a very dangerous and powerful position, able to get away with such a disastrous move. With great power, comes even greater responsibility, I just wish they would be more responsible.
Adopting the Spec
Although the response to the proposal to adopt the spec was initially quite positive, objections eventually came. A number of issues arose, primarily surrounding these areas:
- Obsolete/Deprecated Features in HTML5
- Author/UA Conformance Criteria in the Spec.
- Error Handling
- Presentational Features
- The Starting Point for HTML5
- Architectural Consistency between Web Forms 2.0 and XForms.
Obsolete/Deprecated Features in HTML5
There were a few people who were quite surprised to find out that HTML5 would be specifying more than just features for conforming documents. Rather, it would be specifying everything, in detail. Basically, if browsers are required to support a feature for compatibility with the web, it will be specced.
What people initially failed to realise was that there was a significant difference between features that conforming documents will be allowed to use, and the features that browsers will be required to support. There were people arguing, for example, that marquee shouldn’t be used, and so should not be included in HTML5 at all.
Once we clarified that issue, this debate split into 2 areas: having both user agent and document conformance requirements in the spec, and semantic vs. presentational features.
Author/UA Conformance Criteria in the Spec.
Many people, particularly those with less experience in spec development, were strongly requesting that the document conformance criteria be more clearly separated from the UA conformance criteria in the specification; some even suggested a separate spec entirely.
However, such people fail to realise that a specification is primarily aimed at implementers anyway, so that it can actually be implemented. A good spec needs to contain requirements for a variety of different product classes, including browsers, conformance checkers, authoring tools and documents.
Splitting the spec would just create significantly more work for the editors, and not provide any real benefit to anyone, except perhaps making it slightly easier to read for authors who think a spec should read more like a tutorial.
Error Handling
One of the goals of the WHATWG was to explicitly define error handling for HTML. The problem is that there is a serious lack of interoperability between browsers in the way they handle errors. Having consistent handling of HTML would be a significant benefit to authors everywhere. Yet, surprisingly, there were people arguing against defining error handling and insisting on a more draconian approach.
Some people would prefer to, in their words, "get things right this time around". By that, they mean reject any HTML5 document that is non-conforming in the hope that it would force authors to produce conforming documents, and somehow clean up the web. Such arguments, however, were ignoring the reality of the situation and failed to seriously consider the consequences.
The problem is that it would never work in reality. Browsers would still be required to support all the existing, non-conforming content; and introducing draconian error handling (like XHTML already has) only ends up punishing end users and browser vendors for an author’s mistake, without actually helping anyone.
The better approach to fixing the web is through improved interoperability between browsers, better quality authoring tools, more useful conformance checkers and better education for authors.
Presentational Features
It was inevitable that presentation vs. semantics debate would start up again,
and as you would expect, it primarily revolved around the B and I elements.
This is a long-standing religious debate between the semantic purists, and the
more realistic and pragmatic people.
Some people were arguing for a strict separation of presentation and content,
as if it were a goal in itself, regardless of the use cases. It’s rather ironic
that such people would object to the use of B and I on the grounds of them being
non-semantic and inaccessible, yet in the same breath promote the use of SPAN instead, which has even less semantics.
However, the B and I elements do have
clear, semantic use cases, and so they should be included.
The separation of presentation and semantics isn’t a goal in and of itself that needs to be strictly adhered to. Rather, it’s just a means to an end; and if that end can be reached without a strict separation, then so be it.
The Starting Point for HTML5
For several reasons, including those mentioned above, there were people who argued that the WHATWG’s HTML5 spec was an extremely inappropriate starting point for for the HTMLWG. Some suggested that we should start from scratch, and then incorporate selected features from the WHATWG spec, and some people even suggested that we start with HTML4 instead.
Starting from scratch would effectively throw out 3 years worth of really good work, and starting with HTML4 is inappropriate because it’s so old and poorly written, the whole thing would need to be thrown out anyway.
Architectural Consistency between Web Forms 2.0 and XForms
Eventually, the XForms WG got involved with the us in relation to the forms features. Our charter basically states that we’re to work on the forms features in HTML5 together with the XForms group, and somehow achieve “architectural consistency” with XForms and XForms Transitional.
XForms Transitional is basically a draft that Dave Ragget put together, as an extremely limited and poorly defined subset of Web Forms 2.0 with additional features for declarative, spreadsheet-like calculations.
Personally, I don’t understand why we would want architectural consistency with XForms. There doesn’t seem to be any real justification for it. In my opinion, the forms features should be developed just like any other: to solve real problems and use cases in a way that is compatible with the web. The design not be constrained by the theoretical concept of “architectural consistency”.
At last, the WHATWG specs have finally been accepted by the HTMLWG as a starting point for HTML5. Despite all the debates going on, it finally seems like something productive can happen. But given everything that has happened so far, the HTMLWG appears to move quite slowly. Although I’m really hoping things will improve now that we actually have a spec.