- From: Addison Phillips <addison@yahoo-inc.com>
- Date: Wed, 20 Jun 2007 11:22:45 -0700
- To: public-i18n-core@w3.org
All: Any comments on our proposed response (which follows)? Addison ~~~ 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. Therefore, we recommend that the CSS working group, for clarity, add this text to 4.1.3 in CSS 2.1 at about http://www.w3.org/TR/CSS21/syndata.html#q6 If the number is outside the range allowed by Unicode (e.g., "\110000" is above 0x10FFFF, the largest Unicode code point), then the parser should treat this as a parse error and a user agent must ignore any declaration containing this invalid property name or value. Note that this text is slightly revised from a previous proposal. We welcome any comments you might have on this issue. Best Regards, Addison -- Addison Phillips Globalization Architect -- Yahoo! Inc. Chair -- W3C Internationalization Core WG Internationalization is an architecture. It is not a feature.
Received on Wednesday, 20 June 2007 18:23:05 UTC