Readers with an appetite for controversy will find Tim Bray's blog on HTML5 engaging and will certainly like to read the voluminous comments the piece generated. Suffice it to say, the jury is still out on HTML5, so the debate goes on.
Right off the bat, Bray writes, "I love parts of HTML5, but it’s clear that other parts are a science project. And as a sometime standards wonk, I’m puzzled by aspects of the way the spec (not the language, the spec for the language) is put together."
Bray, one of the co-inventors of XML and was director of web technologies for Sun, continues that he approves of the new elements like video, audio, and canvas and the closely-related Web Socket work, along with how the video element has shone a remorseless and very useful light on the patent-troll infestation standing in the way of better Web multimedia.
He adds that progress is well under way on implementing the pleasing parts of HTML5, and there are people thinking seriously that it may soon remove the need for compiled “native” applications on a variety of platforms."
And now for the less appealing features of HTML5: Bray pronounces the process is "clearly hard to manage," and likens it to drinking from a firehose.
Bray continues:
The Networked-Object-Model Experiment
Interoperability has been at the level of syntax, and that level has worked, so it's strange, Bray writes, that the HTML5 draft seems to disagree, providing as it does, detailed algorithms for parsing HTML, even in the face of severe syntax errors, and specifies how the results of parsing should be used to construct the Object Model. Thus, the syntax is ephemeral; the Object Model, interoperable across the network, is what matters.
He contends that the governing assumption is unproven: If all the User-Agent providers implement all these algorithms exactly as specified, complete interoperability will be achieved and people who build Web applications need no longer concern themselves with the differences between User Agents. He labels this a "science experiment."
The problem, should there be one, may be a minor one, Bray suggests, since Web application authors increasingly work at a higher level, thinking in terms of things like Rails or jQuery constructs, thus insulating themselves somewhat from the compatibility nasties.
At this point, Bray launches into a long passage on how to spec, taking issue with the section on framing. His deliberations lead him to ponder whether HTTP might work just as well for implementing purposes.
He concedes that creating a spec in the HTML5 style calls for a lot of work and finds the draft, as written, repetitive and lacking explanations of certain points. His final verdict is that he finds the spec "strange and counter-intuitive," and thinks " ... this argument between the traditional and HTML5 style of specification is interesting, maybe important, and will be with us for a while."
In the interests of fairness (not Bray's term) he has written an alternate version with the procedural specifications replaced by declarative versions, omitting all the sections which are the same as in the original version and all the closing material. In addition, Bray has added
a web socket and HTTP headers section.
His object here, he announces, is not to replace or amend the web sockets draft but merely provide a document for the purpose of comparing styles of specification. Nor does he claim that his version of the spec is either complete or accurate.
Finally, he writes, just ahead of the blizzard of comments, "The declarative version is much shorter. Is it better or worse? No, that’s the wrong question. For what kinds of specification is the HTML5 style better and for what kinds does the declarative style win?"
There will clearly be differences of opinion on this question.
More Information
HTML5 - Bray's blog entry
HTML 5 - Wikipedia
[...read more...]