Re: [selectors] Child-indexed pseudo-classes and the root element

On Wed, Sep 6, 2017 at 12:48 AM, Emilio Cobos Álvarez <> wrote:
> There was quite a bit of discussion already, see:
> Note that the L3 definition was in terms of parent _elements_, and that
> didn't play very well with shadow DOM. See also the blink-dev discussion:

Yup, this is why we changed it. It was (a) slightly weird that the
root element couldn't match the old definition, and (b) prevented
people from matching elements based on sibling-count that were
top-level in a shadow tree (because their parent node is a ShadowRoot,
which isn't an element, and thus they didn't qualify for :nth-child()
based on the old definition.  The first reason isn't enough to justify
the change, but the second is much more annoying of a restriction, and
was worth making the definition change (even tho it did have a
theoretical compat impact).

> On 09/06/2017 06:51 AM, Daniel Tan wrote:
>> I noticed that :root:nth-child(n) now matches in Chrome and Firefox. It
>> does not match in Safari, IE or Edge, as I would expect. It seems that
>> this was changed in selectors-4, which says
>>> Note: Selectors 3 described these selectors as selecting elements
>>> based on their index in the child list of their parents. (This
>>> description survives in the name of this very section, and the names
>>> of several of the pseudo-classes.) As there was no reason to exclude
>>> them from matching elements without parents, or with non-element
>>> parents, they have been rephrased to refer to an element’s relative
>>> index amongst its siblings.
>> The definition of "inclusive siblings" points to the DOM spec, which
>> requires that an element have a non-null parent in order to be
>> considered a sibling:
>>> An inclusive sibling is an object or one of its siblings.
> Well, this definition seems like it would match "an object" itself,
> regardless of the parent node required to be a "sibling", so I don't
> think there's any inconsistency here.
> Regardless of that, the root element's parent node is non-null anyway
> (the parent node is the document node). This boils down again to parent
> element vs. parent node.

Yup, Emilio's got it here. DOM's definition talks about nodes,
including the document node, which is the parent of the root element;
thus its (parent-based) definition of siblings works just fine for


Received on Wednesday, 6 September 2017 17:27:24 UTC