Re: [attr|=""] Selector

On Wednesday 02 April 2008 20:10, fantasai wrote:
> 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.

Maybe that's because browsers already treat [foo|=""] the way we decided 
to treat the others?

>
>
> 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.

To a programmer, maybe: [foo|=""] matches foo="-bar", because the value 
starts with an empty string immediately followed by a dash. But that's 
the same for ^=, which is defined as:

    Represents an element with the att attribute whose value begins
    with the prefix "val".

So clearly [foo^=""] matches foo="bar", because "" is a prefix of every 
string. And yet we decided that it was *not* clear, and indeed was not 
the case.

I don't care whether the empty string matches everything or nothing 
(although I suspect that most people will not consider the empty string 
to be a prefix of anything), but I think we should be consistent.

>
> 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.)



Bert
-- 
  Bert Bos                                ( W 3 C ) http://www.w3.org/
  http://www.w3.org/people/bos                               W3C/ERCIM
  bert@w3.org                             2004 Rt des Lucioles / BP 93
  +33 (0)4 92 38 76 92            06902 Sophia Antipolis Cedex, France

Received on Wednesday, 2 April 2008 19:06:48 UTC