Comments (8)
The commit you pushed while I was creating this issue solved the failures related to namespaces 🎉
from nwsapi.
@Zirro correct, there was a specific commit for the namespace issue... I hope that commit finally solves both the remaining SVG and more generally the XML issues with mixed-content.
I am also ready to commit the changes needed for the "duplicate IDs", just need a bit more time to do some code lifting and cleanup.
The last commit I did is also a performance improvement for comma separated groups of selectors, they where fast already but now they should be even faster and the code is smaller.
from nwsapi.
I've just tested beta2 with jsdom, and unfortunately the SVG tests are still an issue. I don't know if it helps, but some quick debugging shows that it ends up running this code at one point where e.nodeName is compared against uppercase "SVG":
(function(s
/*``*/) {
"use strict";return function Resolver(c,f,x){var r=[],e,n,o,j=-1,k=-1;c=c(true);main:while(e=c[++k]){if((e.nodeName=="SVG")){r[++j]=c[k];if(f(c[k])){break main;}continue main;}}return r; }
})
I'll have more time for debugging in a few days.
from nwsapi.
@Zirro thank you for noticing the issue, clearly every strangeness you notice and report might help.
I believe with the latest commits I did today the remaining issues should have been resolved.
I was forced to accept a minor performance loss to try a new path aimed at resolving the mixed-namespace problem. I hope this solves the SVG and similar issues with tag names upper/lower case.
from nwsapi.
Yes - the latest commits have finally solved the SVG problem, as well as the one with duplicate IDs! 🎉
Unfortunately, there are also some new failures. 924d5b4 appears to be the cause for most of them, as several more tests pass if I revert it or set FASTCOMMA
to false. Can you explain how this function works and when it is needed?
With FASTCOMMA set to false, there's still a failure where context
becomes null
on line 314, since context
is set to firstElementChild
even for a body (<body>Body text content</body>
) that only has a text node rather than an element.
I'll need some time to figure out if the other issues are in jsdom or nwsapi, but thanks for resolving everything related to mixed namespaces.
from nwsapi.
@Zirro thank you for the feedback, really appreciated (and needed).
I normally test everything with standard browsers first, then when I publish a new release to npm I test with jsdom by simply replacing current "nwmatcher-noqsa.js" with the content of the new "nwsapi". I understand this is a bit of a skew procedure but as soon as I have more spare time I am going to dig myself a bit more into yarn
documentation and learn more about it. I believe that is the current tool used for testing.
Can you share more info about how you do testing of WPT selectors, I have tried yarn test-wpt
but that is not what I need, I need something that goes into more detailed test of only "ParentNode-querySelector-All-xht.xht" (1859 test) or the complete "dom/nodes/" path where this file resides.
I can do it easily from a browser but I will prefer doing the same from terminal running "node <file.js>" that will allow me to test and benchmark without having to run the complete test suite each time.
For the "" problem you noticed I don't know what to say now, but I will check that out if you send me the test or the link were I can see that problem. As a first guess the problem might be in a different place because the "firstElementChild" property should not return a text node in any circumstance that I am aware of. The line you pointed out (L314) is needed by the engine to handle elements in a DocumentFragment (nodeType 11) to allow using native gEBTN method to collect nodes from a fragment since DocumentFragment nodes do not have those methods available in their prototype.
I am writing down details of the process bound to the "FASTCOMMA" flag as you asked in another message to keep things apart.
from nwsapi.
@Zirro about the comma group selectors and the "FASTCOMMA" configuration flag ...
The basic is that the "collect()" method (L1442-1480), in the main "else" block, is caching the needed HTMLCollection lists (which are live lists) needed in resolution of comma groups selectors.
The objective is to resolve comma group selectors in a faster way but at the same time ensure that those initial HTMLCollection lists have not been changed since their last caching time to ensure error free select()
operation. The checking process is a method named "validate()" and is invoked every time a query of that type is served/resolved.
So, as an example, for the "div.notes, span.detail" selector I am caching the "div" HTMLCollection and the "span" HTMLCollection" and then build the usual resolver function that only checks these elements for their corresponding class names without checking the tag names again.
Since I do this in "document order" there is no need to go through an extra reordering pass nor to check the resulting array for uniqueness, which further improves the process performances.
A second example, to better explain a different case where this is important. For a selector like "h1, h2, h3, h4, h5, h6", used to automate TOC building for HTML documents, it will be even faster because the six HTMLCollection lists alone will makeup the result with only one pass to have them returned in "document order". Again no need to perform extra reorder/unique passes.
Not sure the explanation was clear enough, you will have to bear with my English skills.
For any other question or doubt just ask, I would like to have "nwsapi" ready and integrated asap.
from nwsapi.
Can you share more info about how you do testing of WPT selectors, I have tried yarn test-wpt but that is not what I need, I need something that goes into more detailed test of only "ParentNode-querySelector-All-xht.xht" (1859 test) or the complete "dom/nodes/" path where this file resides.
Absolutely - you can use the --fgrep
flag to run a smaller number of tests. For example:
yarn test-wpt --fgrep "ParentNode-querySelector-All.html"
to run that particular test. (don't worry about the .xht
version - I think that fails in jsdom for unrelated reasons)
yarn test-wpt --fgrep "dom/nodes"
to run all tests in the dom/nodes
directory.
You will also need to change the list of failing tests - to-run.yaml
- so that this line is behind a #
-comment. Otherwise the test is disabled when you run yarn test-wpt
.
As a first guess the problem might be in a different place because the "firstElementChild" property should not return a text node in any circumstance that I am aware of.
Yeah, the problem is not that it returns a text node, but it returns null
when there are no child elements. For example, if you try to use document.body.firstElementChild
on the following document:
<body>No elements here - only text</body>
Thanks for explaining FASTCOMMA
and the validate()
-method! That's an interesting approach with a HTMLCollection-based cache for each element you find in a selector. It makes sense since the classes are more likely to change than the structure of the document. Your explanation was perfectly clear too - no need to worry about your English in this case :-)
It's still strange that it would cause these failures though, but perhaps it has some unintended side-effect in jsdom. I will debug it over the weekend.
from nwsapi.
Related Issues (20)
- Error on parenthesis in attribute value inside pseudo-class arg HOT 1
- Missing support for :has() pseudo-class HOT 5
- TypeError: Cannot read properties of undefined (reading 'toLowerCase') HOT 10
- TypeError: Cannot read properties of null (reading 'parentElement') HOT 4
- Publish a new release HOT 2
- unknown pseudo-class selector ':defined' HOT 1
- Upgrade from nwsapi 2.2.2 to 2.2.3 creates infinite loop HOT 12
- v2.2.3 DOMException [SyntaxError]: '.disabled):not(:disabled)' is not a valid selector HOT 26
- fix: v2.2.3 was broken and v2.2.4 it was not published on npm HOT 3
- Infinite loop fixed but still getting error in selectors HOT 25
- Attribute selector ~= does not handle escaped values correctly
- Concatenated `:not` selector doesn't work since version `2.2.3` HOT 1
- logicalsel Rexexp selects incorrect values since 2.2.3 HOT 5
- Not a valid selector HOT 13
- Upgrade from nwsapi 2.2.5 to 2.2.6 started issue with JEST + RTL test cases HOT 26
- SyntaxError: Illegal break statement HOT 3
- SyntaxError when selectors use special characters HOT 5
- :scope in the context of the Document (DOCUMENT_NODE) object does not refer to the root element HOT 2
- `2.2.4 => 2.2.5 === unknown pseudo-class selector ':has(span)'` [VIA jsdom, using pnpm] HOT 5
- :scope can't distinguish a context with no IDs nor classnames
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from nwsapi.