Re: Specificity of :any (was Re: [css3-selectors] Grouping)

On 02/25/2010 03:16 PM, L. David Baron wrote:
> On Thursday 2010-02-25 17:58 -0500, Boris Zbarsky wrote:
>> At least in Gecko's case, what you wrote above would indeed be more
>> or less just syntax sugar.  But this:
>>
>>    :any(#authors, #publications) div
>>
>> would probably be faster to match than:
>>
>>    #authors div, #publications div
>>
>> In fact, we're looking into implementing this right now (as
>> :-moz-any()) to more efficiently deal with the numerous rules of
>> this form that appear in our UA stylesheet.
>
> So the one thing that I just realized I'm not sure how to implement
> is specificity.  (What I actually have implemented is treating :any
> as a pseudo-class and ignoring its arguments, which probably isn't
> what we want.)
>
> So given a selector like:
>
> p:any(:hover,#mypara)
>
> Should this selector have:
>
>   specificity 11 (p + :any)
>   specificity 111 (p + :hover + #mypara)
>   specificity 121 (p + :any + :hover + #mypara)
>   specificity 11 (p + :hover) or 101 (p + #mypara) depending on how it
>     matches (with 101 if it matches both ways)?
>   one of 11 or 101, not depending on how it matches (just always the
>     lowest or highest)
>
> I'd note that the next-to-last seems like it might be best,

I agree. I think anything other than that would have surprising
cascade effects, and it would limit :any()'s usefulness for
shortening unweildy selectors.

> but I can't think of an obvious way to implement it in our code.

:any() is just syntactic sugar, so, the *obvious* way would be to
expand it. :) Of course this gives you the whole combinatorial
explosion problem you're trying to solve...

As a note, the previous discussion between Tab and Brad and several
others seemed to indicate that the name :matches() made its behavior
with combinators (in the argument) more obvious.

~fantasai

Received on Thursday, 25 February 2010 23:46:52 UTC