- From: Lea Verou <lea@w3.org>
- Date: Sun, 24 Mar 2013 21:38:10 +0200
- To: Simon Sapin <simon.sapin@exyr.org>
- Cc: www-style@w3.org
On Mar 21, 2013, at 00:28, Simon Sapin wrote: > Le 15/03/2013 14:57, Brian Kardell a écrit : >> On Mar 15, 2013 9:14 AM, "Lea Verou" <lea@w3.org> wrote: >>> FWIW, I agree that :any() is a much better name than :matches(). I >>> was always baffled by the WG’s decision to name it :matches, >>> despite the existing implementations, straightforwardness and >>> brevity of :any(). >> >> Excellent :-) I think it makes more sense in historical perspective >> given the use cases they were hoping to solve and the evolution of >> ideas that were being tossed around. At this point though, any or >> any-of definitely seems more sensible. > > We discussed this on the conf call today. :any() is great when there are multiple arguments: > > some > long + combinator ~ chain:any(.foo, .bar) > > 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) > > > A good way to think of this is that :matches() does *not* take a comma-separated list of arguments, but its single argument is a comma-separated list of selectors. The pseudo-class is true for elements that *match* the inner selector list. The commas there have the same meaning as at the top level. Yup, I was in that call too :P That’s a good argument. Indeed, :any() doesn’t make sense if you don’t have a selector list. Has the idea of :and() been discussed? For example `ol li:and(aside li)` Can’t see it in this thread. It makes sense for every case I can think of, and is 3 characters instead of 7, just like :any() (of course, it doesn’t have the benefit of existing implementations, like :any() did).
Received on Sunday, 24 March 2013 19:38:30 UTC