Use nth-of-type instead of nth-child when appropriated

[antonmedv]

No description provided.

[antonmedv]

After thinking a little bit more, nth-child as good as nth-of-type

[kfrederix]

@antonmedv I'm curious what are your thoughts about this now?
Personally, I would prefer nth-of-type just because it's so much more intuitive (for humans reading the selector) and also it might be a tad more robust in some cases.

I wouldn't mind creating a PR, if you would be open to that?

[antonmedv]

Probably. Is nth-of-type available everywhere?

[kfrederix]

Browser support for this looks good to me at this point, yes.

[antonmedv]

Sounds good.

[eoghanmurray]

I'm wondering why #some_id div:nth-child(2) a is preferred over #some_id :nth-child(2) a in the existing code? That div appears to be redundant in the examples I've checked.

:nth-of-type does require the tagName as part of the selector

[eoghanmurray]

One idea (for the readability the OP mentioned) is that the lib could favour div:nth-of-type(2) for cases where there are mixed siblings and a plain :nth-child for cases where siblings are all of the same type.

[antonmedv]

It’s an optimisation problem.
if we can check all selectors, we can select the best. But it’s too slow, so Finder uses heuristics to “guess” best selector. Finder uses concept of penalties.

[Snooz82]

I would second that.

input:nth-of-type(1) shouldnbe more stable and less affected by other siblings in the parent that are not of type input. So if some div or span changes, that selector could still work.