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

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

From: Lea Verou <lea@verou.me>
Date: Wed, 4 Feb 2015 00:17:59 -0500
Cc: "Tab Atkins Jr." <jackalmage@gmail.com>, Matt Mastracci <matthew@mastracci.com>, www-style list <www-style@w3.org>
Message-Id: <ECE606D4-A997-4BDE-96D1-AAD063D8060D@verou.me>
To: Henrik Andersson <henke@henke37.cjb.net>
On Feb 4, 2015, at 00:15, 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.
>> ~TJ
> Those selectors look scary. Simplicity helps authors get things right.
> 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.

Completely agree with both.
Also re:performance, it feels a bit like shifting the blame, i.e. “well *sure* this selector won’t be fast, but it’s not our fault anymore, now it’s the user’s!!”
Received on Wednesday, 4 February 2015 05:18:27 UTC

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