Fix adjacent logical selectors

[KindaOK]

Previously, adjacent logical selectors such as :is(*):is(*) would crash because the regex would incorrectly match *):is(*

Replacing the naive match contents with something that matches balanced parentheses correctly handles these situations.

Resolves #137

[KindaOK]

Per #137, no regressions on the following wpt tests

has basic
has relative
not complex
is where basic
is nested

I don't have the full test setup locally, so that will need to be checked still. Also will need a performance check for tuning depth. A depth of 3 seems pretty good in terms of covering real scenarios, but if it doesn't hurt to go higher, then increasing it to something like 4-5 would be nice.

[KindaOK]

This method also does not work for all logical selectors. Sample failing test cases below. It seems like it's related to commas or number of characters between inner parentheses.

// fails with SyntaxError: unknown pseudo-class selector
:is(:is(*, *), *)
:has(> :is(*), *)
:has(:is(*),*)

This PR will not fix #127

Might be fixable by modifying the regex to allow more characters in between nested parens?

[KindaOK]

Funnily enough, :is(*,:is(*)) works.

[KindaOK]

Oh found it. The problem is that commas are interpreted as different selectors sometimes within the context of logical selectors in the initial parse in match

https://github.com/dperini/nwsapi/blob/master/src/nwsapi.js#L1534

[dperini]

@KindaOK
great help from you on these isssues, I agree that your commit for issue #137 is the best we can have at the moment,maybe it can be improved in the future.
For the weekend I wish to have it tested and do the commits for a new release.
I will start merging your pull request today to have the time to execute all the necessary tests.
Again thank you for your time and for the correct suggestions, I really appreciated your help.

[dperini]

@KindaOK
two posiby related things to watch out that could be adversely affecting current status:

1. the :has( ... ) pseudo-class cannot be nested which is the contrary for other logical selectors
2. the parser should accept mangled selectors, selectors missing a closed quote or double quote or brackets/squares

Just a note for when performing the tests.

[KindaOK]

1. the :has( ... ) pseudo-class cannot be nested which is the contrary for other logical selectors

There's no special behavior in place to prevent this at the moment neither in the current version of nwsapi nor in my branch. I think it's hard but doable with regex using a balanced parentheses matcher. Something like "(?!:has\(([^()]*|" + createBalancedParensMatcher(...) + "):has\(". Obviously not complete since parentheses could be put in attribute string comparisons, but that goes back to just using a parser.

2. the parser should accept mangled selectors, selectors missing a closed quote or double quote or brackets/squares

My PR doesn't support that, but mangled selector support already has been gone for a bit. It looks like e60b058 was the commit that removed it. I don't think it can be easily thoroughly readded without a parser setup. The simple case for missing end parenthesis could be resolved by replacing the end \x29 with (?:\x29|$) I suppose though

[dperini]

@KindaOK
well let's apply the changes for these new pseudo-classes and see what the other developers have to say about these new functionalities, try to improve the parsing and the resolvers and getting their reviews and suggestions.
Thank you for your continuous help and research.

[bmm6o]

Is there a plan for a release that includes this fix? I don't see anything in the wiki about release targets or cadences, but it looks like you've been releasing ~bimonthly recently? For us, this is a blocker for Svelte 5.

[dperini]

@bmm6o
I am sorry if this blocks any other development or project.
However you should avoid depending on edge functionalities like these
or at least have different backup solutions to ensure your project works despite
wrong or faulty nwsapi implementations that were not part of the listed functionalities.

I will do my best to increase the releases frequencies related to the :has() pseudo-class but to be honest
I still do not have this clear nor I have a definitive strategy on how to write the correct resolver that can keep up
with the speed of other resolver. The good thing is that this pseudo-class already reached 90% positive resolution
coverage of the available wpt tests.

Next testing strategy candidate will be using "compareDocumentPosition"
and see if we can reach resolution on more cases an still keep decent speed.

Stay tuned, reviews, suggestions and testing are welcome and appreciated.

[bmm6o]

Sounds good. And it might be helpful if I add some context. The dependency chain for us is Vite/jsdom/nwsapi, and what surfaced the bug is that Svelte 5 seems to generate more complex css selectors than Svelte 4 did. This is on the same codebase, so it's not selectors that we are intentionally building. I expect others from the Svelte community will run into this soon if they haven't already, which is what I meant by "us" - I hope I didn't sound too rude earlier.

We are investigating alternatives, which I think would be to replace jsdom.