Re: Should we Publish a Language Specification?

On Sun, 23 Nov 2008, Julian Reschke wrote:
> Ian Hickson wrote:
> > Would you say the same for <script> and <style> in HTML4? How about 
> > <input type="hidden"> and <button type="reset">? How about the form 
> > submission model?
> > 
> > (I'm trying to work out where you draw the line.)
> 
> Of course drawing the line is not easy.

The current line (anything that is required to implement the markup 
language and its APIs in any conformance class) is reasonably easy to 
draw. It would exclude the storage section and Web sockets, which I agree 
should be split out in due course, but other than that it's pretty much 
the current spec.

If we want to split it differently, we need to define how that is to be 
done. Just saying it should be done and not clearly defining what the 
split should be isn't very helpful feedback. :-)


> > Some features aren't useful for the browser platform at all, but are 
> > very useful in other contexts, like <meta name="generator"> or <a 
> > rel="tag">.
> 
> Why is a/@rel not useful for the browser platform?

Some <a rel=""> values (e.g. stylesheet) are, others (e.g. tag) are not. I 
just meant to refer to rel=tag above.


> > Should these features also be taken out of the language specification 
> > and put into another specification? How about the outline processing 
> > model,
> 
> The latter ones are useful features of HTML5 as a document markup 
> language, so of course they should be in.

One could also say that the scripting APIs are useful features of HTML5 as 
an application markup language, so of course they should be in too.

How do you draw the line between "document" and "application", especially 
given the state of the Web? Personally I think trying to draw a 
distinction is old-fashioned. The Web has moved on, even static pages have 
script (the penetration of analytics tools like Google Analytics and its 
competitors is surprisingly high).

My point here being that there is nothing obvious about any of this, so 
saying "of course they should be in" is IMHO either disingenuous or shows 
a naive approach to the problem.


> I think I said before that in *my* opinion, forms submission could be a 
> separate module, as it isn't needed as part of the *document* markup 
> language.

Should elements like <canvas> be in, then? How about <input> and <output>?


> So yes, different people will propose different granularity. But that 
> fact doesn't imply that no granularity at all is the right answer.

We do have granularity. Things like CSS, SVG, JS, DOM Core, and HTTP 
aren't in HTML5. The current scope (with some exceptions that should be 
fixed in due course, as noted earlier) is pretty well-defined and does 
have granularity, albeit granularity you don't like.


I'm not sure how the chair want to proceed at this point, but I think that 
if the group is to adopt a proposal like yours, we will need a lot more 
detail as to exactly how you propose to split the spec.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Sunday, 23 November 2008 09:40:40 UTC