W3C home > Mailing lists > Public > www-style@w3.org > June 2007

Re: [I18N Core Response][CSS21] out of range unicode escapes

From: fantasai <fantasai.lists@inkedblade.net>
Date: Tue, 26 Jun 2007 17:35:40 -0400
Message-ID: <468186AC.7050707@inkedblade.net>
To: Addison Phillips <addison@yahoo-inc.com>
CC: www-style@w3.org, member-i18n-core@w3.org

Addison Phillips wrote:
> Hi,
> I'm writing on behalf of the Internationalization Core Working Group. In 
> our most recent teleconference, we discussed this issue again. 
> Basically, the options for handling out of range Unicode escapes were:
> - do nothing/permit the invalid code point
> - replace with U+FFFD
> - generate a parse error
> The first option is a security risk and shouldn't be seriously 
> considered. Either of the other options could potentially be a valid 
> choice.
> We note that this issue has to do with an escape sequence representing a 
> Unicode character. It shouldn't be associated with transcoding errors 
> from legacy encodings, although it could result from a bug in an escape 
> generator. That is, such malformed sequences are generated purposefully.
> We feel that the best response to this issue is to generate a parse 
> error. Use of the replacement character might mask errors in the style 
> sheet (since there is no obvious failure or failure location), while it 
> is unlikely that the resulting sequence would produce the desired 
> stylistic behavior anyway.

I just looked at the i18n WG minutes for this issue, and I note that your
minuted discussion skipped over some of the more relevant responses to your
concern, specifically

To summarize, replacing the out-of-range escape with U+FFFD will
in almost all cases have the same effect as treating it as a parse
error. The exception is in string values, where for URIs it will
result in a broken request and for content generation it will result
in the printing of U+FFFD.

If the i18nwg has already discussed these responses and decided the
existing solution is still not acceptable, please explain in more
detail why this approach is a problem, as to me it seems like a very
simple and practical solution.

Received on Tuesday, 26 June 2007 21:36:02 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:27:29 UTC