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

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

From: Addison Phillips <addison@yahoo-inc.com>
Date: Tue, 26 Jun 2007 15:57:23 -0700
Message-ID: <468199D3.8020201@yahoo-inc.com>
To: fantasai <fantasai.lists@inkedblade.net>
CC: www-style@w3.org, member-i18n-core@w3.org

fantasai wrote:
>> 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
>   http://lists.w3.org/Archives/Public/www-style/2007May/0081.html
>   http://lists.w3.org/Archives/Public/www-style/2007Jun/0056.html
> and
>   http://lists.w3.org/Archives/Public/www-style/2007Jun/0062.html

We did discuss these items, but neglected to put the links into the 
minutes. Thanks for digging them out.
> 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.

I agree that these are the cases and that the deleterious effects of 
doing this are limited.

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

We didn't say that either solution was unacceptable. We only pointed out 
that introducing a parse error would make the issue easier to 
debug---and that this is much more likely than any reasonable use of 
out-of-range sequences.

So I think that the Internationalization Core WG would be *more* 
satisfied with a solution that produces or allows a parse error. Having 
a validator or parser to flag it would tell people what was wrong with 
their file. U+FFFD is an acceptable option, but less desirable only 
because it produces no sign of why the failure occurred.

I think, personally, that this is a minor issue. Out of range escapes 
will be rare in the wild, usually as some form of typo.


Addison Phillips
Globalization Architect -- Yahoo! Inc.
Chair -- W3C Internationalization Core WG

Internationalization is an architecture.
It is not a feature.
Received on Tuesday, 26 June 2007 22:57:43 UTC

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