English analogy [was: Re: Splitting up the spec]

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 - the first
>> providing just the vocabulary; the next explaining how grammar and
>> punctuation work; another dealing with pronunciation; and another
>> teaching essay writing.

> That's an interesting thought experiment, because I think it has some of
> the same issues as we face here.  ... Should the
> vocabulary section list parts of speech next to the word, and if so how
> is that done without reference to grammar?  If it won't list the part of
> speech, how will "lead (n)" and "lead (v)" be presented?

In natural language, the grammar would typically come first.  (Well, at
least by the time you have multiple documents.  Very first would be a
"word list" that later gets superceded by the vocabulary.)

One reason for that is that the grammar is smaller and better contained.

The equivalent to the "grammar" for html is the syntax of

"<" tagname (attrname "=" attrvalue)* ">" contents "</" tagname ">"

A dictionary or thesaurus or "how to" could then reference the basic
grammar, just as the DOM processing model could reference the
basic HTML vocabulary (which in turn references -- and probably
includes -- the very small syntax portion above).

>> It's not a matter of separating out what's common and what's not
>> common. It's a matter of separating out the markup language (HTML),
>> its API (DOM) and scripting environment features (SQL, storage,
>> history, etc).

> How do you explain the meaning of parts of the markup language whose
> only purpose is to affect the DOM in that setup?  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>).

To some extent, you don't explain that in the vocabulary section, just as
a dictionary doesn't usually contain all the cultural references that make
London different from New York City.

I've already posted which parts I would split from the div, span, and
style sections in the markup vocabulary.  I'll give some more obviously
processing-related elements here.

<script>
Remove the DOM Interface portion to the processing spec
...
"The async and defer attributes are boolean attributes that indicate
how the script should be executed."
-->
"The async and defer attributes are boolean attributes that indicate
when the script should be executed."

Remove (to the processing spec) the remainder of the text in 4.3.1 and 4.3.1.1

--------------

<noscript>

keep the notes.

Only include the noscript branches.

Add a sentence stating that when scripting is enabled, the contents
will instead be treated as text, but the text itself must still be
such that it would parsed into valid noscript content if scripting
were turned off.

----------------

<eventsource>


Stop after the first two paragraphs; the rest is processing.

"""
The eventsource element represents a target for events generated by a
remote server.

The src attribute, if specified, must give a valid URL identifying a
resource that uses the text/event-stream format.
"""

------------------

<iframe>

Content Model:  Text.  If present, this text SHOULD be such that
legacy agents can parse it as fallback content, on the assumption that
iframe has a transparent content model.

Keep 1st paragraph:
The iframe element introduces a new nested browsing context.

Trim 2nd paragraph to:
The src attribute gives the address of a page that the nested browsing
context is to contain. The attribute, if present, must be a valid URL.

Remove 3rd and 4th paragraphs.

Trim 5th paragraph to:
The name attribute, if present, must be a valid browsing context name.

Remove the 6th-8th paragraphs and the note.

Keep the first sandbox paragraph.  Remove the remaining paragraphs
until the @seamless definition.

Shorten and reword @seamless to:
The seamless attribute is a boolean attribute. When specified, it
requests that the iframe element's browsing context is to be treated
though it had been inserted directly into the containing document at
this location.

Keep:
The iframe element supports dimension attributes for cases where the
embedded content has specific dimensions (e.g. ad units have
well-defined dimensions)

The next several paragraphs seem to be saying the same thing the
reworded Content model says.  Keep them if needed to be sufficiently
explicit.

Lose the final paragraph about DOM reflection.

-jJ

Received on Monday, 24 November 2008 19:00:05 UTC