Last Comment Bug 561154 - fix specificity of :-moz-any()
: fix specificity of :-moz-any()
Status: NEW
Product: Core
Classification: Components
Component: CSS Parsing and Computation (show other bugs)
: Trunk
: All All
-- normal with 10 votes (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
: Jet Villegas (:jet)
Depends on:
Blocks: 906353 730280 730835
  Show dependency treegraph
Reported: 2010-04-22 11:27 PDT by David Baron :dbaron: ⌚️UTC-8
Modified: 2015-01-18 03:58 PST (History)
15 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Description User image David Baron :dbaron: ⌚️UTC-8 2010-04-22 11:27:16 PDT
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 .  Ideally we'd use the last one.
Comment 1 User image Dave Hyatt 2010-04-25 15:59:37 PDT
Oops, thought I was editing a WebKit bug.  Disregard my re-assignment.
Comment 2 User image Frank Yan (:fryn) 2010-04-27 03:36:57 PDT
(In reply to comment #0)
> The various ways we could fix this are described in
> .  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.
Comment 3 User image Frank Yan (:fryn) 2010-04-27 03:43:38 PDT
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
> stylesheets.

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

Note You need to log in before you can comment on or make changes to this bug.