How not to fix HTML

Tim Berners-Lee decides to actually do something for a change. Unfortunately, it’s the wrong thing.

• The perceived accountability of the HTML group has been an issue.

  He means the actual accountability. Couching the issue in the term “perceived accountability” makes it seem as though TBL thinks the HTML Working Group is perfectly accountable and all he has to deal with is everybody else’s mistaken impressions. It’s everybody else’s impressions that determine whether or not the group is accountable. Our opinions count, not theirs.

  An issue was the formation of the breakaway WHAT WG, which attracted reviewers though it did not have a process or specific accountability measures itself.

  “Accountability measures” like what? Multinationals stacking the working group? Holding working-group meetings in far-flung capitals on different continents so everyone is equally inconvenienced in attending?

  Why is it that the HTML Working Group has a problem of “perceived accountability,” while WHAT WG “did not have… accountability” at all?

  In what way does WHAT WG not have a “process”?

• There has been discussion in blogs where Daniel Glazman, Björn Hörmann, Molly Holzschlag, Eric Meyer, and Jeffrey Zeldman and others have shared concerns about W3C works particularly in the HTML area.

  HTML is a topic of interest. But it isn’t an outright fiasco. HTML, in large part, works fine right now. Even a site with tag soup and invalid HTML works in browsers. We know that such a site is no good technically. We are discouraging such sites – or at least those in the Web-standards movement are; the W3C has barely helped us at all in that regard. Even with those provisos, HTML pretty much works.

  Meanwhile, WCAG 1 is old; the WCAG Working Group is the target of more suspicion, and the source of more hostility and outright mismanagement, than any other W3C group; and WCAG 2, by consensus of nearly everyone not on that Working Group, is an outright failure.

  So we’re starting our fixes with HTML?

  Why?

  Because five people posted on their blogs about it? More than five people posted about WCAG 2. Why aren’t we starting there?

  HTML is working OK but Web accessibility guidelines are in trouble. So why is HTML a priority fix?

• We had a W3C retreat in which we discussed what to do about these things.

  And how much discussion was had to abandon WCAG 2? If we’re so concerned with process and accountability, how about a public answer to that question? How about publishing an accurate précis of the dialogue about WCAG 2 at that retreat?

• Some things are very clear. It is really important to have real developers on the ground involved with the development of HTML. It is also really important to have browser makers intimately involved and committed. And also all the other stakeholders, including users and user companies and makers of related products.

  That’s fine, but only W3C employees, Members (capital M sic), and invited experts get to vote. “Other stakeholders” can be and safely are ignored. Even invited experts can be and safely are ignored.

• The plan is to charter a completely new HTML group. Unlike the previous one, this one will be chartered to do incremental improvements to HTML

  …which means that, with the W3C’s glacial processes, we’ll have a spec document to look at in 2010 and actual browser support in 2012.

  Do you really think that Web accessibility for people with disabilities will improve substantially in the time the W3C spends filing rough edges off a standard that, in broad terms, already works?

• We have strong support for this group, from many people we have talked to, including browser makers

  …who will, in turn, dominate the process. (Remember, a browser maker that is a Member of the W3C has more clout than you do and has the same clout any multinational Member does.)

HTML isn’t the problem

If you are under the impression that I am lending de facto support to WHAT WG, I’m not. Nor am I opposing WHAT WG. My concern is that WHAT WG is doing exactly what the W3C did. Due in no small part to WHAT WG’s leadership by a strict standardista with an interest in video games, “HTML5” replicates HTML’s obsession with computer-science and math elements.

• HTML has samp, var, and kbd. I use all of them and I am pretty much the only one who does.
• “HTML5” has meter (for measurements) and t for time notation. But, true to member biases, “HTML5” bans the use of dl–dt/dd for dialogue, a usage permitted by the HTML spec and in wide use by intelligent developers like me who have to mark up documents unrelated to computer science. (They’d prefer you use a thicket of blockquotes and cites. And, presumably, nullify all the indention and italicization that browsers will do by default.)

