W3C home > Mailing lists > Public > www-style@w3.org > March 2013

Re: [selectors4][naming] Renaming :matches() (was: Proposal: Logical Combinators / Sets)

From: Peter Moulder <peter.moulder@monash.edu>
Date: Thu, 21 Mar 2013 14:08:34 +1100
To: www-style list <www-style@w3.org>
Message-id: <20130321030834.GA16856@bowman.infotech.monash.edu.au>
On Wed, Mar 20, 2013 at 05:10:26PM -0700, Tab Atkins Jr. wrote:
> On Wed, Mar 20, 2013 at 5:01 PM, Peter Moulder <peter.moulder@monash.edu> wrote:
> > On Wed, Mar 20, 2013 at 11:28:35PM +0100, Simon Sapin wrote:

> >> But one counter-argument that convinced me is that it doesn’t make
> >> any sense with a single argument. This can be useful when that
> >> selector contains combinators:
> >>
> >>   ol li:matches(aside li)
> >>
> > Ooc, what's the reason that the above rule is (apparently quite deliberately)
> > invalid in the current selectors4 ?  Just wondering whether that reason might
> > be relevant to what the matches-any pseudo-class should be called.  E.g. I
> > wonder whether there's a chance that we'll end up with a different name or
> > syntax for combinators anyway, in which case the above argument might be moot.
> Because complex selectors are more expensive than compound selectors.
> (A lot more, afaik.)

If we never expect complex selectors, or any other useful "single argument",
in :any or :any-of, then there isn't a problem with calling it :any or :any-of.

If in fact these performance concerns can be ameliorated by separating the
"any-of" functionality from the "intersection of complex selector matches"
functionality (e.g. by calling one of them :any or :any-of and calling the
other one :matches or :all-of(ol li, aside li)), then that might actually be
an argument positively in favour of renaming to :any or :any-of.

(I don't actually object to the name :matches, I'm just thinking of arguments
that might be relevant to the decision.)

Received on Thursday, 21 March 2013 03:08:59 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:39:09 UTC