W3C home > Mailing lists > Public > public-html@w3.org > November 2008

Re: An HTML language specification

From: Ian Hickson <ian@hixie.ch>
Date: Sun, 23 Nov 2008 04:53:35 +0000 (UTC)
To: Jim Jewett <jimjjewett@gmail.com>
Cc: HTML WG <public-html@w3.org>
Message-ID: <Pine.LNX.4.62.0811230422280.19276@hixie.dreamhostps.com>

On Sat, 22 Nov 2008, Jim Jewett wrote:
> > 
> > This would be a very weird split ("vocabulary" vs "DOM and processing 
> > requirements"), with, to my knowledge, no precedent.
> It isn't that far from the split betwen HTML and DOM in previous specs.  

HTML4 contains all the implementation requirements of the HTML4 language. 

Are you proposing splitting just the DOM, or the DOM and the 
implementation requirements?

> > Why should authors that don't write script be somehow segregated from 
> > authors that do write script?
> Because there are many authors who do not write script, or who leave the 
> scripting portion to someone else.

There are plenty of authors who don't write forms, too.

> What these authors need is a strict subset of what the scripting authors 
> need, but it is already complicated enough that there is value in 
> keeping it as short as possible.

I think it's more likely that what these authors need is an authoring 
guide or a good set of tutorials.

> > Why should implementors have to read two specifications to work out 
> > how to implement one feature?
> Why should they have to read what ought to be ten separate 
> specifications to implement what ought to be only one of the ten?

Your question has assumption with which I don't agree, but ignoring that, 
the answer is: because it would help those who want to implement more than 
just one of the parts. Ignoring parts of a spec is far, far easier than 
piecing together multiple specs (I have learnt that through painful 
experience over the past few years).

My original question stands, though -- why should implementors 
implementing one feature need to read two documents? That seems like a 
recipe for bugs, a problem which we really need to avoid given the poor 
state of browser implementations.

> > What about authors who want to write documents with no images? Surely 
> > they don't need to know anything about <img>; does that mean we should 
> > have a spec without <img> too?
> There were versions of the spec that excluded "fancy" things like tables 
> and forms.  There are certainly versions that excluded frames.  You 
> still keep tables in a separate section, because they are easier to 
> understand that way.
> Eliminating one or two elements won't make the spec sufficiently shorter 
> to be worth doing.
> Eliminating all the scripting-only interfaces will.

I guess we could make a view of the document that hides the scripting as 
well as the implementation requirements, when we set up the multiple 
views. I don't think we want to make them separate documents at the source 
level though. I don't think that would go far towards achieving the goal 
of helping authors, and I think it would hurt a number of our other goals, 
such as staying on schedule, getting quality implementations, ensuring we 
don't have holes in the specs, etc.

Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Received on Sunday, 23 November 2008 04:54:13 UTC

This archive was generated by hypermail 2.4.0 : Saturday, 9 October 2021 18:44:39 UTC