Chrome unlikely to support XPath 3.1

https://github.com/whatwg/dom/issues/903#issuecomment-707748069

by norswap • 6 years ago

143 110 6 years ago

github.com

crazypython• 6 years ago

Safari tends to be slow to implement features, but they rarely outright reject implementing a feature.

Google Chrome hasn't implemented MathML yet, even though Firefox and Safari have: https://caniuse.com/mathml

netheril962• 6 years ago

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.

the_other2• 6 years ago

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!

drran• 6 years ago

It looks quite capable:

https://mdn.mozillademos.org/en-US/docs/Mozilla/MathML_Proje...

lern_too_spel• 6 years ago

MathML support in Blink is under active development.

https://bugs.chromium.org/p/chromium/issues/detail?id=6606

chromakode• 6 years ago

Safari has been holding the web back for years on features that make the web competitive with Apple's app ecosystem. I don't believe the distinction of "rejecting" vs being slow has merit.

https://caniuse.com/push-api https://caniuse.com/mediasource

runroader• 6 years ago

Safari vs. iOS Safari is a distinction that needs to be made and people need to keep in mind. Apple's a lot more likely to allow stuff in desktop that it won't even consider for iOS. I mean your own link for media source has it being fully supported since 2014 in desktop Safari.

esprehn• 6 years ago

Apple has refused to implement a large number of features, at least as many as Google. They're usually more quiet about it though unless it's part of marketing related to privacy. All the browsers take strong architecture and ecosystem positions.

samtheprogram• 6 years ago

Actually, they do refuse sometimes, not that I’m against it, but it’s inaccurate to say they don’t.

https://www.zdnet.com/article/apple-declined-to-implement-16...

acqq• 6 years ago

There “due to privacy concerns” could still be a real motivation.

anuila• 6 years ago

I think that’s misleading since Safari’s development is not generally discussed outside the occasional WebKit blog post and the rare Safari developer on Twitter who may or may not rightfully ignore any questions/arguments.

A lot of features are implemented late and incorrectly. I think that the first Safari version that supported PWAs was so broken that many had to manually exclude the browser in their support detection code.

dmitriid3• 6 years ago

Search for rniwa on GitHub, he's one of the core developers, and is active in all discussions (including meeting notes that are often published in GitHub issues).

donatj• 6 years ago

XML is undeniably a huge attack vector with a shrinking user base. I think that’s a very valid argument for not expanding its surface area.

richx4• 6 years ago

Is it an attack vector? Can you elaborate further?

barefootliam6• 6 years ago

No. XML libraries increase the attack _surface_, but XML itself is passive. There was a famous "billion laughs" attack, but JavaScript was also vulnerable to this, as is any language that lets you concatenate strings. The usual fix is a max size on such strings. There are a couple of other potential vulnerabilities, such as the ability to access the content of any URL, including file://etc/group, but again JavaScript has that too.

retrofuturism• 6 years ago

Let’s deprecate old technologies that are currently bundled in web browsers instead of adding to them. Browsers need to go on a diet.

znpy• 6 years ago

browsers are quite fast nowadays.

they appear to be bloated mainly because of two reasons:

1) companies pulling in all sort of un-optimized content and making requests to a huge amount of external services, effectively slowing down the render of pages

2) a lot of developers developing stuff that should really be native code in html+js+css, which doesn't always perform that well and tends to slow down the whole browser. it really suffices one badly-coded app (not using well asynchronicity and/or wasting memory) to make the whole browser appear slow.

cesarb• 6 years ago

No, the browser itself is bloated.

For instance, the RPM for the Firefox I'm using right now is 100 megabytes, and that's an already compressed format. After installing, just one of the components (libxul.so, which has most of the executable code) is over 110 megabytes.

Each new feature will only increase this size even more.

ferdowsi• 6 years ago

The Google team is right. It had a great run, but it's time to let XML die.

netfl02• 6 years ago

Have they proposed an alternative?

nimish2• 6 years ago

HTML and JavaScript. Works for PDF with PDF.js

XML is no longer relevant to the modern web

dclusin• 6 years ago

YAML of course. /s

PretzelFisch• 6 years ago

XML is far from dead ask most enterprise companies. XPath in particulare can be very useful in finding nodes in an HTML tree.

