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

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

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Tue, 13 Jan 2015 14:36:04 -0800
Message-ID: <CAAWBYDDRV-eHVGNbQwH7tw=AXK4EYCKU_rUAXwyd0jT6Qx2kYw@mail.gmail.com>
To: Benjamin Poulain <benjamin@webkit.org>
Cc: www-style list <www-style@w3.org>
On Tue, Jan 13, 2015 at 2:04 PM, Benjamin Poulain <benjamin@webkit.org> wrote:
> This is a very well written proposal.
> The main argument I have against this is performance. Any time a :n-children
> is evaluated, we would have to really go over all the children to find the
> elements and count them.
> The pseudo class :nth-child() does not have this problem. The tree is
> visited in-order depth-first. When evaluating a :nth-child(), the previous
> nodes have been evaluated and we know what the state is.
> The performance of :n-children would be more like :nth-last-child(). It is
> possible to cache the result, but the initial evaluation requires you to
> evaluate lots of node.
> Style invalidation is gonna be inefficient, but not worse than
> :nth-last-child().
> Given that there is already :nth-last-child() support in the spec, I am okay
> with having :n-children.

:n-siblings() is already possible and equivalent to :nth-last-child()
(see <https://grack.com/blog/2015/01/09/abusing-css3-selectors/>, for
example, which Matt already pointed at in the OP).  The new thing with
:n-children is letting a parent look at its child count.  Given :empty
and :blank, I agree that this shouldn't be bad.

Received on Tuesday, 13 January 2015 22:36:52 UTC

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