Re: Splitting up the spec

Jim Jewett wrote:
> 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 approach makes it impossible to actually use the "markup spec" for 
even writing an authoring tool.  What exactly is the point of this 
"markup spec", again?

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

That doesn't sound right, since iframes with names that start with '_' 
but aren't in the predefined set are non-conforming, last I checked.

> Therefore
> any reference to the browsing context definition should explicitly be
> only informative, rather than normative.

Informative circular references are even worse than normative ones, 
since they're more likely to become stale...

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

 From an "I'm an implementor trying to implement this spec", the latter 
is often simpler, depending on how the inclusion and the referencing are 
done and how tightly related the two things are.

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

 From the markup perspective, what the heck is "a browsing context"? 
 From the "markup" perspective when creating an actual HTML application, 
does the application creator need to know that some targets will make 
his application go away while others won't?

> 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 doesn't make it any better, as I said above.

-Boris

Received on Monday, 24 November 2008 21:39:51 UTC