zmix4• 6 years ago

What format do you recommend the Digital Humanities folks should use?

zorked• 6 years ago

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.

augusto-moura• 6 years ago

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"

jeffbee3• 6 years ago

i guess the non-inflammatory title would be “representative of chrome project votes no in one of many working group proposals “?

josephcsible• 6 years ago

They didn't just vote no. They basically said they're not implementing it even if everyone else votes yes.

jeffbee3• 6 years ago

Like my mother used to say: if all of your friends jumped off a bridge, would you jump too?

somehnguy2• 6 years ago

Please just let XML die. Just because it existed doesn't mean it has to exist forever. Will there be pain points in getting rid of it for good? Yeah. But we'll be better off in the long run.

richx4• 6 years ago

I don’t agree. Never touch a running system! I think you have no idea in how many software implementations XML plays an important role. Just because it’s not hot and fancy it does not mean it’s bad.

somehnguy2• 6 years ago

I don't care about hot and fancy. I care that XML is a usability nightmare and makes my eyes bleed. It should not be used in anything new. Part of achieving that goal is to not continue to implement and support it.

vfclists• 6 years ago

No one addresses why the company that dominates web search should have an outsize influence on standards in an area where it has an obvious conflict of interest in adopting technologies that _may_ empower potential competitors, aka ie the rest of the world.

anderspitman• 6 years ago

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.

rangoon6264• 6 years ago

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.

kgwxd• 6 years ago

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

mmm_grayons• 6 years ago

