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