- From: Arron Eicholz <Arron.Eicholz@microsoft.com>
- Date: Tue, 22 Jul 2008 12:49:34 -0700
- To: "www-style@w3.org" <www-style@w3.org>
There seems to be a conflict in the tokenization and prose about escapes.
http://www.w3.org/TR/CSS21/syndata.html#characters
# In CSS 2.1, a backslash (\) character indicates three types
# of character escapes.
# ...
# Second, it cancels the meaning of special CSS characters.
# Any character (except a hexadecimal digit) can be escaped
# with a backslash to remove its special meaning.
This means
P { /*\*/*/ color: orange; }
Would display as orange.
http://www.w3.org/TR/CSS21/syndata.html#tokenization
# COMMENT \/\*[^*]*\*+([^/*][^*]*\*+)*\/
Notice the COMMENT token does not include {escape}. Parsing
According to this tokenization would mean that
P { /*\*/*/ color: orange; }
would not display as orange.
Test case:
http://lists.w3.org/Archives/Public/www-archive/2008Jul/att-0060/escaped-comment.htm
Firefox, Opera, Safari follow the tokenization rules.
IE7 follows the prose rules.
Proposal:
In 4.1.3 prepend
"Except within CSS comments"
to the sentence
# Any character (except a hexadecimal digit) can be escaped
# with a backslash to remove its special meaning.
We note that for parsing style sheets in a renderer, whether a
Unicode escape is recognized or not doesn't matter, but if there's
a CSSOM API for accessing comments, we should say somewhere that
Unicode escapes are processed within CSS comments. This will allow
serializing */ inside comments.
--
fantasai and Arron Eicholz
Received on Tuesday, 22 July 2008 19:50:24 UTC