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

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

From: Mark Davis <mark.davis@icu-project.org>
Date: Tue, 26 Jun 2007 15:14:50 -0700
Message-ID: <30b660a20706261514m6a166716n4f317b829dc7931e@mail.gmail.com>
To: fantasai <fantasai.lists@inkedblade.net>
Cc: "Addison Phillips" <addison@yahoo-inc.com>, www-style@w3.org, member-i18n-core@w3.org
How about under the #3 approach ("- generate a parse error")?

Mark

On 6/26/07, fantasai <fantasai.lists@inkedblade.net> wrote:
>
> 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.
>
> ~fantasai
>



-- 
Mark
Received on Tuesday, 26 June 2007 22:14:54 GMT

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