Re: [attr|=""] Selector

Bert Bos wrote:
> On Wednesday 02 April 2008 18:50, fantasai wrote:
>> Bert Bos wrote:
>>> This test:
>>>
>>>    
>>> http://www.w3.org/Style/Examples/013/css3-selectors-0603-empty.html
>>>
>>> tries to test substring-matching attribute selectors ~=, |=, ^=,
>>> *=, $= (Selectors section 6.3[1]) with empty values, such as
>>> p[title^=""].
>>>
>>> It assumes that such selectors are valid (i.e., not ignored) but
>>> match nothing. I think that is what we decided last week[2]. I'm
>>> not sure if we decided anything for |=, but it seems consistent to
>>> treat it the same way.
>>>
>>> This test:
>>>
>>>     http://www.w3.org/Style/Examples/013/t050801-empty-attr-01.html
>>>
>>> is the same, except that it only tests ~= and |=, and is thus
>>> suitable for CSS level 2, section 5.8.1[3].
>>>
>>> [1] http://www.w3.org/TR/css3-selectors/#attribute-selectors
>>> [2] http://www.w3.org/2008/03/28-css-irc.html#T00-52-44
>>> [3] http://www.w3.org/TR/CSS21/selector.html#matching-attrs
>> Bert, [attr|=""] is not an ambiguous (match everything or match
>> nothing) case. It is very clear from the existing definition that it
>> should match attr=""
>>    attr="-foo"
>>    attr="-"
>> and not
>>    attr="foo--"
>>    attr="foo"
> 
> I would drop the "very" and probably the "clear," too :-) It's not any 
> more clear than the other substring-matching attributes. None of them 
> says that the right-hand side must be non-empty to have an effect, and 
> yet that is what we decided it meant.
> 
> It seems consistent to treat |= the same as ~=, except that the former 
> uses white space as separators and the latter dashes. So if

Their definitions are not the same, and the WG resolutions have all left
the |= defintion untouched.


Consider:
   # [attr|="val"] Represents an element with the att attribute, its value
   # either being exactly "val" or beginning with "val" immediately followed
   # by "-" (U+002D).'

Given this definition of |= there is no ambiguity about whether [attr|=""]
matches a given attribute. None.

Now here:
   # [attr~="val"] Represents an element with the att attribute whose value
   # is a whitespace-separated list of words, one of which is exactly "val".'

Consider the following

  A) attr=""
  B) attr=" "
  C) attr="  "

If attr is considered to be a whitespace-separated list of words, is the list
given in A empty or does it contain one empty-string word? Is the list given
in B empty or does it contain two empty-string words? Is the list given in
C empty or does it contain one empty-string word or three empty-string words?

If you try to match against the empty string with ~=, these answers are not
evident from the definition. This is why the empty string case must be called
out and defined explicitly.

>     [foo~=""] does not match foo=" "
> 
> then also
> 
>     [foo|=""] does not match foo="-"
> 
> It's interesting that all browsers (at least those I tested: Konqueror, 
> Opera 9.5 beta, iCab, Safari and Firefox) indeed treat [foo|=""] and 
> [foo~=""] as matching nothing, although they treat [foo^=""] as 
> matching always.
> 
> Firefox also treats [foo*=""] as matching nothing.
> 
> Konqueror is inconsistent, because [foo~=""] doesn't match, except when 
> foo is itself empty (foo=""). I don't understand the logic of that. 
> (Safari does the same, but not Webkit.)

Follow-up: www-style

~fantasai

Received on Wednesday, 2 April 2008 18:11:14 UTC