Things looked similar amid the dominance of IE. I think it will probably happen eventually, though you're right that a start-up probably won't do it. The problem that no one pays for web browsers. There are companies building alternative engines for commercial embedding (including one that's parallel and very fast), so it would probably involve one of those being open-sourced.

fouc• 6 years ago

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.

masklinn• 6 years ago

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.

xaduha2• 6 years ago

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.

zozbot234• 6 years ago

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

xaduha2• 6 years ago

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.

aravindet• 6 years ago

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

halflings• 6 years ago

does not make any reference to costs or benefits to other users of the web platform
arguments for are being presented publicly in that thread while those against are being discussed elsewhere (perhaps at Google?)

It's right there at the end of the highlighted comment:

"we would love to [...] replace them with something that generates less security bugs. Increasing the capabilities of XML in the browser runs counter to that goal."

So security bugs in XML seems to be the main issue?

richx4• 6 years ago

I’m wondering which security risks they mean. I don’t see any security risk in XML itself, maybe it’s related to some XPath or XQuery functions?

kerng• 6 years ago

1-2% of page views is pretty massive!

Consider adjusting this number to remove any Google sites that are viewed (to remove Google's own bias/quasi browser monopoly) - and it probably goes up a lot more even.

inimino• 6 years ago

The number of pages with Flash content was also massive for many years. There must be some discipline to remove things from the web platform or it will die.

XPath predates CSS selectors being exposed to JS, and it is absolutely clear that XPath had its best shot to move from niche to mainstream over a decade ago and it didn't happen.

nwellnhof• 6 years ago

His comment is that in the Chrome codebase, the XPath implementation is within some XML libraries, which are in maintenance mode.

Chrome actually has two XPath engines. One is used for querying the HTML DOM with Javascript, the other one in libxml2 is only used for XSLT transformations. (XSLT support is the main reason why Chrome still uses libxml2. If they weren't relying libxslt which in turn requires libxml2, they would probably switch to a better suited XML parser like Expat or write their own.)

dmitriid3• 6 years ago

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.
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.

A few months back Chrome shipped Constructible Stylesheets. The proposed specification was strictly opposed by other browser vendors, with Safari stating that they will not ever consider implementing them in the current state [1].

Chrome not only shipped it enabled by default, but refused to bring it back under a flag because "is used on about ~.8% of page loads in Chrome now" [1] (safe to assume, all of them are Google users and users of Google-developed libraries).

It's the most recent example (also backed up by numbers provided by Google themselves). I won't even mention the plethora of standards that other browser vendors consider harmful, but are enabled by default in Google.

So yes, Google is only concerned by the cost to Chrome, never by the costs or benefits to other users of the web platform.

it looks like the process of discussion does not exist at WhatWG anymore, and that Google basically dictates terms.

That is true. The standards process (both w3c/whatwg and tc39) is hijacked by the same 3-4 people from Google, and decisions are rammed through irregardless of anyone.

[1] https://github.com/WICG/construct-stylesheets/issues/45#issu...

[2] https://github.com/WICG/construct-stylesheets/issues/45#issu...

ocdtrekkie• 6 years ago

I am not sure we can fix the web until other browsers actively treat Chrome developers as a hostile entity. Firefox and Edge teams have both been repeatedly screwed by the assumption their counterparts at Google were acting in good faith.

namedgraph5• 6 years ago

They are what Joel Spolsky called "architecture astronauts".

londons_explore• 6 years ago

If only a tiny proportion of page views use XPath, it would seem it isn't performance critical.

If that's the case, rewrite the whole lot into JavaScript, run it in the browser sandbox, and rip out the libxml that has security concerns. Then invite pull requests to add new versions of whatwg things.

As soon as a browser API is written in JavaScript and only using other public API's, it becomes a near zero maintenance burden.

chrismorgan• 6 years ago

Discussion 19 days ago: https://news.ycombinator.com/item?id=24765868

dang• 6 years ago

https://news.ycombinator.com/item?id=24940676 is also related.

petters• 6 years ago

I thought XPath was terrible beyond 1.0?

E.g. https://tomforb.es/xcat-1.0-released-or-xpath-injection-issu...

But it does not seem to be mentioned as an argument.

zmix4• 6 years ago

XPath beyond 1.0 can do the same things, that XPath 1.0 could do. You still can do your nifty one-liners. But it can do so much more now! Especially since it is a subset of XQuery now, and that's where things become very interesting.

throw_m239339• 6 years ago

I mean some people working on Chrome tried to remove XSL support at some point:

https://bugs.chromium.org/p/chromium/issues/detail?id=514995

which was already nuts, so they are clearly not interested in anything related to XML. XML is a fantastic tool, it's just that a whole generation of developers refused to even touch it and are biased against it.

And since Chrome is now basically the web... wait til there is only Chrome and Safari left and see what happens to web "standards"...

bawolff3• 6 years ago

I dont know, i think im biased against it because i have touched it (even of xslt is quite cool)

LaserToy• 6 years ago

I changed my opinion of XML after I had to deal with yaml.

Whoever thought it is a good idea for complex configs (kubernetes) was wrong

amaccuish• 6 years ago

I think enterprise Java gave xml a bad name. I just hate having to go into a Wildfly config.

rhacker• 6 years ago

Would have been less controversial if they just rename it to hpath.

csours• 6 years ago

I feel like a real dummy right now... Aren't modern web pages xhtml??? Isn't xhtml xml???

Removing support for XPath kills MANY tests. I feel like a crazy person. Can someone help with context?

goto11• 6 years ago

Modern web pages are HTML. You can write HTML in a way that it is compliant with the XHTML standard and therefore also valid XML, but it will still be rendered by the HTML engine in the browser, not the XML engine.

dathinab4• 6 years ago

No, xhtml died.

Pages are html and not neccessary xml compatible.

XPath is used for html independent of xml (because the structure is very similar and as such querying html with xml based query systems can work).

But for google it's part of their xml code base they don't want to touch.

richx4• 6 years ago

The European Securities and Exchange Commission (ESMA) has just now mandated all listed companies in the EU to publish their annual financial statements in XHTML instead of PDF or paper. Combined with XBRL taxonomies it’s a very powerful structured format. Please don’t forget that XML is widespread in business applications and I haven’t seen any similar powerful replacement for XML validation and XPath. Please let me know if you know one.

barefootliam6• 6 years ago

There isn't an alternative, largely i think because XML people come at the problem from the idea that documents are primary, not just artifacts of programs.

zmix4• 6 years ago

Very good comment. I wholeheartedly agree.

Also, there is a whole world outside of software development: The world, that uses this software. And that world produces documents, that need to be managed. And those, who manage them, are users, not programmers.

namedgraph5• 6 years ago

Data-driven architecture is the future. Data has to be driving the software, not the way around.

Chrome unlikely to support XPath 3.1

Related Stories