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

Re: [CSS21] out of range unicode escapes

From: David Clarke <d.r.clarke@sheffield.ac.uk>
Date: Fri, 01 Jun 2007 09:56:03 +0100
Message-ID: <465FDF23.7050801@sheffield.ac.uk>
To: Mark Davis <mark.davis@icu-project.org>
CC: "Paul Nelson (ATC)" <paulnel@winse.microsoft.com>, www-style@w3.org, public-i18n-core@w3.org
Stepping back a little. If I understand correctly, Paul Nelson is
supporting my reasoning.

If an invalid sequence appears in the CSS, surely this will not be what
the author intended?

If the standard indicates that parsers should silently replace an
invalid sequence by a character that may be valid (e.g. within some
literal text), then validators ought to accept the invalid sequence.

If, on the other hand, it is treated like any other invalid sequence of
characters, then the CSS will legitimately fail validation and signal
that something needs to be corrected or, if being processed by a UA,
ignored.

This is the same as specifying a non-existent colour name, the CSS
declaration is ignored.


Mark Davis wrote:
> As Paul says, it depends very much on the context. FFFD works pretty
> well in many cases. If in literal text, it displays, and shows that
> something *was* there. If in the middle of syntax, because it isn't
> normally a syntax character (=, (, ), ...) it usually causes a syntax
> error.
>
> The really serious security problems are caused by simply *removing*
> an illegal or invalid sequence, or to replace them by a character such
> as "?" which has syntactic meaning in many contexts, and can thus
> cause serious misinterpretations.
>
> Mark
>
> On 5/31/07, *Paul Nelson (ATC)* <paulnel@winse.microsoft.com
> <mailto:paulnel@winse.microsoft.com>> wrote:
>
>     Of course the issue is how one is consuming the stream of text
>     coming in.
>
>      
>
>     For example, the text is going to be displayed it needs to be
>     replaced. Thus, an error in an inline CSS property would have been
>     replace if the .html file has an error as part of the initial
>     parsing/converting to Unicode. If, however, the text is a .CSS
>     file that is not displayed and the css property parser is parsing
>     it is easy to throw a parsing error and move on.
>
>      
>
>     When it comes time to render in the UA, who cares about trying to
>     render right if there is invalid Unicode escapes. Whether the
>     character is converted or turned into a replacement character the
>     result is the sameā€¦something other than what the author
>     intendedā€¦unless they were a malicious person trying to crash your UA.
>
>      
>
>     Regards,
>
>      
>
>     Paul
>
>
> -- 
> Mark
----
David Clarke



Received on Friday, 1 June 2007 08:56:39 GMT

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