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

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.

~TJ

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