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.
Very well-written and accurate summary. Though I’d probably close comments on this entry if I were you before it turns into a flame war waged by those who hold opinions opposite of yours (and mine).
When I first heard about the open call to the HMTLWG, I thought I should join out of responsibility to web standards. I really do have great affection for HTML and wanted to see it thrive, unlike XHTML 2. I didn’t expect for the list of WG members to grow to 300+ (last I checked).
What the open call has created is a very chaotic environment. It took me a few weeks before I was able to determine who was a respected member of the W3C community and who was more like me (just some designer who may or may not have any idea what he is talking about).
So, at first, I felt the need to argue with people over wild requests to remove some element. Eventually, I realized that I didn’t need to fight against these people because there are long-standing community members that won’t let stupid things happen. While I don’t agree with everything in WHAT’s HTML 5, I believe in it as the successor to HTML 4 and believe that all the decisions in the spec are made for reasons beyond my consideration. That is, I have tons of faith in the key members of WHATWG (esp. Hixie). I know that they won’t let HTML 5 get screwed up (and if it does, they won’t let WHATWG’s HTML get screwed up).
So, knowing that there are several rational people devoted to HTML 5 and knowing that there is an extreme amount of noise on the mailing list, I’ve basically taken a back seat observer approach. I don’t want to add to the noise because I think it’s hindering the people who know what they are talking about from getting work done. On several occasions, I’ve considered withdrawing from the group. I can’t reconcile leaving with the desire to be involved, though.
I can’t decide if the open call for “invited experts” was a bane or boon.
It is indeed unfortunate that you choose to continue to use incendiary language such as, “…semantic purists, and the more realistic and pragmatic people…”, suggesting that those who seek to ensure a universally accessible web (through the use of proper semantics) are some how “fanatical”, whereas those who argue for primarily presentational “design” are somehow more realistic and pragmatic.
If indeed, as you state, “The work on HTML5 is one of the largest and most important endeavours in the history of web standards.” then it should not come as a surprise to anyone that those who have fought for the adoption of accessible web development practices would also fight to ensure that moving forward our concerns are equally addressed: this cannot simply be an exercise in pragmatism, it must also advance the medium for all users, “cow paths” or not.
Now that HTML 5 has reached the point where it will move towards W3C ratification, the original WHAT WG members need to realize that this move is a “partnership”, not a wholesale adoption or acquiescence of the work that has come to date, but rather an agreement that much of the work has been good. However, personally feelings and opinions aside, other equally invested W3C working groups can and will have the mandate to comment and intercede as the ratification process of HTML 5 works it’s way through an international ‘standards’ body. Members of the W3C will have both a legal and moral obligation to ensure that accessibility and “semantic” development remain in the forefront – arguing against these types of improvements simply because it has not yet come forward is wrong. It may not be important to the kids cranking out their MySpace pages, but for governments, educational institutions (and depending on how Target.com goes) large businesses: all of these key players (and financial contributors to the W3C) will insist on as much.
You state: “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.” In any use case you care to submit, the method of “presentation” will be affected by any number of external factors, including but not limited to Adaptive Technology considerations. How is striving for equal delivery of knowledge (regardless of “presentation”) be wrong? And how can the specification authors fail to realize that if this is the continued direction of HTML5 it is doomed to ever becoming fully ratified – there are too many other points of view at the very large W3C table that will never agree to this?
As a vocal member of the “web accessibility community”, rest assured that our community will continue to fight for what *we* need and believe in, just as strenuously as those who are arguing over the specifications of <canvas> and debating the finer points of this “new” enhancement to the language.
Thanks for putting these issues in front of everyone in concise arguments.
So much to consider.
Versioning:
I commented on Andy Budd’s blog on a similar case involving css.
Obsolete/Deprecated Features in HTML5:
Didn’t you reference “painting the bikeshed or something”?
Author/UA Conformance Criteria in the Spec.:
We developers are concerned with what features there are and how to use them, but the specs really are written to tell the vendors how to implement them—particularly as related to the DOM and DOM APIs.
You say,
I would leave authoring tools out of that mix. It is their job to produce a conforming document, not be treated as a special case allowing otherwise invalid markup. Since you’re driving a car with bad brakes, you don’t need to stop for a red light? That’s exactly the silliness going on in the whatwg list.
Error Handling:
Hah! Personally, I’d like invalid markup to cause catastrophic failure. But that ain’t happennin’. I’d settle for UAs handling content having invalid markup as plain text, with an error message explicitly stating that there is invalid markup. That’s not happening either, So, specifying error handling is the next best thing.
Presentational Features:
That’s been discussed in prior posts.
The Starting Point for HTML5:
Agreed. There are several things I don’t care for, at first blush. I will confess to not yet having a good understanding of the whatwg document, though, so I’ll not go there yet.
Architectural Consistency between Web Forms 2.0 and XForms:
Way too little knowledge of the subject to comment for or against.
cheers,
gary
The language in this post seems deliberately emotive and needlessly childish in a point-scoring kind of way. Is it intended to be a political document or an objective summary of events?
John, it is indeed unfortunate that you equate “semantic purists” with interest in accessibility and “realistic and pragmatic people” with those wanting presentational features. That is simply not the case. Accessibility and pragmatism are not mutually exclusive.
Phil, it was originally written as a personal email to Molly to summarise events and give my opinion about the situation. It was not originally written with the intention to publish, but even so, it was decided that the issues it raises were worth making public. Thus, I’m aware of its emotive nature, yet I wouldn’t call it childish or political in any way.
now now, that’s a slight misrepresentation, isn’t it? this makes no mention of the fact that many of those – including myself – who argue that B and I (and others, like SUB and SUP) are presentational also request that new, more accurate elements are added to the spec to cover the reasons behind why people use those presentational elements (whether it be out of ignorance, bad authoring tools, or simply out of necessity because the current HTML spec doesn’t actually include more accurate/specific/semantic elements). you’re making it sound like we’re just saying: drop B and I and replace with SPAN.
This is not what I have said. What I said was that your choice of language makes it seem that those of us arguing for more, or enhanced semantic structure, and a “purer” representation of semantic intent are somehow “fanatical” as oppose to those on the other side of the argument who are “realistic and pragmatic”. This infers that your side of the debate is somehow superior or more balanced – and it is not. The “pragmatic” cow-paths voices are equally entrenched on their points of view, and in many instances as “fanatical” as those who argue against you.
There are many new features and enhancements being proposed to the new HTML, features that as yet have no existing “in the wild” precedence (such as <canvas>). So why then is it unrealistic or impractical to also ask for, and advocate, enhanced means of conveying semantic intent: nobody is “insisting” that garden variety hobbyists use these constructs, but for those content authors that must or should, having the correct tools and standardized means to do so is imperative. And when these same informed accessibility experts attempt to point out potential flaws (such as using @class as a carrier of this type of semantic information), rather than listening to what they say, their comments are dismissed and ridiculed whether via the HTML WG mailing list, or via the less public IRC channel.
To continue to argue against this, and to portray those of us who are asking for (and arguing for) these additions to HTML 5 as unrealistic and non-pragmatic “purists” is insulting, and does a dis-service to those who care just as equally about the future of the HTML mark up language as you claim you do, but in ways that perhaps are not as important to your personal perspective.
Advice from WAI and the PFWG on the potential accessibility impact of the absence of the headers attribute for HTML 5 will be forthcoming:
Re: headers attribute debate
will get back to you Re: headers attribute debate
Regarding the B and I elements, I can’t help thinking: “Then what about U, S, STRIKE, and BIG!?” Keeping the B and I elements because they can represent useful semantics associated with the given default presentation still seems a bit odd to me. Heck, even BLINK would fall under that.
Facts and opinions are all presented as facts in this post. That is unfortunate, even though I happen to share most of these opinions 🙂