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

I'd like to just back up a step and say that if you look at the
evolution and historic proposals/discussions for :matches it is easy
to see where it came from and that at different times people proposed
slightly different things that it might do or how it would work.  One
use case was that we have things like (citing dbaron's examples[1]):
--------------
/* 3 deep (or more) unordered lists use a square */
ol ol ul,     ol ul ul,     ol menu ul,     ol dir ul,
ol ol menu,   ol ul menu,   ol menu menu,   ol dir menu,
ol ol dir,    ol ul dir,    ol menu dir,    ol dir dir,
ul ol ul,     ul ul ul,     ul menu ul,     ul dir ul,
ul ol menu,   ul ul menu,   ul menu menu,   ul dir menu,
ul ol dir,    ul ul dir,    ul menu dir,    ul dir dir,
menu ol ul,   menu ul ul,   menu menu ul,   menu dir ul,
menu ol menu, menu ul menu, menu menu menu, menu dir menu,
menu ol dir,  menu ul dir,  menu menu dir,  menu dir dir,
dir ol ul,    dir ul ul,    dir menu ul,    dir dir ul,
dir ol menu,  dir ul menu,  dir menu menu,  dir dir menu,
dir ol dir,   dir ul dir,   dir menu dir,   dir dir dir {
  list-style-type: square;
}

which can be rewritten as:
/* 3 deep (or more) unordered lists use a square */
:-moz-any(ol, ul, menu, dir) :-moz-any(ol, ul, menu, dir) ul,
:-moz-any(ol, ul, menu, dir) :-moz-any(ol, ul, menu, dir) menu,
:-moz-any(ol, ul, menu, dir) :-moz-any(ol, ul, menu, dir) dir {
  list-style-type: square;
}
-----------------

Because the initial implementation just allowed compound selectors it
could side step a lot of the open questions - in some cases you
_might_ even be able to _improve_ performance if this was the only
problem you were solving because where things forks and rejoin is
immediately clear (those all represent the same element to be checked)
- there is no competing combinator (which would require answers to
questions about independence and have performance implications, etc).

To be clear though, that seems like a _minor_ use case and without
answering complex selectors which, as far as I am aware is still
desired for matches (else we probably would have named it something
like any to begin with).  Am I right?  This seems to imply that the
current case is better as something more like :any, that the multiple
case with complex support is better as something more like :any and
that the only one that is _potentially_ improved with :matches is when
you give it a single arg.

Again, I'm not entirely hung up on any name, I'm more concerned with
considering the concept and making sure that the group consider that
there are potential "like" concepts that could use consistent naming.
Call it :union or :any-of or :matches or whatever - as long as you can
answer the questions "what would the other logical ones be called" and
it seems consistent.

Received on Thursday, 21 March 2013 15:24:20 UTC