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

On Wed, Jul 15, 2015 at 12:00 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
> On 7/15/15 2:47 PM, Tab Atkins Jr. wrote:
>> 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.
>
> Sounds good.

https://github.com/whatwg/dom/issues/55

>> (But seriously, what are people misinterpreting this as? Do they think
>> :first-child shouldn't match an element without a parent?
>
> Yes, exactly.  Or more interesting, :nth-child(1).

Well, those are defined to be exactly the same.

>> Switching away from the "parent/child" language was *explicitly* meant to
>> avoid
>> that sort of misinterpretation!)
>
>
> Yeah, but using "sibling" in a meaning that's different from the normal
> "child of the same parent" meaning is not much better.

It... is the same meaning?  There are no other elements that are
children of the same parent, so it's the sole sibling in its inclusive
siblings.  This is just an issue with people being uncomfortable with
degenerate cases, which we've run into in the past, and I'm always
happy to clarify those.

> Of course the actual names of the selectors don't help either.  Since they
> insist on including the world "child", a spec reader needs a very clear
> indication that they don't _actually_ mean "child" when they say "child".
> Leaving things underdefined causes people to assume the reasonable thing:
> that "child" means "child".  We can't change the selector names, so we have
> to define things very explicitly...

At Ms2ger's request, I added a note about the change from Selectors 3
a day or two ago, at <http://dev.w3.org/csswg/selectors/#child-index>.

~TJ

Received on Wednesday, 15 July 2015 20:12:53 UTC