search

dperini / nwsapi

Fast CSS Selectors API Engine
MIT License
103 stars 35 forks source link

h1 + h2 appears to break #114

Open Fil opened 3 months ago

Fil commented 3 months ago

This selector errors after c104f8cdf49d38699a9570d327446689251efe11; it's working with the parent 34c2154acbaf0e2b21accecbb1bf9c71fc5ee229

Dom.select("h1 + h2")

dperini commented 3 months ago

@Fil ... yes the last commit brings a regression within the changes made to improve and further isolate HTML / XML / XHTML languages inside "nwsapi" so next cut release will not contain this last namespaces related commit. Hope no more regression will surface. I understand developers need a "new stable nwsapi" release library and I will now focus on making that happen. Thank you for the help.

miguel-leon commented 3 months ago

Just in case it helps, here's a more intricate case. It's a different error, but I was getting 'not valid selector' before, so I guess it's related.

selector: ':is(.a, .b:not(.c:is(.d), .e), .f), .g'

stacktrace:

SyntaxError: unknown pseudo-class selector ':not(.c:is(.d'
    at emit (C:\Users\taliz\OneDrive\Escritorio\dev\puristic\node_modules\.pnpm\nwsapi@2.2.10\node_modules\nwsapi\src\nwsapi.js:576:17)
    at compileSelector (C:\Users\taliz\OneDrive\Escritorio\dev\puristic\node_modules\.pnpm\nwsapi@2.2.10\node_modules\nwsapi\src\nwsapi.js:1300:17)
    at compile (C:\Users\taliz\OneDrive\Escritorio\dev\puristic\node_modules\.pnpm\nwsapi@2.2.10\node_modules\nwsapi\src\nwsapi.js:766:16)
    at match_collect (C:\Users\taliz\OneDrive\Escritorio\dev\puristic\node_modules\.pnpm\nwsapi@2.2.10\node_modules\nwsapi\src\nwsapi.js:1371:16)
    at Object._matches [as match] (C:\Users\taliz\OneDrive\Escritorio\dev\puristic\node_modules\.pnpm\nwsapi@2.2.10\node_modules\nwsapi\src\nwsapi.js:1426:35)
    at Array.Resolver (eval at compile (C:\Users\taliz\OneDrive\Escritorio\dev\puristic\node_modules\.pnpm\nwsapi@2.2.10\node_modules\nwsapi\src\nwsapi.js:781:17), <anonymous>:3:104)
    at collect (C:\Users\taliz\OneDrive\Escritorio\dev\puristic\node_modules\.pnpm\nwsapi@2.2.10\node_modules\nwsapi\src\nwsapi.js:1578:21)
    at Object._querySelectorAll [as select] (C:\Users\taliz\OneDrive\Escritorio\dev\puristic\node_modules\.pnpm\nwsapi@2.2.10\node_modules\nwsapi\src\nwsapi.js:1533:36)
dperini commented 3 months ago

@miguel-leon yes it is related ... I almost fixed the spill. A mix up of wrong RegExps changes brought me here. The ability of parsing nested selectors compounds was not the objective of "nwsapi", not now. It will be available soon I hope, but not yet, not for a bug free release bug free at least, but it has become the time to close this circle and push a working release.

The problem is known ... in this moment compiler generated code is not always up to the complexity of the task in term of nesting, levels deep. It has worked in "nwmatcher" why should it fail in "nwsapi" ? Well ... first because I missed up a particular parameter where the errors should be also parsed/evaluated by looping through alle the sub-nested exceptions.

I am working to push a commit for this failure only and see how this affects remaining problems.

miguel-leon commented 3 months ago

Oh. If the problem is RegExps, it's annoying because they lack recursion. So also, in case it helps, you could decide and document that nesting is supported only up to a certain depth, and then repeat the expression inside of itself a couple of times to circumvent the recursion problem without using another mechanism outside the realm of regexps to loop through sub-nested cases.

For example for parenthesis:

✌️