W3C home > Mailing lists > Public > public-html@w3.org > January 2009

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

From: Maciej Stachowiak <mjs@apple.com>
Date: Wed, 28 Jan 2009 03:39:48 -0800
Cc: Ian Hickson <ian@hixie.ch>, Larry Masinter <masinter@adobe.com>, HTML WG <public-html@w3.org>
Message-id: <E933EA28-5EA7-4EF7-BCA1-4C5BB1995DD3@apple.com>
To: "Michael(tm) Smith" <mike@w3.org>

On Jan 27, 2009, at 9:05 PM, Michael(tm) Smith wrote:

> The audience statement above does not qualify at all what type of
> implementors or tools it is referring to. It doesn't mention "HTML
> user agents" or "browsers" or "HTML parsers" or "tools that
> implement the DOM" or "tools that expose DOM APIs".
> A "tool" could be something as simple as a plug-in for Vim or
> Emacs that enables context-sensitive editing of HTML documents,

This is the kind of tool that would need to know how to parse an HTML  

> 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

And this is the kind of tool that, if it is transforming from an XML- 
based model, would need to know how to correctly serialize an HTML  
document; or if it works by string-pasting, how to correctly escape  
things in light of how error handling will occur.

I don't think a definition of the formal syntax alone is useful for  
any nontrivial tool.

> All that said, I don't think it would be a problem even if it
> stated that it did have the same audience as the HTML5 draft.
> Having the same audience would not then necessarily require it to
> contain details about DOM APIs, parser rules, or many of the other
> things that the HTML5 draft has -- because it's explicitly not
> intended to cover everything that audience would need to know.
> It instead just covers a specific, focused part of what that
> audience would need to know -- namely, what a "conformant
> document" is.

It's not clear to me why anyone needs to have this defined in a  
document that omits all information and requirements about how a  
conformant document will be processed. For example, it is certainly  
possible to make a specification that describes the syntax of a  
conformant C++ program, and omit anything about the semantics of the  
language or processing requirements, or to do so for SVG, or CSS. In  
all these cases, no one found this useful and every audience of the  
single spec for these languages has been reasonably satisfied to have  
everything all in one place.

In fact, I don't know of any language, protocol or format of any kind  
where there is one standards document defining the legal syntax, and a  
completely separate document defining all the processing requirements  
and behavior.

No one has yet adequately explained why this is necessary and useful  
for HTML, but not for any other language, not even for any other W3C- 
specified language.

Personally, I think there are constituencies that find "that ugly tag  
soup stuff" and "that evil scripting stuff" aesthetically and  
ideologically distasteful, and therefore wish to have some sort of  
standards document purged of such unclean influences, no matter how  
nonsensical and useless the resulting document may be.

While certainly anyone is entitled to their own sense of aesthetics,  
in this case, by catering to it we will create considerable additional  
work for the Working Group, and impose ongoing future costs on  
implementors and content authors (as outlined by Henri, Lachlan,  
myself and others).

Received on Wednesday, 28 January 2009 11:40:32 UTC

This archive was generated by hypermail 2.4.0 : Saturday, 9 October 2021 18:44:41 UTC