Add support for relative selector lists #75
Conversation
✅ Deploy Preview for parsel ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
|
Hi there, sorry this took so long! In the spirit of permissiveness, I wonder if it may be worth it to just parse all relative complex selectors. What do you think? |
|
I am so sorry, I only just now saw this comment (gotta tune my GH notifications I guess for being too noisy). Do you mean just to always parse a selector as possibly relative? Yeah I think that's reasonable. Not all pseudos take relative selector lists but that could very well be expanded in the future so leaving it up to the person using parsel to validate that seems reasonable. I'll make some time this week to finalize this PR. |
|
Yes, exactly. |
thecrypticace
force-pushed
the
relative-selector-lists
branch
from
48b5d68
to
f359c31
Compare
|
Sorry — "this week" turned into a little over 2 weeks. I made that change. The PR is a good bit simpler now because of it as well! |
|
Looks great, thank you! |
Fixes #74
This PR adds support for relative selectors used in
:haswhile making the addition of other relative selector pseudo-classes in the future fairly simple.I added a new type
Relativefor this but I'm not sure whether or not this is the right design. The CSS spec states that, because:has()takes a relative selector list, the arguments of:has()are actually complex selectors. However, it seems a little odd to me to treat theleftside of a complex selector asnull(but that could be an alternate design), especially since the text talks about complex selectors being compound selectors separated by combinators. So the "first" compound selector would be nothing in the relative case — somehow feels wrong from the definition.Thoughts?