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