Re: ACTION-95, ISSUE-65: Plan to publish a new WD of HTML-5

Michael(tm) Smith wrote:
> A "tool" could be something as simple as a plug-in for Vim or
> Emacs that enables context-sensitive editing of HTML documents, or
> it could be a part of a CMS that just needs to generate valid HTML
> output, but doesn't itself need to parse it

FWIW my experience is that the absolute best emacs modes (e.g. 
nxml-mode, js2-mode) implement a proper parser for the underlying 
language that they support. I would hope in time to see a HTML 5 mode 
that does the same thing and would hope that we would not actively 
discourage that by directing authors of such tools away from the HTML 5 
spec to the Markup Language spec.

> And if you take the argument that everything needs to be defined
> in the same specification to its logical end, the HTML5 draft
> itself would actually need to contain much more than it does now.
> Just because an implementor of a particular spec needs some body
> of information, it of course does not follow that the information
> all needs to be within one document. If that were the case, the
> normative spec for the XMLHttpRequest object would need to be in
> the HTML5 draft (and the spec for content-type sniffing and the
> Origin header and Web Sockets API, and the Web Sockets protocol).

There is the question of the difficulty of separating two parts of the 
spec. Making this document normative and keeping with the sane policy of 
only defining everything exactly once implies an undertaking of effort 
to remove all the corresponding text from the HTML 5 draft, create a 
complex web of normative references and ongoing effort to ensure the 
documents remain in lockstep with each other; a process that seems to be 
highly unreliable. This is a significant amount of work (indeed it has 
been noted that the drafts are already out of sync), yet the appeal of 
the Markup language spec seems to be to people in the set ((producing an 
HTML document | producing a tool to produce HTML documents) & don't 
require APIs or scripting & don't need to consume HTML & understand 
complex formal languages). As far as I can tell this leaves a small 
subset of authors and a probably small subset of authoring tools. 
Everyone else will need to look at the HTML 5 spec proper. Given the 
likely complexity of making the split and the apparently small group of 
beneficiaries, I don't see the value proposition for making this 
document normative adding up. I don't think the existence of other cases 
in which the value proposition did add up should be used a priori as 
evidence that the same will be true in this case.

Received on Wednesday, 28 January 2009 10:31:19 UTC