Everyone is mad at the chrome person, but honestly, all they are saying is they don't want the feature bloat of extended support for a super complex standard, that isn't very popular despite existing for 21 years and involves a library they want to deprecate.
Seems like a very reasonable no to me. You don't get good software by saying yes to every feature idea.
If the "no" argument here was what you are saying, that they don't want the feature bloat of XPath, then that would be reasonable. But they are actually arguing that they don't want the feature bloat of XML capability, and XPath doesn't need to have any dependency on XML capability.
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.
> XPath doesn't need to have any dependency on XML capability.
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.
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.
> The XML parts of our pipeline are in maintenance mode and we would love to eventually deprecate and remove them, or ...
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.
Wasn't the whole point of WHATG to not focus on the browser / specific implementations, but on the standards? I mean it was a ploy to dethrone IE. Just because IE has been dethroned, doesn't mean the purpose of the group should stagnate. I think at this point they feel justified because they defunded Mozilla. The FEDS absolutely need to break up Google.
W3C focused on design by committee, de jure standards. WHATWG focuses on standardizing de facto standards. W3C’s HTML effort failed and now its HTML5 spec redirects to WHATWG’s HTML5 spec. Maybe I misunderstood your comment, but sounds like you got it backwards.
On the contrary, i think the point of whatwg was to focus on reality and make descriptive standards instead of making prescriptive standards like the w3c that nobody implemented.
Pushing xpath (or anything else) despite vendors not wanting it is a step in the opposite direction.
> Conversely, what is the point of a standard that just documents what 2 out of 3 multi-billion companies want to do anyway?
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.
Seems like a very reasonable no to me. You don't get good software by saying yes to every feature idea.