[whatwg] How not to fix HTML

[Ian Hickson]

Hey Joe,

Joe Clark wrote:
> http://blog.fawny.org/2006/10/28/tbl-html/

Note that in general I would encourage you to post your suggestions 
straight to the WHATWG list, as it is not guarenteed that I will always 
see your blog posts (though in this case, at least three separate systems 
and people alerted me to your post, so...).


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

Dialogue is an open issue. What the spec says about the matter today is 
certainly not the end of the discussion. Indeed there was recently a 
thread (which I will be getting to when I next look at list elements) 
about this very issue.

(I'm starting to think that we may need a separate set of elements... 
maybe <dialog>... with <dt> and <dd> -- dialog talker and dialog... 
discourse? I dunno, whatever -- but the point is it would be backwards 
compatible with legacy UAs.)


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

Note that while it certainly is true that I'm a geek who doesn't 
understand many things outside my sphere of interests, it is _not_ true 
that such concerns are being intentionally ignored here. I encourge you 
and anyone else who has desires for what HTML should do to speak up.


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

Again, that certainly isn't the intent. Please be vocal in your 
suggestions for HTML5. They will be taken into account in due course. We 
have already added elements for time, headers, footers, sections, 
navigation, and so forth, based especially on quantified author needs 
(some of the results of the studies made for these purposes were published 
on the code.google.com site).


> We assuredly could use elements from tagged PDF like:
> [...]
>   * annotation

Could you elaborate on this?


>   * note and reference for footnotes, endnotes, and sidenotes (not aside
>     in "HTML5")

Could you elaborate on this? Does the "title" attribute cover this case? 
What do you need that isn't covered by "title"?


>   * part, section and article (some in "HTML5")

Could you elaborate on what isn't included?


>   * caption generically applicable to tables and figures

This is something that will be considered (possibly relatively soon).


>   * bibliographies, tables of contents, and indices (some in "HTML5")

Could you elaborate on what isn't covered here?


>   * nonstruct for generic groupings

Could you elaborate on what it is that <div> and <span> don't cover here?


>   * formula

Math in HTML5 is an area that is undergoing active research at the moment.


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

Because the people asking for gauges were vocal and gave solid use cases, 
while the people asking for deks were not. I have no idea what a "dek" 
is. If you could elaborate on your use cases, give examples, show Web 
pages that are working around the absence of an element for the purpose, 
etc, then that would be a huge help. As you said, I'm a geek, and I don't 
know about things outside my realms of interest. WHATWG is completely 
open; your input and the input of everyone else is not only accepted, it's 
desired. Please help us, tell us what you want, why you want it, how you 
get around the lack of it today.

(Note: <meter> is actually a gauge UI element, not a measurement element.)


> I would even be fine signing on to "HTML5" if WHAT WG made some changes.

Could you elaborate on what changes would help you get involved?


>   * Ban tables for layout.

For what it's worth, HTML5 will do this.


>   * Allow fragment identifiers to start with any ASCII character, not just
>     a letter. Suddenly hundreds of millions of Blogger comment URLs become
>     valid.

For what it's worth, HTML5 will almost certainly do this.


>   * Allow multiple uses of the same id/label in a form and suddenly it
>     becomes possible to mark up multiple-choice questionnaires accessibly.

Could you elaborate on this? I'm not sure how this would work with the 
DOM, but I'm sure there's a way of addressing the use case you have in 
mind.


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

Could you elaborate on this? Henri is currently looking closely at tables 
and now would be a very oportune time to deal with these issues.


>   * Let us nest certain block-level elements in certain other ones right
>     away, `a la XHTML 2. A p really should be able to contain an ol. (And
>     a dt really should be able to contain a p.)

It's not clear to me why a <dt> should contain a <p>, but could you 
elaborate and describe your use cases? HTML5 allows things like <ol> 
inside <p> (though admittedly, for compatibility reasons, that will only 
actually work in the XML serialisation).


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

HTML5 will make <emded> legal.


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

I'm not sure about <dir>, could you elaborate?

<menu> in HTML5 is being revived and made much more powerful (it will 
allow for dropdown menus, context menus, toolbars, etc).



Going back to some of the more political stuff:

> [tbl wrote:]
>> 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.
>>
>> [...]
>>
>> There has been discussion in blogs where Daniel Glazman, Bjo:rn 
>> Hoermann, Molly Holzschlag, Eric Meyer, and Jeffrey Zeldman and others 
>> have shared concerns about W3C works particularly in the HTML area.
>
> [...] 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?

Because there's another group competing with the W3C in this arena. If you 
want to replace the WCAG work with something better, the only way (it 
seems) to get the W3C to actually realise there's a problem is to actually 
start working on an honest to kittens solution, much like the WHATWG 
started doing about 2 years ago in the HTML space.

Start a Working Group For Web Accessibility, independent from the W3C, and 
write an alternative to WCAG2. In about 2 years, if the work you've done 
starts getting more traction than the W3C's work, then you'll get their 
attention and then they'll start fixing the WCAG work.

At least, that would be my conclusion based on my own experiences. But 
certainly, I don't think it was the "five people blogging" that did it.


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

For what it's worth, I completely agree that this is unacceptable; that's 
why one of the founding principles of the WHATWG is that the only real 
level is "contributor", and everyone is equal in that way (well, except 
the editor, but _someone_ has to actually make decisions or we'd never get 
anywhere -- so long as the decisions are based on the balance of 
information that everyone has brought to the table, that seems to work).

(There is actually a higher level too, "members", a small group of people 
who act as an oversight committee and can basically change the editor if 
the editor gets out of hand. So far the "members" have not felt the need 
to ever intervene, which I take as a sign that the process is working.)


Thanks again for your feedback. Please do send elaborate suggestions to 
this list -- you can reply to this e-mail, or, you can send individual 
comments as separate e-mails to ease tracking, either is fine. You can 
also just e-mail me directly if that would be better for you. Either way, 
the only way your comments are going to be taken into account is if you 
actually tell someone what they are.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'