Re: Splitting up the spec

Asbjørn Ulsberg wrote:
>> 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?
> 
> I believe there is a very valid use-case for an as pure "markup spec" as 
> possible, and that is: Authors.

As people keep saying (including the ones advocating splitting things 
up), authors should be reading authoring guides, not specifications.

> Being able to reference the markup 
> elements and attributes without the interference of DOM and scripting 
> definitions is a huge plus-side of the HTML4 specification.

I've always seen it as a downside, as an author, that I have to go to 
two separate places to get information about the one thing I want, and 
then try to synthesize it...  But then again, I've always seen it as a 
downside, as an author, that I have to read either the HTML4 spec or the 
DOM2 HTML spec at all, what with the cryptic DTD mess, the complexity 
and interconnectedness of DOM2 HTML, etc.

> While HTML5 successfully tries to specify a heck of a lot more than 
> HTML4 in terms of how HTML actually works, I have to agree with Jim and 
> Toby in that the HTML5 specification would be better

Better for what target audience of the specification itself?  Authors 
aren't it.

>> Informative circular references are even worse than normative ones, 
>> since they're more likely to become stale...
> 
> True, and I agree that circular references should be kept at an absolute 
> minimum or best of all; avoided completetly. There is a way to avoid 
> them: Write the specifications in layers or levels, where the reference 
> and dependencies only one way (up or down, depending on your perspective).

This works well when defining new things.  It's _very_ hard to do when 
specifying existing things that don't have the benefit of splitting up 
nicely like that.

> If we could think of "HTML5: Markup and Document Object Model" as "level 
> 1" in this stack of specifications, "level 2" could be "HTML5: 
> Processing", "level 3" could be "HTML5: Scripting", "level 4" could be 
> "HTML5: Interfaces and plugins", etc. Level 4 would reference level 3 
> which would reference level 2 which would reference level 1, but never 
> the other way around.

I'd love it if you could actually draw such lines, but given the 
existing behavior, you can't.  Parsing has normative dependencies on 
scripting and vice versa, for example, in a UA that supports scripting.

This can be done if the "lower" specs provide abundant integration 
points for the "higher" specs to hook into, but this enormously 
increases complexity.

> I'd like to see level 1 be as bird's eye view and HTML author-friendly 
> as possible, without heavy scripting references or intricate parsing 
> algorithms.

Again, there is no need for the normative specification to be 
author-friendly.  In my opinion.

-Boris

Received on Monday, 24 November 2008 22:31:08 UTC