Live data from Hacker News

Chrome unlikely to support XPath 3.1

github.com

21–30 of 114 posts

Re: Chrome unlikely to support XPath 3.1

#21
post #9

This is an editorialized link name and the target comment isn't even obviously wrong or anything. Let the awfully outdated XML tooling die. Context: This was named "Chrome holding the web back: an example", I expect moderation will change this at some point to something like "Chrome unlikely to support XPath 3.1" which is considerably less incendiary and something few people here care about.

More like: "Chrome unlikely to follow WHATWG XPath 2.0+ support spec if ever merged"

Or "Chrome devs being against XPath 2+ spec because of internal maintenance problems"

Re: Chrome unlikely to support XPath 3.1

#22
post #19

This discussion is a decade late. The direction was set when HTML5 was chosen instead of XHTML 2.0 and I don't think any important group changed their mind since. Committee-made standards are impotent without popular implementations.

HTML5 does have a standard XML serialization, which subsumes the "XHTML 2.0" use cases (such as extensibility via other XML namespaces).

Re: Chrome unlikely to support XPath 3.1

#23

Earlier quoted context omitted.

The MathML support in Firefox and Safari are barely usable. Even if my target audience all browsed on Firefox and Safari, I'd avoid MathML.

Don’t let perfect be the enemy of good. Use MathML, put up noticea that your content only works in Safari and Firefox. These are all attacks against Google. FIGHT!

Have you misunderstood me? MathML does not work well even in Safari and Firefox, and that is why they are avoided.

Re: Chrome unlikely to support XPath 3.1

#24
post #19

This discussion is a decade late. The direction was set when HTML5 was chosen instead of XHTML 2.0 and I don't think any important group changed their mind since. Committee-made standards are impotent without popular implementations.

HTML5 does have a standard XML serialization, which subsumes the "XHTML 2.0" use cases (such as extensibility via other XML namespaces).

Sure and what can you use it for in the browser? SVG at most. XInclude? I don't think so. XHTML 2.0 was about much more than this.

Re: Chrome unlikely to support XPath 3.1

#25
For those replying with "XML is bad and therefore Google is right", reading the whole thread presents a more complex picture. Quoting from various comments in that thread,

> this is a proposal for querying the HTML DOM with XPath, not XML.

> Per https://www.chromestatus.com/metrics/feature/popularity it does seem that about 1-2% of page views end up using XPath

One could argue whether a feature that has existed for over a decade and is only used by 1-2% of page views is worth improving, but that is not the argument that domenic is making here.

> Chrome is not interested in this. The XML parts of our pipeline are in maintenance mode...

> By "XML parts of our pipeline" I mean "everything implemented using libxml and libxslt".

His comment is that in the Chrome codebase, the XPath implementation is within some XML libraries, which are in maintenance mode. This may or may not be true for other browsers. It's interesting that these refer only to the implementation cost to Google, and does not make any reference to costs or benefits to other users of the web platform, which are discussed by other comments.

Overall, while there seem to be valid arguments both for and against the proposal, arguments for are being presented publicly in that thread while those against are being discussed elsewhere (perhaps at Google?), with only final, unchallengeable decisions being posted here. Domenic is fairly explicit in his refusal to engage in a discussion.

> As such, I won't be participating in this thread further. I think I've made our position clear.

Irrespective of whether you agree with the proposal itself, to an outsider like myself it looks like the process of discussion does not exist at WhatWG anymore, and that Google basically dictates terms.

Edit: moved a paragraph for clarity

Re: Chrome unlikely to support XPath 3.1

#28
post #16

I feel like XPath queries have been gaining more widespread usage over the last decade by developers at the css/javascript level, so perhaps it makes sense to improve the power of it.

There is no need to improve the power of xpath in browsers, they already have a scripting langage, they don’t need a second one.

What would be useful however is improving the precision, xpath 1.0 had a pretty restricted set of functions which hampers filtering, you either need to bring too much back to JS or the selector becomes overly complex with painful cross-language escaping, especially when dealing with HTML trees (token lists are really painful to deal with just 1.0’s functions set).

Making exslt & applicable later functions available would be a huge boon without needing to change the langage itself.

Re: Chrome unlikely to support XPath 3.1

#30

As of the last couple years, Chrome is the web. The writing has been on the wall since at least Widevine. The browser wars are over, and I don't see any scrappy startup crossing the moat of complexity GOOG has built around "modern" browsers. Especially when combined with their stranglehold of the standards committees. We need to find a new attack vector.

They’ll do it to themselves. One thing I see regularly is Chrome’s web caching being so aggressive it is driving front-end developers to start using FF for dev. We simply need to stand back and let time take its course.

Does Chrome no longer have the option to disable cache while dev tools is open?
Post reply on HN