This is a classic problem in HTML development: The people doing the work are geeks with computer-science interests who do not understand, for example, newspapers, or screenplays, or, really, print publishing in general. In some obscure way, they disdain print publishing, as the Web is not print. Indeed it isn’t, but print has structures the Web doesn’t, and it doesn’t have them because people like these refuse to acknowledge they exist or simply refuse to consider them.

Years ago, and obviously unrelated to the as-yet-nonexistent WHAT WG, I tried to explain to Tantek that newspaper publishers desperately needed elements mappable to heds (perhaps the same as a heading), deks (not the same as a heading), and ledes (not the same as a paragraph or a span). Tantek told me (E-mail, 2006.05.16):

[T]he “print publications” crowd… cares much more about pixel precision, etc. They don’t (typically) bother to even mark up their headings using h1…h6. Now, if there were a bunch of Web pages today which were adaptations of print publications where they tried to use semantic markup as much as they could and then started using <div class=""> for semantics that HTML didn’t capture, then that would be evidence.

Of course there weren’t “a bunch of Web pages today” that did so; the elements didn’t exist. And that proved the elements didn’t need to be invented.

This attitude – still present in WHAT WG, though it is separate and was formed later – can be summed up as “Until we decide you are using our computer-science tags adequately, we won’t even consider the semantic needs of your documents.” I find the attitude ill-educated and uncultured. It’s Comic Book Guy deciding what will and won’t be legal on your own Web page.

For “HTML5” and the new HTML variants, why can’t we just adopt what’s already been done in other namespaces, like the Text Encoding Initiative and tagged PDF? Yes, I really mean the latter. We assuredly could use elements from tagged PDF like:

• generic heading (present in “HTML5”)
• annotation
• note and reference for footnotes, endnotes, and sidenotes (not aside in “HTML5”)
• part, section and article (some in “HTML5”)
• caption generically applicable to tables and figures
• bibliographies, tables of contents, and indices (some in “HTML5”)
• nonstruct for generic groupings
• formula

Why not just borrow those? Why give us a way to mark up measurements but no way to mark up structural elements in layouts like footnotes and deks?

Small fixes first

I’m not even insisting on the adoption of those elements; they are presented for discussion, to show there is an approach that doesn’t require TBL’s new committee starting from scratch. And I know that Ajax-style interaction needs new elements and attributes. I’m fine with that. I would even be fine signing on to “HTML5” if WHAT WG made some changes. They’re a good example of a community group plugging a hole the W3C never noticed.

Nonetheless, aren’t the easiest fixes those that would make many nominally invalid documents valid and help accessibility?

• Ban tables for layout.
• Allow fragment identifiers to start with any ASCII character, not just a letter. Suddenly hundreds of millions of Blogger comment URLs become valid.
• Allow multiple uses of the same id/label in a form and suddenly it becomes possible to mark up multiple-choice questionnaires accessibly.
• Give us actual rowgroups (not just tbody) along with colgroups in tables and maybe browsers will begin to support both of them. (Table headers also badly need fixing.)
• Let us nest certain block-level elements in certain other ones right away, à la XHTML 2. A p really should be able to contain an ol. (And a dt really should be able to contain a p.)

If you’re really intent on adding elements, add ones that already exist in the wild or used to exist in HTML. You don’t even have to look as far afield as TEI or PDF.

• Make embed legal. Give it up, people: object doesn’t work and never will.
• Give us back dir and menu. They used to be in HTML before the W3C decided that CERN physics papers never need directories and menus.

When do we take back the Web from the W3C?

Do you really think that another committee from the “consortium” with a recent history of one screwup after another, and with serious structural compromises everywhere, is going to improve HTML? Especially with such a late start?

Is improving HTML really that important? Why? So we can mark up measurements or some other new things? Why are measurements or other new things more important than, say, Web accessibility?

When do we take back the Web from the W3C?