Re: Splitting up the spec

Boris Zbarsky wrote:
> Toby Inkster wrote:
>> 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.

Agreed.

One way to break cycles is to use the simpler definition in the vocabulary
spec, and refine it in the DOM spec.

For example, in the markup, simply state that the name attribute of an
iframe element is a string, used to designate the browsing context.

The processing spec can then refine this requirement to describe the
special meanings for the empty string and strings starting with "_".

That is information you may (depending on your conformance class)
need to process an iframe name, but it isn't essential for determining
whether or not the element in serialized form is conforming.  Therefore
any reference to the browsing context definition should explicitly be
only informative, rather than normative.


> 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.

Ideally, but a recurring pattern of X references Y may be less bad than a
recurring pattern of Y includes X inline.

>>> 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.

Again, from the markup perspective, it is simply a string used
to indicate the browing context.  A browser will have more
specialized processing (though I didn't notice an actual
restriction), but those aren't needed for the Markup definition,
so the reference should strictly informative.

>> 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.

Without those, autocomplete acts as more of a comment than a
useful feature, but the definition is still valid.

> 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.

The information about how to implement ("as if the user had modified
the element's value") should stay in processing.  But saying that
the attribute exists, takes values of exactly "on" and "off", and
defaults to "on" is fine for the markup vocabulary.

If it really weren't part of the markup, then it would be DOM-only,
like the disabled attribute of style is currently specified.  (Though,
to be honest, I think that one ought to be available in the markup
as well.)

-jJ

Received on Monday, 24 November 2008 21:32:38 UTC