Re: Should we Publish a Language Specification?

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.

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

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

> which defines which header applies to which section? That only applies to 
> certain conformance classes (primarily data mining tools and authoring 
> tools); should it also be removed?

Good question. I didn't claim I have answers for all details.

> I believe you have also said that you believe that the IDL blocks and the 
> definitions of the element interfaces should be in a separate document. If 
> this is the case, would you propose defining the processing that an 
> <input> element should receive when its type is dynamically changed in the 
> scripting specification, or in the vocabulary specification? These 
> requirements would be mostly only applicable to scripted browsers, but 
> other user agents could also be affected (e.g. authoring tools or scripted 
> automation tools).
> 
> If you could clarify your position that would be very helpful.

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.

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

BR, Julian

Received on Sunday, 23 November 2008 09:22:29 UTC