Re: review of "The root element" subsection

On Tue, 10 Jul 2007 12:43:44 +0200, Robert Burns <rob@robburns.com> wrote:

>> No. It is not a requirement for UAs. The requirements for UAs are:
>>
>>    http://www.whatwg.org/specs/web-apps/current-work/#determining0
>
> I wasn't asking about the UA requirements, I was asking if there was any  
> research on the current behavior (that we're trying to be backwards  
> compatible with).

There was. It is documented in the section referenced above.

    http://www.hixie.ch/tests/adhoc/html/parsing/encoding/

>> Perhaps, but it isn't compatible with existing UAs.
>
> Do we already have some tests on this?

We do now... ;-)

    http://simon.html5.org/test/html/parsing/encoding/001.htm

>>> Pre-parsers will be able to find the value more easily
>>
>> Not really. They still have to look for encoding information in meta  
>> elements too. Adding more places they have to look doesn't make it  
>> simpler.
>
> Well adding:
>
> A sequence of bytes starting with: 0x3C, 0x68 or 0x48, 0x54 or 0x74,  
> 0x4D or 0x6D, 0x4C or 0x6C, and finally one of 0x09, 0x0A, 0x0B, 0x0C,  
> 0x0D, 0x20 (case-insensitive ASCII '<html' followed by a space)
>
> doesn't seem to be that much of hardship: neither adding it to the  
> pseudo part of the spec, nor the methods already in a UA preparser.

Adding things to the algorithm doesn't make the algorithm simpler  
(regardless of the amount being added).

>> How does requiring an attribute on the root instead of on a meta  
>> element that is first child of head reduce the risk of the encoding  
>> information being in the wrong place?
>
> Its just simpler to deal with attributes. When a separate element  
> doesn't add anything to the expressiveness of the language it simply  
> adds complexity and room for authoring error.

I won't argue with that.

>>> Also there will be less author error in placing the meta element in  
>>> the incorrect order.
>>
>> How can you tell?
>
> If you can tell me how you can tell it there won'' be less error, then  
> I'd have an easier time responding to the question. Is there some reason  
> for the straight nay-saying?

I didn't say there won't be less error.

>> The benefits seem weak to me compared to the drawbacks (not compatible  
>> with existing UAs, complicates implementation).
>
> It hardly complicates the implementations. I would agree that the XML  
> serialization has already solved this in a much more elegant manner. And  
> since this is a long-term solution, the text/html serialization might  
> disappear before anyone had the chance to take advantage of this new  
> feature. It's only strength would come from text/html sticking around  
> for some length of time.

Even if it didn't complicate implementation, it still isn't compatible  
with current UAs, which is the main drawback.

-- 
Simon Pieters
Opera Software

Received on Tuesday, 10 July 2007 12:21:44 UTC