Malfunctioning mindset - the HTML5 working group
For the record, I think that making Sam Ruby a chair of the HTML5 working group is a good sign, in a dismal process.
A DOCTYPE is a mostly useless, but required, header.DOCTYPEs are required for legacy reasons. When omitted, browsers tend to use a different rendering mode that is incompatible with some specifications. Including the DOCTYPE in a document ensures that the browser makes a best-effort attempt at following the relevant specifications.
To a web developer the DOCTYPE header is essential to insure a specific interpretation of HTML. If you think that HTML4 is better than HTML3 (or earlier), then the DOCTYPE is pretty damn important. In some ideal (non-existent) world, the first specification of HTML was perfect, and all browser implementations perfectly implemented the HTML exactly as in that same specification. In that world the DOCTYPE header would not be needed. In the real world, the DOCTYPE header is extremely useful, because it allows the web developer to invoke the better behaviors offered by later browser implementations, when those later implementations improve on what came before.
Seems I wrote about the DOCTYPE a year ago. My opinion has not changed.
Somehow the W3C HTML working group has walked through the looking glass. The difference between compatible and incompatible is "mostly useless". Good is bad, and the trivial is vitally important.
The constant references to XML and SGML in the HTML5 spec need to be removed. HTML is not XML. HTML is not SGML. HTML is not and never will be either XML and SGML. An appendix describing a mapping to XML would be useful. A history section describing the relationship to SGML and XML would be informative. Pretty much every other reference is a waste of time.
The massively verbose sections on parsing are a waste of time. The HTML standard is defined in terms of ASCII, and ASCII only, which makes much of the following needlessly verbose.
A DOCTYPE must consist of the following characters, in this order:1. A U+003C LESS-THAN SIGN (<) character. 2. A U+0021 EXCLAMATION MARK (!) character. 3. A string that is an ASCII case-insensitive match for the string "DOCTYPE". 4. One or more space characters. 5. A string that is an ASCII case-insensitive match for the string "HTML". 6. Optionally, a DOCTYPE legacy string (defined below). 7. Zero or more space characters. 8. A U+003E GREATER-THAN SIGN (>) character.
In other words, , case-insensitively.
Then there is the response from Ian Hickson. To be clear - I give Ian a lot of credit for tackling a large and difficult job (though Google's apparent sponsorship dilutes that just a bit), and for trying to be moderate in dealing with the HTML5 working group. Credit aside, it seems that Ian does not have the right mindset (in which he is not at all alone).
Regarding the alt="" attribute: we don’t want to say that alt="" should be optional, because that would be an accessibility nightmare. It isn’t optional, it shouldn’t be optional.
In reality the alt attribute is optional. You cannot force web developers to use the attribute, or to use the attribute well. Web browsers cannot reject HTML documents that lack alt attributes. Few web applications will be written for accessibility, and the treatment of the alt attribute in the HTML5 standard cannot change that. Better to fit the spec to reality, than insist on a fantasy.
Regarding the extensibility mechanisms — HTML5 already has literally over half a dozen extensibility mechanisms: [link]
The existing support for extensibility in HTML is lame. What we need is something simpler and more fundamental. Here I have to admit weakness in that I have no particular skill as teaching. If you do not already deeply get why Lisp and Scheme are remarkable, then I cannot offer an adequate explanation. (Who does?)
I wish Sam luck. Boy does him ever have a big job in front of him.