Shortly I'm going to land bug 544834, which implements the :-moz-any() selector. This patch, however, doesn't handle specificity properly; it just treats :-moz-any() as having the specificity of a pseudo-class.
The various ways we could fix this are described in
http://lists.w3.org/Archives/Public/www-style/2010Feb/0263.html . Ideally we'd use the last one.
Oops, thought I was editing a WebKit bug. Disregard my re-assignment.
(In reply to comment #0)
> The various ways we could fix this are described in
> http://lists.w3.org/Archives/Public/www-style/2010Feb/0263.html . Ideally we'd
> use the last one.
@dbaron: You mention that the last one is ideal, whereas in the w3c mailing list point, you mention that the next-to-last one might be best. Which do you mean?
If you mean the next-to-last one, I propose a solution:
In the blog post, you mentioned that this selector is slower when it is the right-most selector, since it isn't in the tag bucket. Couldn't this new selector simply be treated as syntactic sugar and be pre-compiled (expanded in this case) to "regular" CSS before matching? Then "p:any(:hover,#mypara)" would expand to "p:hover, p#mypara" which would have the proper specificity. Doing this would not require a new code path for matching.
I just read that you wrote in the bug for the implementation:
> I expect this will speed up some existing selectors in our user-agent
In that case, my proposal is probably faster than the existing implementation
when -moz-any() is used as the right-most selector (assuming that matching is
slower than pre-compilation) but slower otherwise. I wonder which is the common