W3C home > Mailing lists > Public > www-style@w3.org > February 2015

Re: [selectors] Proposal: :n-children() selector

From: Benjamin Poulain <benjamin@webkit.org>
Date: Wed, 04 Feb 2015 10:50:38 -0800
Message-ID: <54D269FE.4060703@webkit.org>
To: "Tab Atkins Jr." <jackalmage@gmail.com>, Henrik Andersson <henke@henke37.cjb.net>
CC: Matt Mastracci <matthew@mastracci.com>, Lea Verou <lea@verou.me>, www-style list <www-style@w3.org>
On 2/4/15 1:33 AM, Tab Atkins Jr. wrote:
> On Tue, Feb 3, 2015 at 9:15 PM, Henrik Andersson <henke@henke37.cjb.net> wrote:
>> Tab Atkins Jr. skrev:
>>> That said, I'd actually prefer not to implement this.  Instead, I'd
>>> prefer to get custom selectors working (at least the declarative alias
>>> kind) as suggested in
>>> <http://dev.w3.org/csswg/css-extensions/#custom-selectors>, so people
>>> can do this themselves if they want it.  Doing this well requires
>>> going a little further than what is currently written in the doc, but
>>> all very believable - basically we need a way to handle plumbing
>>> arguments through from the "custom" pseudo to the expansion, and we
>>> need some better combinators to handle "self and/or siblings", etc.
>>> With that, you could do something like:
>>> @custom-selector $rest:--n-siblings($n)
>>> :nth-child(1):nth-last-child($n) /self-and-siblings/ $rest;
>>> So that writing `.foo:--n-siblings(3)` would become
>>> `:nth-child(1):nth-last-child(3) /self-and-siblings/ .foo` after
>>> expansion.
>> Those selectors look scary. Simplicity helps authors get things right.
> You (or someone smarter than you that you're copy-pasting from) writes
> them once.  Then you can use them in the simple way, like
> `.foo:--n-children(5)`.  That's the whole point of custom selectors.
What would be the specificity of :--n-children() in your example?

If it is the specificity of the expansion, that would be hell to work with.
If it is the specificity of a single pseudo class, that may be too limiting.
>> There is also a matter of performance. I don't know how to evaluate
>> performance, but one thing is clear: browsers have the opportunity to
>> optimize if they know what you are doing.
> It'll be similarly costly, most likely.  When something has both
> proven itself popular as a custom selector *and* a native impl has
> significantly better perf, we can add it in, but I'd prefer to enable
> authors to do things themselves otherwise, rather than waiting for
> standards bodies to agree on things and browsers to implement them.
I agree. In many cases, it is easier for the engines to optimize a 
combination of simple blocks than specialize everything.

Received on Wednesday, 4 February 2015 18:51:35 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:51 UTC