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

101–110 of 114 posts

Re: Chrome unlikely to support XPath 3.1

#101

Post by zmix »

barefootliam wrote: post #75
richx wrote: post #56

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…

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.

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.

Re: Chrome unlikely to support XPath 3.1

#102

Post by zmix »

petters wrote: post #29

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.

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.

Re: Chrome unlikely to support XPath 3.1

#105

Post by zmix »

somehnguy wrote: post #86
richx wrote: post #66

Earlier quoted context omitted.

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.

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.

Where is XML a usability nightmare?

Re: Chrome unlikely to support XPath 3.1

#107

Post by Mikhail_Edoshin »

nimish wrote: post #98
netfl0 wrote: post #47

Earlier quoted context omitted.

I can’t tell if this was a serious response, I am not trying to pull your leg.

It’s a very serious response. XML is a defective technology that has no place in the modern web. Perhaps the only successful bit is SVG, for lack of a better alternative. MathML is a failure — katex and mathjax do a fundamentally better job of rendering mathematics on the web — and are based on what people who write a lot of math actually use: tex and friends. If you need to interpret XML documents as HTML, use some…

XML is rather successful outside of the web in spite of all the vitriol poured on it. And modern web is under a specific and unique combination of pressures to serve as a reference for the rest of software development. If you looking for something that deserves the name of "defective" you don't need to go any further.

For example, the problem of math is not only to render it in the browser. At the very least we may want to render it on the server and to index it. And since math expressions are in a document, there's a general need to process them programmatically for a variety of purposes, some of which are not even clear at the moment. With the KaTeX or MathJax solution each such scenario would have to include KaTeX or MathJax or a custom parser for the underlying TeXlike language the only upside of which is that it's somewhat well-known and more or less easy to write. With MathML these and other scenarios can be handled with the standard XML toolchain. (And this doesn't mean we need to exclude that neat TeXlike language if we need to input it: we only need to add a step that transforms it into MathML.) MathML, is, of course, not simple, but it addresses both presentational and semantic sides of a formula, something that no other solution does. It's complex because the math is complex.

Re: Chrome unlikely to support XPath 3.1

#108

Post by rangoon626 »

foota wrote: post #93
rangoon626 wrote: post #84

Earlier quoted context omitted.

Yes, I should implement scorched-earth cache busting and force a complete reload of all bundles, because one craptastic browser relies on aggressive caching so that their complimentary ad services doesn’t bog down website performance. That’s exactly how the web should be.

... Yes? I mean, if you're not whole into the js ecosystem you can just use a cache buster parameter on your js requests in development, but I think the recommended approach is to use module splitting so that parts of the bundle that don't change remain the same. Alternatively if you just hate caching you can set cache control headers on your js. I think tying caching behavior to Google's web sites is silly, caching…

... No.

Every other browser seems to find a sane middle ground.

Anyway this was never about my own practices, this was about how Chrome has become annoying and how it will result in attrition. The faster this happens, the better.

Re: Chrome unlikely to support XPath 3.1

#109

Post by dathinab »

bawolff wrote: post #88
dathinab wrote: post #55

Earlier quoted context omitted.

> Whoever thought it is a good idea for complex configs (kubernetes) was wrong Kinda agree, YAML is a mess wrt. many aspects. > I changed my opinion of XML after I had to deal with yaml. I still didn't change my opinion about XML, it is similar a mess wr. many aspects. For both there is a sane sub-set which isn't a mess and which looks reasonable fine. Sadly this subset has not necessary clear borders. So I guess a s…

So... JSON? Honestly if json had comments and allowed trailing commas it would be perfect.

It also would at least need a first class base64 type IMHO.

Oh and NaN,-Inf,+Inf.

Re: Chrome unlikely to support XPath 3.1

#110

Post by namedgraph »

inimino wrote: post #95
kerng wrote: post #57

Earlier quoted context omitted.

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.

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.

Could a part of the reason that XPath stayed a niche technology that WHATWG and Google continuously chipped away at XML support and compatibility and shipped 20 year old implementations?
Post reply on HN