- 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