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

Re: [selectors] Need to clearly define matching for :first-child, :nth-*, etc

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Wed, 15 Jul 2015 11:47:46 -0700
Message-ID: <CAAWBYDA52Wg1nr-GZZ0CX77kxPuX5=2TqujxR-FdCNCJzT863w@mail.gmail.com>
To: Boris Zbarsky <bzbarsky@mit.edu>
Cc: www-style list <www-style@w3.org>
On Wed, Jul 15, 2015 at 11:40 AM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
> On 7/15/15 2:28 PM, Tab Atkins Jr. wrote:
>> There's no explicit definition because I didn't realize there could be
>> any possible confusion.
> <shrug>.  That's the usual thing that happens when there is no explicit
> definition.
>> We already have the + combinator, which relies
>> on the exact same concept.
> Well, we should fix that.
>> How are people interpreting these
>> differently, and what needs clarification, exactly?
> The spec uses the concept of "siblings" is typically defined as "children of
> the same parent", which is nonsensical when there is no parent.  So we
> should probably explicitly define that when there is no parent the set of
> "siblings" consists of just the element itself, or something (and make all
> mentions of "siblings" link to this definition).
> Note that treating "siblings" as the empty set (due to not having a parent)
> would, for example, cause :nth-child(1) to not match, and I assume the
> intent of the spec is that it match an element with no parent, yes?  So you
> really do want "siblings" to be defined as the set containing just the
> element being matched if it has no parent.

I just pinged Anne to define "sibling list" in DOM, to be the object
and all of its siblings in tree order.  Then I'll switch Selectors to
using that term and linkify it.

(But seriously, what are people misinterpreting this as? Do they think
:first-child shouldn't match an element without a parent? Switching
away from the "parent/child" language was *explicitly* meant to avoid
that sort of misinterpretation!)

Received on Wednesday, 15 July 2015 18:48:33 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:52:18 UTC