[selectors4] :not and :matches specificity (was :not(a, b) vs. :not(a):not(b)

On Tue, Mar 19, 2013 at 02:34:39PM +0100, Simon Sapin wrote:
> Le 19/03/2013 14:14, Peter Moulder a écrit :

> >...

> >There's an issue open as to whether the specificity of :matches should change
> >from max specificity to something else, though that issue was raised before
> >:not was changed to take a selector list, so there isn't yet a corresponding
> >proposal as to how or whether the specificity of :not(a, b) might change if
> >that proposal for :matches(a, b) were to be adopted.

Possibilities include:

  - Keeping as max (which would then become the only selector to use max).

  - Same specificity as a pseudo-class.  This might match some existing
    implementations (is this what Gecko does?).  It might also be the simplest
    behaviour to implement on top of any other existing selection
    implementation that doesn't yet have :not; this might be relevant to
    polyfilling, for example.  Shorter implementation time for :not might mean
    sooner availability of other CSS features.

    From an author perspective, this would be consistent with the specificity
    of other :xxx() selectors, but leave :matches() as inconsistent -- unless
    we chose to change :matches to have this specificity too.  This latter
    option hasn't found much favour in the past (before considering the
    question of :not lists), and several people who have said that they like
    the proposed specificity-of-what-matches change to :matches specificity.

  - change to sum, so that :not(a, b) would in fact have the same specificity as
    :not(a):not(b).  More generally, the two would have identical behaviour,
    except that :not(a):not(b) should be preferred by authors as more likely to
    get the same behaviour across different UAs.

    Another reason to recommend authors to prefer :not(a):not(b) is that
    various posts in this list constitute evidence that authors are less sure
    of the meaning and specificity of :not(a, b) than :not(a):not(b), including
    the posing of the question in this message and in the message that started
    this (parent) thread.

    This brings us to:

  - Drop the list argument feature of :not.  This would reduce differences
    between selectors3 and selectors4, making life easier for both authors and
    CSS test suite authors, in addition to the reasons given above to recommend
    authors not to use the feature if it were retained.

    In implementation cost, there isn't a big difference as to whether :not
    takes a list or a single element (and some have said that a list is
    actually a bit easier for them).

> Yes, there is an inline issue in the spec:
> http://dev.w3.org/csswg/selectors4/#specificity
> 
> The specificity of :not() and :matches() are, and IMO should remain,
> consistent. I think dbaron’s proposal makes sense, but it requires
> more discussion and unfortunately the group’s focus does not seem to
> be on Selectors at all at the moment.

In the case of a simple-minded selection engine such as that in libcroco,
the proposed change to :matches specificity does have some additional
implementation cost compared to max, but the difference isn't huge.  However,
much more relevant is what the cost is for more sophisticated implementations.

There's also a runtime cost, because one needs to either evaluate all
sub-selectors (rather than stopping at the first matching one), or at least one
would need to sort the subselectors by specificity (and not sort by cheapness).

(E.g. in this optimization, simple type selectors would go to the end of the
list in this optimization, even though they're among the cheapest to evaluate
and most likely to match.  OTOH, a common case for :matches is that all the
sub-selectors have the same specificity.)

So far, I don't think these implementation & runtime costs are prohibitive
to adopting this proposed change to :matches specificity.

pjrm.

Received on Wednesday, 20 March 2013 00:43:45 UTC