W3C home > Mailing lists > Public > whatwg@whatwg.org > July 2013

Re: [whatwg] Requiring the Encoding Standard preferred name is too strict for no good reason

From: Martin Janecke <whatwg.org@prlbr.com>
Date: Thu, 1 Aug 2013 00:56:10 +0200
Message-Id: <EF7C1B0A-17F8-4830-8C8E-E85D2D52ED2E@prlbr.com>
To: whatwg <whatwg@lists.whatwg.org>
Am 31.07.2013 um 22:33 schrieb Ian Hickson:

[]

>>> I would rather go back to having the conflicts be caught by validators 
>>> than just throw the ISO spec under the bus, but it's really up to you 
>>> (Henri, and whoever else is implementing a validator).
>> 
>> Consider a typical case. Joe Q. Author is using ISO-8859-1 as he has 
>> done for years, and remains happy, until he tries to validate his page 
>> as HTML5. Is it useful that he gets an error message (and gets 
>> confused), even though his data is all ISO-8859-1 (without C1 Controls)? 
> 
> No, it's not. Like I said, I would rather go back to having the conflicts 
> be caught by validators.
> 
> 
>> Suppose then than he accidentally enters, say, the euro sign  because 
>> his text editor or other authoring tool lets him do  and stores it as 
>> windows-1252 encoded. Even then, no practical problem arises, due to the 
>> common error handling behavior, but at this point, it might be useful to 
>> give some diagnostic if the document is being validated.
> 
> Right.
> 
> Unfortunately it seems you and I are alone in thinking this.

Well, I agree with this.

I don't see any sense in making a document that is declared as ISO-8859-1 and encoded as ISO-8859-1 non-conforming. Just because the ISO-8859-1 code points are a subset of windows-1252? So is US-ASCII. Should an US-ASCII declaration also be non-conforming then -- even if the document only contains bytes from the US-ASCII range? What's the benefit?

I assume this is supposed to be helpful in some way, but to me it just seems wrong and confusing.

Martin
Received on Wednesday, 31 July 2013 22:56:43 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 17:00:03 UTC