Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Retrieve :nth-child nodes by identity #22

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

other-mickk
Copy link

Ensure that the :nth-child/:nth-of-type selectors find siblings
through the Core.:(===) operator. This is the same behaviour as
nextSibling and prevSibling.

Closes #21.


Passes tests locally.

I would appreciate eyeballs on this, I got the idea for this fix by noticing what nextSibling and prevSibling do:

i=findall(x->x===n, p.children)

As I understand it, because Gumbo.jl’s data takes the form of mutable structs using === is reliable only if nodes are not copied. I don’t know enough about the ecosystem to figure out if that makes this PR sensible.

Ensure that the `:nth-child`/`:nth-of-type` selectors find siblings
through the `Core.:(===)` operator. This is the same behaviour as
`nextSibling` and `prevSibling`.

Closes Algocircle#21.
@aviks
Copy link
Collaborator

aviks commented Jan 15, 2021

Hmm... I think it's reasonably safe to assume that nodes are not copied within a single Cascadia run .. we just go with what Gumbo.parse returns -- but I would like to dig into why == does not work here. I don't understand that yet.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

:nth-child seemingly selects identical siblings
2 participants