Re: [HTML5] 2.8 Character encodings

On Wed, 12 Aug 2009, Julian Reschke wrote:
> Ian Hickson wrote:
> > >
> > > If HTML5 only requires two charsets, then requiring support for 
> > > equivalence tables is nonsensical.
> > 
> > How so?
> 
> 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.


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


> Also, using RFC1345 as normative definition of ASCII looks wrong to me, 
> it really should point to the ANSI spec.

I was originally going to do so, but it turns out RFC1345 is a more 
helpful reference.


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.


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


On Wed, 12 Aug 2009, Dr. Olaf Hoffmann wrote:
> 
> The meaning of some elements is different in 'HTML5' as well or is 
> defined in a more restrictive way, what excludes some use cases possible 
> in HTML4.

Yes, but in practice that's not an issue since HTML5 describes how HTML4 
UAs actually did things.


> And has far as I have seen, those changes are not mentioned
> in the current draft (as well as maybe some missing attributes).
> If we take the sample of the version attribute itself, it does not 
> define what it means, HTML4 for example does.

HTML4's statements on the matter are inconsistent with actual 
implementations and legacy content.


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


> A current draft cannot change the meaning of a previous 
> specification/recommendation and it does not change the meaning of 
> documents written in this previous language version.

Actually, it can, when the older specification was incorrect.

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

Received on Sunday, 16 August 2009 03:43:47 UTC