W3C home > Mailing lists > Public > www-style@w3.org > July 2008

Re: [Selectors] Attribute Selectors with Empty Values

From: Alan Gresley <alan@css-class.com>
Date: Wed, 09 Jul 2008 15:08:11 +1000
Message-ID: <487447BB.9080004@css-class.com>
To: fantasai <fantasai.lists@inkedblade.net>
CC: Lachlan Hunt <lachlan.hunt@lachy.id.au>, www-style <www-style@w3.org>

fantasai wrote:
> 
> Lachlan Hunt wrote:
>>
>> Hi,
>>   I came across this issue while working on the Selectors API test 
>> suite.  It's not clear from the Selectors spec whether or not these 
>> selectors should match any elements:
>>
>> [class^=""]
>> [class$=""]
>> [class*=""]
>>
>> Given this element:
>>
>> <p class="foo">
>>
>> It seems that browsers disagree on this issue too.  Opera matches all 
>> of them, Firefox 3 matches both $= and ^=, but not *=, and WebKit 
>> matches none.
>>
>> This selectors test suite [1] actually requires WebKit's behaviour, 
>> but I just can't find where this is defined in the spec.
>>
>> [1] http://disruptive-innovations.com/zoo/css3tests/selectorTest.html
> 
> Hi Lachlan,
> 
> The CSSWG discussed this issue awhile back and decided that those
> selectors should match nothing. The edits haven't made it into the
> spec yet. See
>   http://lists.w3.org/Archives/Public/www-style/2008Apr/0038.html
> 
> ~fantasai


Fantasai,


Echoing Justin Roger's statement, where does that leave the status of 
the not() syntax.

http://css-class.com/test/css/selectors/att/not-attribute-substring-no-match-empty.htm


Are Opera, Safari and IE8 now all suppose to match these selectors with 
empty strings when used with negation? If all of these are declared non 
matches along with those without negation then that would break the 
rules of negation.


Alan
Received on Wednesday, 9 July 2008 05:09:19 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 27 April 2009 13:55:10 GMT