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:41:55 -0400
Message-ID: <46818823.1070602@inkedblade.net>
To: Mark Davis <mark.davis@icu-project.org>
CC: Addison Phillips <addison@yahoo-inc.com>, www-style@w3.org, member-i18n-core@w3.org

Mark Davis wrote:
> The choice of whether to do #2 or #3 in parsing depends on the 
> environment. In the case of CSS, it'd be nice to see some specific 
> examples of what happens. For example, for a programming language, the 
> difference between #2 and #3 is mostly that literals would continue to 
> work but contain U+FFFD.  That is, let's suppose that [X] represents a 
> defective byte sequence (ill-formed Unicode or escape). Then take the 
> following examples:
> Stri[X]ng x = "abcdef"; // line 1
> String x = "abc[X]def"; // line 2
> String x = "abcdef"; // line 3[X]
> But I'm a bit fuzzy on what happens in either case. Take the following:
> h1 {
> 	col[X]or: #990000;
> 	background-color: #FC9804;
>       background-image: url("butter[X]fly.gif");
> }
> Does #3 mean that all of the attributes of h1 are suppressed in the 
> above? Or only lines 1 and 3?

Under the "replace with U+FFFD" approach, the 'color' declaration would
be dropped, and the background-color declaration would be valid.
The background-image declaration would be applied, but the request for
"butter[X]fly.gif" would be changed to a request for "butter\00FFFDfly.gif"
and (assuming "butterfly.gif" is the correct filename) would fail. No
background image would be rendered.

Received on Tuesday, 26 June 2007 21:42:17 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 27 April 2009 13:54:51 GMT