Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Chrome unlikely to support XPath 3.1

github.com

Post reply on HN
Print view View original

61–70 of 114 posts

Re: Chrome unlikely to support XPath 3.1

#61

Post by nwellnhof »

aravindet wrote: post #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 o…

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

Re: Chrome unlikely to support XPath 3.1

#62

Post by dathinab »

nimish wrote: post #12
netfl0 wrote: post #10

Earlier quoted context omitted.

Have they proposed an alternative?

HTML and JavaScript. Works for PDF with PDF.js XML is no longer relevant to the modern web

PDFs don't use HTML.

Standard PDFs are also not XML based.

PDF.js ab-uses HTML to somehow render PDF.

The HTML used by PDF.js is in no way a sane "human readable structured data" format. But a "browser compatible" ad-hoc representation for the underlying PDF representation.

Lastly PDF are not formats for structured data, which is what XML is all about in the end.

So I have no idea why you thing HTML+Js is a sane replacement for XML use cases, it isn't. It isn't a replacement to a degree that IMHO it doesn't even really makes sense (the JS part).

Re: Chrome unlikely to support XPath 3.1

#63

Post by repiret »

drran wrote: post #32
netheril96 wrote: post #6

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.

It looks quite capable: https://mdn.mozillademos.org/en-US/docs/Mozilla/MathML_Proje... https://mdn.mozillademos.org/en-US/docs/Mozilla/MathML_Proje... https://mdn.mozillademos.org/en-US/docs/Mozilla/MathML_Proje...

I followed your first link on Safari. Some things look fine. Some things are ugly, which is too bad but tolerable. If it was just that, I might consider MathML. But some things are rendered in a way that changes their meaning, and that’s totally unacceptable.

Re: Chrome unlikely to support XPath 3.1

#64

Post by richx »

halflings wrote: post #42
aravindet wrote: post #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 o…

> 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 count…

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?

Re: Chrome unlikely to support XPath 3.1

#66

Post by richx »

somehnguy wrote: post #13

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.

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.

Re: Chrome unlikely to support XPath 3.1

#68

Post by runroader »

chromakode wrote: post #35
crazypython wrote: post #3

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

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

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.

Re: Chrome unlikely to support XPath 3.1

#69

Post by ljm »

LaserToy wrote: post #53
bawolff wrote: post #51

Earlier quoted context omitted.

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

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

XML isn't the most enjoyable thing to write (although we don't seem to have a problem when it comes to HTML and JSX). There's the whole debate around when to use attributes or children, and all that, which I can see would be a problem if the schema is poorly defined.

But then, it's not like YAML is any better with how confusing its whitespace rules can be, and all the short-hand ways of avoiding explicit syntax (see: do you indent arrays in a hash or not? What's up with having to double-indent in some cases but not another?). And given the length of many yaml-based configs, it becomes pretty much useless once you're a thousand lines in, which you'll easily approach with a CI config.

At least with XML, you could actually attach a stylesheet to it (even just CSS) and you'd automatically have a human readable version of the file, without having to bother with converting YAML or JSON or whatever. That'd simplify the generation of a lot of internal dashboards.

Re: Chrome unlikely to support XPath 3.1

#70

Post by dmitriid »

aravindet wrote: post #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 o…

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

Post reply on HN