Toby A Inkster wrote:
>> 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 other.
If they do this, it introduces a large amount of overhead into the
mental model, significantly complicates the task of creating any
implementation that has to deal with both parts, and significantly
increases the risk of disagreements and things being underdefined.
Perhaps you view this as an acceptable, or even necessary cost, in view
of some greater good that comes out of the split, but it's a cost that
definitely needs to be kept in mind.
> Again these would be candidates for normative references between the
> vocabulary and grammar.
And again, the number of "circular" normative references should be kept
down to a minimum. Heck, even the number of non-circular normative
references should be as small as possible, for things to remain sane in
terms of understanding how two specifications interact.
One approach to avoiding an explosion of integration points in this sort
of situation is to develop the two specifications in lockstep, with
minimal integration points provided, but that's not what some people in
this thread are looking for (e.g. the ones who want to reuse arbitrary
parts of the specification without reference to other parts for some
other purpose).
>> 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.
While true, one implements a system that "knows" a language from 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.
I would hope that a C compiler writer in fact learns C (the language the
compiler must support, which is quite different from the language that
any single person actually writes) from the EBNF.
>> 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.
The "target" attribute of <a> is only there to affect navigation. The
on* attributes are only present to trigger script execution. The
various attributes of <script> and <style> only exist to affect
processing of the script or stylesheet. The proposed <eventsource>
element has no purpose other than to trigger DOM event dispatch. The
"reset" type of input and button has no purpose other than to trigger a
certain operation on the page state.
That's off the top of my head and without thinking too hard. An
exhaustive list would be quiet a bit longer. Note that with the
exception of <eventsource> all of these are in HTML4.
> 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.
That presupposes existence of an assistive technology, and the
editability of inputs, which is irrelevant to most conformance clases.
There are many in this thread who would feel that such a definition
would have no place in a "vocabulary" specification, and should instead
be placed in a "processing" specification.
> 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.
OK. That puts you a lot closer to my viewpoint than a number of other
people in this thread are...
> 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.
I thought you advocated normative circular references between
specifications. Why not between sections? In any case, I don't believe
this is possible given the list of things above that are attributes or
elements whose only purpose is to exert an influence on the DOM or on
the navigation model.
I'm not saying this is a good thing, by the way. Just that this is HTML
as it's existed for almost 10 years now.
> This way, user agents that do not
> build a DOM may still be able to implement some sort meaningful support
> for the element.
I think that's possible as things stand. Just ignore all the parts that
talk about the DOM and the effect the element has on the DOM.
-Boris