@ -664,4 +664,4 @@ The primary aim of this library is accuracy when possible and/or practical. Howe
16. There will only be support for XPath 1.0 in this implementation because that is all PHP DOM's XPath supports. Writing a custom XPath parser to support XPath 3 would be a huge undertaking and is outside of the scope of this library.
17. The DOM XPath specification itself is an ill-conceived API that is entirely impractical to use, and as a result in browser land isn't used much at all. Version 1.x of this library attempted to implement much of the XPath extensions to maintain conformity with the specification, but in practice using it compared to PHP DOM's implementation was a horrible experience. Therefore, all XPath-related classes and traits have been removed from the library except for `XPathException`. Evaluation of XPath expressions is now done entirely through `Document::evaluate`.
18. `Document::evaluate` as specified (as part of `XPathEvaluatorBase`) is as ill-conceived as the rest of the DOM XPath specification, so while this library keeps it around it behaves entirely like `\DOMXPath::evaluate`. Namespaces must be manually defined using `Document::registerXPathNamespaces`. It's just a much simpler and less bullshit way to use XPath, and the PHP authors were right in deviating. As with `\DOMXPath`, `Document::evaluate` will return an integer, float, or a `NodeList` depending on what the expression would return instead of `XPathResult` as defined in the specification.
19. Unlike node names and prefixes this implementation will NOT coerce non-ASCII characters. As of this writing (December 2023) no browser supports unicode characters in XPath expression selectors, but the [XPath specification][m] states the expression should be a Unicode string and that node names used in selectors should follow the same conventions as XML. On the surface it seems it's as easy as coercing any non-ASCII characters in an expression, but internally attribute values aren't coerced. To accomplish coercion of selectors a superficial tokenization of the expression would be necessary to isolate selectors and string comparison on `name()`. We might consider doing this in the future, but it's not a high priority.
19. Unlike node names and prefixes this implementation will NOT coerce non-ASCII characters in XPath expressions. As of this writing (December 2023) no browser supports unicode characters in XPath expression selectors, but the [XPath specification][m] states the expression should be a Unicode string and that node names used in selectors should follow the same conventions as XML. On the surface it seems it's as easy as coercing any non-ASCII characters in an expression, but internally attribute values aren't coerced. To accomplish coercion of selectors a superficial tokenization of the expression would be necessary to isolate selectors and string comparison on `name()`. We might consider doing this in the future, but it's not a high priority as this is an edge case and would rarely turn up in real world usage.
