RE: [Selectors] Attribute Selectors with Empty Values

I'm probably late to the game on this one but...

That was an interesting decision since as Lachlan notes:
Opera matches all of them, FireFox 3 some of them, and I'll add that IE7 and IE8 (we've made no changes here, waiting for final spec wording) also matches them. The thought when I wrote the original matching logic is that:

^=, $= and *= are a subset of =, and foo="" will match an empty attribute, why wouldn't all of the other selectors match it as well? It simply doesn't make sense.

Shutting it down seemed kind of arbitrary and I really enjoyed the not([foo^=""]) arguments. I never saw any sort of conclusion that the not() syntax was desirable.

Justin Rogers [MSFT]

-----Original Message-----
From: www-style-request@w3.org [mailto:www-style-request@w3.org] On Behalf Of fantasai
Sent: Tuesday, July 08, 2008 8:49 AM
To: Lachlan Hunt
Cc: www-style
Subject: Re: [Selectors] Attribute Selectors with Empty Values


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

Received on Tuesday, 8 July 2008 16:32:45 UTC