W3C home > Mailing lists > Public > public-css-testsuite@w3.org > April 2011

Re: [CSS2.1] escapes, characters and parsing

From: Alan Gresley <alan@css-class.com>
Date: Fri, 01 Apr 2011 22:46:36 +1100
Message-ID: <4D95BB1C.5040207@css-class.com>
To: Bjoern Hoehrmann <derhoermi@gmx.net>
CC: Peter Moulder <peter.moulder@monash.edu>, www-style@w3.org, CSS-testsuite <public-css-testsuite@w3.org>
CC CSS test suite mailing list.

On 27/03/2011 11:40 AM, Bjoern Hoehrmann wrote:
> * Peter Moulder wrote:
>> On Fri, Mar 25, 2011 at 07:59:07AM +0100, Bjoern Hoehrmann wrote:
>>
>>> The ["\2a"] selectors would match elements with node name `*`.
>>
>> That's what I would expect to happen, but if WebKit or any other UA
>> treats it as universal selector, then I can't say that the spec is
>> completely clear about it.
>
> Well, there is no reason to treat `\2a` differently from `\*` as both
> are IDENT tokens identifying the same identifier, and there is no reason
> to treat `\*` the same as `*` as the backslash is supposed to remove any
> special meaning the `*` may have and because there would otherwise be no
> way to match an element named `*` even though you can match pretty much
> every other name.


Where in the spec does it define that a backslash is supposed to remove 
any special meaning for `*`? I do see this.

   | Second, it cancels the meaning of special CSS characters.
   | Any character (except a hexadecimal digit, linefeed, carriage
   | return, or form feed) can be escaped with a backslash to remove
   | its special meaning. For example, "\"" is a string consisting
   | of one double quote. Style sheet preprocessors must not remove
   | these backslashes from a style sheet since that would change
   | the style sheet's meaning.


I think that maybe having '*' as a universal selector wasn't the best 
thing to do in CSS.


[snip]
> The place for such clarifications is the test suite. As "escaped special
> character" is among the most obvious test cases, I would expect this to
> be covered there already (be that WebKit's or W3C's or whoever's).


The current test suite [1] does not have any test with escapes like my 
recent test. I plan to submit such test but I do believe that CSS2.1 - 4 
syntax and data needs a look over. I do not know quite what to put in 
the meta asserts.

Here are some additional test.


<http://css-class.com/test/css21testsuite/escapes-029.xht>

<http://css-class.com/test/css21testsuite/escapes-030.xht>

<http://css-class.com/test/css21testsuite/escapes-036.xht>


In WebKit, the first line in 'escapes-029' only is red.


   escapes-029       body \* { background: red; }

   escapes-030       body \\* { background: red; }

   escapes-036       body \
                     * { background: red; }



Here are some additional tests where a stray escape may be present ' 
class="ڰ" '.


<http://css-class.com/test/css21testsuite/escapes-039.xht>

<http://css-class.com/test/css21testsuite/escapes-040.xht>


This time WebKit ignores a string like this '.\06B0 \*' but this is the 
same nature as 'body \*'.


   escapes-039      .\06B0 \* { background: red; }

   escapes-040      .\06B0 \
                    * { background: red; }


In FF3.6.16 and FF4b the line is red for 'escapes-040'. This I find 
usual since when does '*' overrule 'div *' in specificity?


     div * { background: green; }

     .\06B0 \
     * { background: red; }




1. 
<http://test.csswg.org/suites/css2.1/20110323/html4/chapter-4.html#s4.1.3>



-- 
Alan http://css-class.com/

Armies Cannot Stop An Idea Whose Time Has Come. - Victor Hugo
Received on Friday, 1 April 2011 11:47:11 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 1 April 2011 11:47:18 GMT