Re: [HTML5] 2.8 Character encodings

Ian Hickson wrote:
>> Minimally the requirement for entries in the table that contain 
>> character sets for which support is not required.
> 
> I don't see why that is a problem. The spec has all manner of requirements 
> that only apply to user agents that happen to also implement other 
> requirements first, e.g. anything to do with scripting only applies to UAs 
> that implement some scripting language.

The way it is currently phrased makes it confusing.

>> Related:
>>
>> "User agents must support the preferred MIME name of every character 
>> encoding they support that has a preferred MIME name, and should support 
>> all the IANA-registered aliases. [IANACHARSET]"
>>
>> How is this supposed to work? By updating the client every time a new 
>> alias is registered?
> 
> Yes, just like the reference to Unicode requires UAs to implement 
> whatever the latest version of Unicode is.

Does it? That's a problem as well, at least has a hard conformance rule.

But anyway, a registry usually changes faster than a standard,

> ...
> On Wed, 12 Aug 2009, Julian Reschke wrote:
>>> HTML5 describes how you handle documents intended for previous 
>>> versions as well, so that's not an issue.
>> Well, except for the things it doesn't describe anymore.
> 
> Did I miss something? I thought I'd included everything that UAs were 
> going to support.

meta/@scheme, head/@profile...

>> So I agree that the media type registration should remain in a 
>> stand-alone document, obsoleting RFC 2854, but keeping most the historic 
>> stuff in it.
> 
> This is inconsistent with the W3C/IETF agreement on the matter.

How so?

> ...
>> This simply shows, that the current 'HTML5' draft does not indicate, how 
>> to interprete previous versions of HTML documents in general, it 
>> indicates only, how to interprete 'HTML5' documents and maybe how often 
>> used current browsers interprete current HTML documents (what can be 
>> wrong or incomplete).
> 
> If you want to be told how to interpret legacy content that is 
> contemporary with HTML4, then HTML5 does a better job than HTML4.
> ...

In many cases: yes. But not in all cases.

> ...

BR, Julian

Received on Sunday, 16 August 2009 08:33:25 UTC