Closed Bug 561154 Opened 14 years ago Closed 4 years ago

fix specificity of :-moz-any()

Categories

(Core :: CSS Parsing and Computation, defect)

defect
Not set
normal

Tracking

()

RESOLVED FIXED
81 Branch
Tracking Status
firefox81 --- fixed

People

(Reporter: dbaron, Assigned: emilio)

References

Details

Attachments

(1 file)

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.
Assignee: nobody → hyatt
Assignee: hyatt → nobody
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 > 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 case?
Blocks: 730280
Blocks: 906353
Specificity of a selector containing `:-moz-any` should probably be just equal to specificity of the standard selector it is a replacement of. For example this: .example :-moz-any(UL, LI) { margin: 0; padding: 0; } makes it impossible to override with a rule like this: .example UL + UL { border: 1px solid #ccc; margin-top: .3em; padding-top: .3em; } So we are forced either to use a redundant `:-moz-any()` containing just _one_ simple selector: .example :-moz-any(UL) + UL {} or use a different selector which is not always an option: .example UL:not(:first-child) {}
No longer blocks: 906353
Blocks: 906353

This is strictly better and more flexible, but can change specificity so
have a pref in case it causes trouble. I doubt it will though, the
specificity rules of :is() make more sense, and my gut feeling is that
:-moz-any is not very used on the wild.

Make it early-beta-or-earlier for now to minimize risk, once this is on
nightly for a bit we can enable it everywhere.

Assignee: nobody → emilio
Status: NEW → ASSIGNED
Pushed by ealvarez@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/13c2bda8cb38 Implement :-moz-any() as an alias of :is(). r=heycam
Status: ASSIGNED → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → 81 Branch
Blocks: 1666086
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: