W3C home > Mailing lists > Public > public-html@w3.org > November 2008

Re: Splitting up the spec

From: Toby A Inkster <tai@g5n.co.uk>
Date: Mon, 24 Nov 2008 17:01:11 +0000
Message-Id: <8EF594A6-34C7-41D3-B597-33D2EA6651DB@g5n.co.uk>
Cc: public-html@w3.org
To: Boris Zbarsky <bzbarsky@MIT.EDU>

On 24 Nov 2008, at 15:15, Boris Zbarsky wrote:
> Toby A Inkster wrote:
>> A better analogy might be taking a "rulebook for using the English
>> language" and splitting it up into separate books
> That's an interesting thought experiment, because I think it has  
> some of the same issues as we face here.  What is the dictionary  
> definition of the words 'a' and 'the' and how are they to be  
> defined without defining the grammar?

I have never said that the parts may not normatively reference each  

In the case of 'a' and 'the', a vocabulary could define these as 'the  
indefinite article' and 'the definite article' respectively. The  
grammar could then say that when nouns are used, they are typically  
prefixed with the definite article when it is clear from context  
which instance of the noun is being referred to and the indefinite  
article when it is not, with an exception to the latter rule when the  
noun is used in its plural form. Such a definition might be not be  
especially helpful for people learning English as a foreign language,  
but that merely suggests that good English tutorials are needed too.

> Heck, consider the grammatical construction "would have been  
> writing". Please describe to me the vocabulary sections for  
> "would", "have", and "been"?

I'm not going to go into definitions for various words. The word with  
the longest definition in the OED is "set", as it has so many  
different senses in which it can be used. I'm sure that if you were  
to look up those words, the definitions of all of them would be very  
comprehensive, and include the sense in which they are used in your  

Again these would be candidates for normative references between the  
vocabulary and grammar.

> I should further note that in practice when learning a language one  
> doesn't learn it by learning the vocabulary, then the grammar, etc.

Indeed, but one learns a language from a tutorial-type book, not the  
specification. This goes for human languages as well as markup  
languages, and programming languages too. You don't learn, say, C  
from the EBNF syntax specification, but rather from a tutorial.

> How do you explain the meaning of parts of the markup language whose
> only purpose is to affect the DOM in that setup?

I'm not so sure that there are any such parts.

> Heck, how do you explain the meaning of parts of the markup  
> language whose only purpose is to affect navigation (say the  
> "autocomplete" attribute of <input>).

Similarly to how it is already explained in WF2.

That autocomplete="off" indicates that an <input> element is either  
of a particularly sensitive nature or is a value that is unlikely to  
ever be reused. It indicates that the page author believes that the  
<input> element cannot usefully be or should not be pre-filled by  
assistive technology.

> I think everyone agrees that the SQL stuff needs to be split out at  
> some point.  I challenge you to point to someone who argues against  
> that. The bone of contention is element definitions, element DOM  
> APIs (arguably an integral part of element definitions, though  
> apparently not to you), and things like the Window and Document  
> objects.

I think in my last list of suggested splits I included the element  
and attribute definitions, DOM and document object as all being  
included within the HTML5 markup language specification. Originally,  
I listed the DOM/document part as being a separate specification, but  
I can see valuable arguments in both directions. Overall, I think a  
combined specification for markup and DOM is probably slightly  
preferable, but think that it should be structured so that each  
element is defined without reference to the DOM, and the DOM is then  
defined in reference to the element and its attributes. This way,  
user agents that do not build a DOM may still be able to implement  
some sort meaningful support for the element.

My most recent list of suggested splits:

1. The chapter numbers I used are from the latest public working  
draft on the W3C site; in more recent editor's drafts, many of these  
numbers have changed.
2. I say 'i.e. the "document" object in Javascript, but no other part  
of the document object' which doesn't make much sense. What I mean is  
'i.e. the "document" object in Javascript, but not other part of the  
Javascript API'.

Toby A Inkster
Received on Monday, 24 November 2008 17:02:02 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:15:39 UTC