Earlier today, Joe Clark responded to Tim Berners-Lee’s announcement of the W3C’s new plan for HTML. Joe has argued that fixing HTML is not as important as accessibility, and that the WCAG working group is in much more serious trouble than the HTML working group. For this, he seems to be criticizing the W3C’s decision.
He has also criticised the WHATWG and their work on HTML 5, claiming that they’re making the same mistakes as the W3C, and raised several issues and suggestions for improving HTML.
I’m not disputing his claims about the problems with the WCAG working group or the WCAG 2.0 guidelines. In fact, I agree with him in that regard. But to imply that that the W3C doesn’t need to do anything about (X)HTML or the HTML working group is misguided. Something desperately needs to be done with each of the HTML, XForms and WCAG working groups; they’re all in serious trouble and their problems need to be fixed.
The W3C’s decision to deal with the HTML working group is at least a step in the right direction. Whether the chosen path is right or wrong is yet to be seen and I’m trying to reserve judgment until more information is available. But I promise, as soon as the information I’ve asked for becomes available, I’ll review it thoroughly.
The Problems with HTML
HTML is a topic of interest. But it isn’t an outright fiasco. HTML, in large part, works fine right now.
It is true that HTML 4.01 itself isn’t a total fiasco. In many ways, it works. We’ve been using it for years without too many problems and will continue to do so for many years to come. However, there are many problems and limitations with it that need to be addressed.
There are also many problems with the W3C’s HTML working group, who have been ignoring the needs of real world developers and pushing ahead with a language that is doomed to failure. They’ve not only completely ignored backwards compatibility issues, but have failed to adequately address many other issues that have been raised.
For instance, they don’t consider error handling to be important for interoperability. They’ve made vague statements about how they don’t need to define error handling, how browsers should just refuse to handle erroneous content, and they don’t care if different browsers handle it differently.
…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.
Yes, it is true that specs do take a long time to write and a long time to implement, but there are reasons for that. The process involves many steps, designed to help ensure the quality of the final specification. But, due to the process, actual browser implementation must occur before the spec can be finished, not years afterwards.
Criticisms of the WHATWG and HTML 5
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
kbd. I use all of them and I am pretty much the only one who does.
How is HTML 5 repeating the same mistakes? HTML 5 did not introduce
var, they have been retained from HTML 4
and there is no reason to remove them.
HTML 5 has not yet introduced any more elements specifically for computer
science and mathematics. In fact, so far, proposals specifically for mathematics
have, at this stage, been rejected mostly due to backwards compatibility
and complexity issues.
The following is a list of all of the elements introduced in the current drafts of HTML 5 (I hope I didn’t miss any).
m(marked or highlighted text)
x(cross-reference to an instance of the use of a term)
t(date and/or time)
embed(not yet documented, but will be)
Of all of those new additions, which ones specifically fall into the category of computer science and/or mathematics?
- But, true to member biases, “HTML5” bans the use of
ddfor 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 complex issue. Many people have argued in the past that definition lists are strictly for marking up definitions, and that the description about using it to markup dialogue given in the HTML 4.01 spec is a mistake. But, in my view, such arguments are based mostly on the name of element, rather than its actual definition. The definition list, which I think should be called a description list (or association list), has proven much more useful in the real world as a generic structure for many kinds of name/value, term/description, or key/value pairs, and reserving it strictly for definitions is not very practical.
The current HTML 5 draft recognises this, but still notes that that it is inappropriate for dialogue. This issue was raised on the list recently and, at this stage, should be considered an open issue.
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.
I am not going to disagree with that but, Joe, as you clearly do know about such things, why don’t you get involved? If you, or anyone else presents use cases and other real world evidence that supports the need for something to be added, and it can be shown that existing markup is inadequate, we can develop something to solve the problem together.
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.”
The WHATWG is not just trying to solve problems for marking up computer-science documents. What we need is to document use cases and other evidence to show that something will be useful. We don’t need to see people using non-existent markup before we’ll consider it. We need to look at what people are using and the kind of content they are publishing to see where the limitations lie with existing markup. There is no point introducing new markup if existing markup is already suitable or if people aren’t going to use it anyway, so we need evidence that they will.
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 can. We just need to document things like use cases to show how such markup would be used, real world example content (from any media) for which it would be suitable, how authors are already marking up such content, the limitations of existing markup and an explanation of why new markup would be useful to authors and what benefits it provides to users.
We assuredly could use elements from tagged PDF like:
That’s a reasonable suggestion. Why is existing markup inadequate for this? What benefit would it provide to authors and users?
referencefor footnotes, endnotes, and sidenotes (not
There are many examples of footnotes used on the web, such as Wikipedia for instance, and I do believe it would be a valuable addition. The difficulty is in working out the best way to mark it up.
As for notes, the XHTML Role Attribute
module already has a
note value for
such things. Whether or not the
role attribute will be included in HTML
5 is not yet clear. It’s been discussed before, but I can’t recall if the issue
has been resolved or not.
article(some in “HTML5”)
article are already present, what benefit would
part element provide? How is it different from section? Its
definition in the PDF
Reference, Fifth Edition, Version 1.6 (PDF) seems rather vague:
A large-scale division of a document. This type of element is appropriate for grouping articles or sections.
It’s not clear to me when I would use it or why it would be useful to do so. Could you provide a use case?
captiongenerically applicable to tables and figures
This has been discussed before and the issue is still open. The major problem
is related to backwards compatibility. Unfortunately, it’s not as simple as
just using the
caption element because when a
caption element occurs outside
of table markup, current browsers do not include the element itself within the
There is also the issue of how to associate the
caption with the figure.
img is an empty element, so the
caption can’t be included
within it. It also can’t be included inside the
object element, because it
would be considered fallback content and not visible in current browsers.
- bibliographies, tables of contents, and indices (some in “HTML5”)
For tables of contents, isn’t existing list markup good enough? Would it
be beneficial to explicitly mark the content as the TOC? Could the
address this problem?
I don’t know much about bibliographies and indices, so no comment
nonstructfor generic groupings
Why is this useful? I don’t understand how it is different from
definition given in the PDF reference was not clear to me.
A grouping element having no inherent structural significance; it serves solely for grouping purposes. This type of element differs from a division (structure type Div; see above) in that it is not interpreted or exported to other document formats; however, its descendants are to be processed normally.
Could you provide a use case?
Similar concepts have been discussed before. As far as I know, the issue is still open. But doesn’t that fit into the category of science and mathematics that you had issues with earlier?
Nonetheless, aren’t the easiest fixes those that would make many nominally invalid documents valid and help accessibility?
- Ban tables for layout.
This will no doubt be done when the table section is written. The last I heard about this was that it’s scheduled for later this year or early next year.
- Allow fragment identifiers to start with any ASCII character, not just a letter. Suddenly hundreds of millions of Blogger comment URLs become valid.
That was a limitation of the SGML heritage of HTML, which has unfortunately been carried over into XML as a validity constraint for attributes of type ID. Note that HTML 5 is no longer considered an application of SGML, it has its own syntax requirements, but XHTML 5 is based on XML.
However, regardless of the validity constraint (as I understand it), (X)HTML 5 effectively dispenses with DTD based validity, in favour of much more rigorous conformance requirements and there is no mention of what constitutes a valid ID attribute. I believe, as long as it’s well-formed and doesn’t contain whitespace, it will be considered conforming (though I’d need to confirm that).
- 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 a little? What are the problems and limitations with
tbody? As far as I can tell, the HTML table row group model
is the same as that in Tagged PDF, so that didn’t give me any clues as to what
- Let us nest certain block-level elements in certain other ones right away, à la XHTML 2. A
preally should be able to contain an
This is already allowed. However, there are backwards compatibility issues
with making the DOM match in HTML (not XHTML). If browsers were to suddenly allow such elements
to appear within
p elements in the DOM, it could potentially break millions
of pages. However, this is not an issue in XHTML 5, it is already explicitly allowed.
embedlegal. Give it up, people:
objectdoesn’t work and never will.
This already planned to be introduced, it just hasn’t made it into the spec yet.
- Give us back
menu. They used to be in HTML before the W3C decided that CERN physics papers never need directories and menus.
menu element has already been brought back. What’s the use case
dir? The HTML 2.0, 3.2 and 4.01 specs are incredibly vague on this issue
and seem to only indicate presentational differences, which aren’t even visible
in current browsers. How is it different from
ul? What problem does it solve?
What benefits does it provide?