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

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

From: Simon Pieters <zcorpan@gmail.com>
Date: Wed, 27 Jun 2007 02:01:37 +0200
To: "Addison Phillips" <addison@yahoo-inc.com>, fantasai <fantasai.lists@inkedblade.net>
Cc: www-style@w3.org, member-i18n-core@w3.org
Message-ID: <op.tujzozab7a8kvn@hp-a0a83fcd39d2>

On Wed, 27 Jun 2007 00:57:23 +0200, Addison Phillips  
<addison@yahoo-inc.com> wrote:

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

I don't think it would be easier to debug. In the case of 'content', you  
would see on the page directly where in the replaced content there was an  

> So I think that the Internationalization Core WG would be *more*  
> satisfied with a solution that produces or allows a parse error.

IE7, Firefox, Opera and Safari all replace invalid escapes with U+FFFD. I  
don't think it is worth trying to change this when there is interop  
already and the change would result in the same effect in the common case.

Moreover, all browsers replace &#x110000; in HTML with a U+FFFD, so I  
would expect CSS to do the same.

> 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 don't understand why a parse error produces any more sign of why the  
error occured than replacing with U+FFFD.

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

Agreed, and indeed.

Simon Pieters
Received on Wednesday, 27 June 2007 00:01:43 UTC

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