W3C home > Mailing lists > Public > www-style@w3.org > January 2012

Re: [css3-syntax] CSS escape sequences

From: Kang-Hao (Kenny) Lu <kennyluck@csail.mit.edu>
Date: Fri, 20 Jan 2012 23:58:52 +0800
Message-ID: <4F198F3C.2040803@csail.mit.edu>
To: Mathias Bynens <mathias@qiwi.be>
CC: WWW Style <www-style@w3.org>
(Cc+ www-international)

(12/01/20 21:57), Mathias Bynens wrote:
> Ok so what’s the status here? Should we file bugs with all browsers except
> Firefox, asking to fix this? Does the spec need amending?

Do you have reasons to use the "composing two code points to one trick"
besides the fact WebKit doesn't support 6 digits decimal? I go for
amending, although I can sort of imagine the trick being easier to use
because this is what you get if you query the identity of that character
from JavaScript and doing the 2 * UTF-16 code units → Unicode characters
math isn't that easy.

If we are to go to Firefox's direction, I propose a simple fix like this:

  # If the number is outside the range allowed by Unicode (e.g.,
"\110000" is above the maximum 10FFFF
  # allowed in current Unicode), the UA may replace the escape with the
"replacement character" (U+FFFD).
 
to

  | If the number is outside the range allowed by Unicode (e.g.,
"\110000" is above the maximum 10FFFF
  | allowed in current Unicode) or the character this number represents
can not be stored in the UA (e.g.
  | surrogate characters can't be stored in a UA that uses UTF-16 as the
internal encoding for characters),
  | the UA may replace the escape with the "replacement character" (U+FFFD).

although it seems to be better it this is a 'should' or a 'must' instead
of a 'may'.

I don't know if characters in ISO 10646 means a Unicode code point or a
Unicode character. If it means the latter, the prose needs to change to
match that (i.e. s/above the maximum 10FFFF/above the maximum 10FFFF or
in between D800 to DFFF/ )

Cheers,
Kenny
Received on Friday, 20 January 2012 15:59:21 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:48 GMT