Seems like a very reasonable no to me. You don't get good software by saying yes to every feature idea.
So they haven't really addressed the request itself, and they are being extremely dismissive about any suggestion that they might be interpreting things in an unfair light. I think that is why people are frustrated.
I don't even want this feature and I am frustrated just by reading the linked thread.
That's an important point, programmatically applying XPath to HTML can be super convenient, while basic CSS selectors are superior, XPath is way better for non-trivial selections, and because CSS was designed in a rather ad-hoc manner it "scales" very badly as new features get grafted on.
This... is actually subjective.
XML is a relatively simple standard; the complexity is emergent rather than inherent to its definition.
Take for example an oft-cited security issue with xml: xxe. This results from xml entity referencing supporting filesystem access. But there's nothing inherently "complex" about that from a language/syntax definition perspective, filesystem access is just an inherent danger regardless of complexity.
That's not to say XML is as simple as it could be (everything has its caveats and edge-cases: null-default attribute namespaces is a weird one that comes to mind), but in general "strict" and limited language syntaxes tend to be much less complex than lax syntaxes: e.g. HTML or YAML, which have endless depths of gotchas with ambiguous or unintuitive parsing behaviours.
> that isn't very popular
Ha!
It sounds scary. I hope he meant core changes, not API
> ... or at least replace them with something that generates less security bugs. Increasing the capabilities of XML in the browser runs counter to that goal.
> By "XML parts of our pipeline" I mean "everything implemented using libxml and libxslt".
I have one example. Have you known HTML parser is faster than XML [1]? Yes, awfully bloated HTML parser [2] is faster.
All they are saying is that Chrome team is hypocritical to the extreme. See https://news.ycombinator.com/item?id=24766554
Pushing xpath (or anything else) despite vendors not wanting it is a step in the opposite direction.
Documenting the commonalities between implementations in order to gain interopability, is precisely the point of a standard.
Because it provides a fixed target that can be targeted with confidence by both developers and also the makers of any alternative browser (of which about 4 are still listed in global browser market share statistics).
Those who complain that right now the browser market is dominated by a couple of players seem to be entirely oblivious to history.