Re: Rethinking HTML 5 (Was: Re: Semicolon after entities)

On May 2, 2007, at 2:52 PM, Jim Jewett wrote:

> On 5/1/07, Maciej Stachowiak <> wrote:
>> On May 1, 2007, at 11:00 AM, Shane McCarron wrote:
>> > Lachlan Hunt wrote:
>> >> This seems to be the source of contention in the current debate.
>> >> For the spec to be implementable, it needs to define conformance
>> >> requirements for UAs, including error handling and how to handle
>> >> both existing and future content.
>> > Perhaps if those implementation conformance constraints were
>> > defined in a separate specification, it would help to clearly
>> > divide the issue?
>> ... it is essential that the two match up when
>> they overlap.
> Would it resolve some of the acrimony if the document were split into
> two clearly marked specifications
> (1)  HTML 5.0 Language Specification
> (2)  HTML 5.0 User Agent Error Processing Specification
> (Whether to make them two separate documents, or just two different
> classes to be used on adjacent sections -- I suppose would depend on
> how tightly the two specifications were interwoven.)
> The language could stay pure.  It would be clear (at least to people
> who cared) which parts of the language were "correct", and which were
> merely "historical notes documented to aid browser implementors".

I think this would be a lot of extra work. Maybe you could skim the  
current document to see if you find the distinction between document  
requirements and UA requirements sufficiently clear as written. I  
don't think "purity" is a valid reason to do a lot of extra work, if  
the resulting conformance requirements for documents and UAs would be  

> Someone who wanted to write a validator (or a demo browser) could
> speed development by explicitly supporting only correct markup,
> instead of picking a hodge-podge of features at random.

I don't think Henri had any problem distinguishing UA conformance  
requirements from document conformance requirements in his work on an  
HTML5 conformance checker. I don't think there's a lot of value to  
optimizing the spec for demo browsers that never intend to become  
full browsers supporting all content. Surely we care more about  
helping current and future full-fledged browsers than demo browsers,  
since that is what will assure continuing competitiveness of the  
browser marketplace.


Received on Wednesday, 2 May 2007 22:45:13 UTC