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

On Wed, Sep 6, 2017 at 12:48 AM, Emilio Cobos Álvarez <emilio@crisal.io> wrote:
> There was quite a bit of discussion already, see:
>
>   https://github.com/w3c/csswg-drafts/issues/695
>
> 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:
>
> https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/RgdSWmv0s4g

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
CSS.

~TJ

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