561154 - fix specificity of :-moz-any()

Status: RESOLVED FIXED

(Core :: CSS Parsing and Computation, defect)

Description

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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.

Comment 1

[Dave Hyatt]

Oops, thought I was editing a WebKit bug.  Disregard my re-assignment.

Comment 2

[Frank Yan (:fryn)]

(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.

Comment 3

[Frank Yan (:fryn)]

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?

Comment 4

[Marat Tanalin]

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) {}

Comment 5

[Emilio Cobos Álvarez (:emilio)]

Attachment: Bug 561154 - Implement :-moz-any() as an alias of :is(). r=#style

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.

Comment 6

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/13c2bda8cb38
Implement :-moz-any() as an alias of :is(). r=heycam

Comment 7

[Cosmin Sabou [:CosminS]]

https://hg.mozilla.org/mozilla-central/rev/13c2bda8cb38