You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Consider specifying document.evaluate and document.createNSResolver #67
These are currently left to DOM 3 XPath. However, that spec is (a) very old, and thus wrong in a lot of ways; (b) not very large. It could maybe be subsumed and thus give implementations an actual non-crazy reference.
More modern numbers seem to be ~2.3%, ~0.3%, ~0.1%, all vastly higher than four years ago. (Interestingly, createExpression seems to have gone up from ~0.01% to ~0.1% over the past few months very suddenly; some major site now using it?)
That said, to try and write up some to-do list:
Try and get consensus on what the WebIDL should look like (WebKit has contextNode optional, defaulting to document; Blink changed this to match Gecko a while back because the contextNode default was totally non-obvious and undocumented)
Define the DOM -> XPath data model (note this includes several intentional violations of the XPath data model, as the wiki page notes)
Define what each WebIDL operation/attribute does
Integrate the HTML DOM special case into the DOM spec from HTML
The query is matched against the DOM, and therefore contrary to the XPath 1.0 data model the root element has a parent (the Document) and text nodes can be adjacent to one another. [wilful violation]
assuming the cost of parsing, and validating, the XPath query would've been removed from the mutation dance/equation, but I've discovered only recently XPathEvaluator and createExpression, and I'm sure if other developers knew about it, its usage would be closer to the document.evaluate one, which is also now at 2.x%.
If the direction is to nuke XPathEvaluator though, I rather would like to know it before landing such refactoring, thanks.
I'm not quite sure what the deal is with these two feature values; it's best I post this before I look too far down that rabbit hole or I might forget entirely ...
Note that this needs to add a conversion mode for not processing namespaces so that when namespaces are enabled it will correctly map XHTML documents and when disabled it will correctly map HTML documents. -- The exact mechanism for this (likely an additional processing option) has not been agreed yet.
It attempts to deal with the various willful violations of the XPath/XML data model in a way that it can handle the different flavours of (X)HTML in the corresponding fn:parse-html function. This includes things like the non-conforming handling of template elements.
Note existing behaviour in browsers cannot be described by the DOM -> XDM conversion alone.
For example, matching //FooBar will match a (http://www.w3.org/1999/xhtml, foobar) element, but it won't match a (http://www.w3.org/1999/xhtml, FooBar) element.
Activity
annevk commentedon Sep 3, 2015
See https://wiki.whatwg.org/wiki/DOM_XPath.
zcorpan commentedon Feb 24, 2016
Also see https://blogs.windows.com/msedgedev/2015/03/19/improving-interoperability-with-dom-l3-xpath/
gsnedders commentedon May 29, 2019
More modern numbers seem to be ~2.3%, ~0.3%, ~0.1%, all vastly higher than four years ago. (Interestingly,
createExpressionseems to have gone up from ~0.01% to ~0.1% over the past few months very suddenly; some major site now using it?)That said, to try and write up some to-do list:
contextNodeoptional, defaulting todocument; Blink changed this to match Gecko a while back because thecontextNodedefault was totally non-obvious and undocumented)foolip commentedon May 29, 2019
I made #763 today. Didn't know about this issue, but I'll link it.
foolip commentedon Aug 28, 2019
@gsnedders in #763 (comment):
Add the DOM XPath interfaces from the WHATWG wiki
foolip commentedon Aug 30, 2019
I've updated https://wiki.whatwg.org/wiki/DOM_XPath to point at https://dom.spec.whatwg.org/#xpath for the Web IDL definitions.
WebReflection commentedon Oct 13, 2020
FWIW, I've just refactored some code from this:
to this:
assuming the cost of parsing, and validating, the XPath query would've been removed from the mutation dance/equation, but I've discovered only recently
XPathEvaluatorandcreateExpression, and I'm sure if other developers knew about it, its usage would be closer to thedocument.evaluateone, which is also now at 2.x%.If the direction is to nuke
XPathEvaluatorthough, I rather would like to know it before landing such refactoring, thanks.SamB commentedon Feb 27, 2022
Hmm,
createExpressionlooks to have hit 0.3% recently: V8XPathEvaluator_CreateExpression_Method.DocumentXPathCreateExpression is also up to about 0.025%.
I'm not quite sure what the deal is with these two feature values; it's best I post this before I look too far down that rabbit hole or I might forget entirely ...
rhdunn commentedon Jul 17, 2023
An attempt at a DOM to XPath XDM has been made at https://qt4cg.org/specifications/xpath-functions-40/Overview.html#html. Feedback is welcome.
Note that this needs to add a conversion mode for not processing namespaces so that when namespaces are enabled it will correctly map XHTML documents and when disabled it will correctly map HTML documents. -- The exact mechanism for this (likely an additional processing option) has not been agreed yet.
It attempts to deal with the various willful violations of the XPath/XML data model in a way that it can handle the different flavours of (X)HTML in the corresponding
fn:parse-htmlfunction. This includes things like the non-conforming handling of template elements.gsnedders commentedon Oct 24, 2023
Note existing behaviour in browsers cannot be described by the DOM -> XDM conversion alone.
For example, matching
//FooBarwill match a(http://www.w3.org/1999/xhtml, foobar)element, but it won't match a(http://www.w3.org/1999/xhtml, FooBar)element.rhdunn commentedon Oct 24, 2023
See qt4cg/qtspecs#296 for making the XPath matching side of this work, given a HTML document mapped to the XDM.
gsnedders commentedon Oct 24, 2023
It might be worth moving at least the XPath section of https://html.spec.whatwg.org/multipage/infrastructure.html#interactions-with-xpath-and-xslt into DOM, because it's really about matching XPath against HTML Documents, which we nowadays define in DOM.