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

91–100 of 114 posts

Re: Chrome unlikely to support XPath 3.1

#91

Post by runlevel1 »

9HZZRfNlpR wrote: post #52
kgwxd wrote: post #30

Earlier quoted context omitted.

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

It sure does and it works, not sure how or what use case the parent has problems with. Would be quite interesting to find out.

Not the parent, but I have run into these ones before:

Issue 645845 (Open, ~4 years old): DevTools: "disable cache" doesn't work for media resources: https://bugs.chromium.org/p/chromium/issues/detail?id=645845

Issue 470030 (WontFix): 'Disable cache' should prevent HSTS redirects: https://bugs.chromium.org/p/chromium/issues/detail?id=574345

Issue 775435 (Fixed after ~1 year): Disable cache does not disable cached redirects https://bugs.chromium.org/p/chromium/issues/detail?id=775435

Re: Chrome unlikely to support XPath 3.1

#93

Post by foota »

rangoon626 wrote: post #84
foota wrote: post #78

Earlier quoted context omitted.

I mean, to some degree you need to take advantage of build options that put out resources under unique paths, which I'm fairly certain is standard guidance by now.

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 is a crucial part of performance for any heavy web application.

Re: Chrome unlikely to support XPath 3.1

#94

Post by Izkata »

kgwxd wrote: post #30
rangoon626 wrote: post #20

Earlier quoted context omitted.

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?

A product owner I worked with around 2016 regularly had problems with this, eventually we figured out whenever this happened the only way to clear her cache was to open dev tools, long-press reload, and pick the 3rd option (it only showed up when dev tools were open).

Re: Chrome unlikely to support XPath 3.1

#95

Post by inimino »

kerng wrote: post #57
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…

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.

Re: Chrome unlikely to support XPath 3.1

#96

Post by fomine3 »

runroader wrote: post #68
chromakode wrote: post #35

Earlier quoted context omitted.

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.

Technically true but is it mean anything? Support on iOS Safari is the important thing.

Re: Chrome unlikely to support XPath 3.1

#97

Post by lern_too_spel »

netheril96 wrote: post #6
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

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.

MathML support in Blink is under active development.

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

Re: Chrome unlikely to support XPath 3.1

#98

Post by nimish »

netfl0 wrote: post #47
nimish wrote: post #12

Earlier quoted context omitted.

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

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 javascript. The attack surface reduction of eliminating XPath, XHTML, XSLT and other mistakes like microformats is worth it alone.

I stand by this, having implemented enough of XPath, XML 1.1 and XSLT to implement WS-Security from scratch (have fun with c14n!).

The sooner we move on from the failed experiment of XHTML, the better. The idea that the browser is the means of extending the core document model is gone; most if not all power resides in the JS engine. If it makes sense to stick in the core browser engine, then it will be obvious when that is so via usage statistics.

You can compile libxml2 to wasm if you must (i’ve done this when I needed a more complete XPath implementation)

Re: Chrome unlikely to support XPath 3.1

#99

Post by stjohnswarts »

barefootliam wrote: post #83
cesarb wrote: post #41

Earlier quoted context omitted.

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.

Here at least, firefox depends on libxml2, which comes from a different package. But, bloated is in the eye of the beholder - there's always Dillo and lynx.

Which break on tons of sites because they simple can't render them and never will. That bloat isn't really bloat because it is necessary to handle what modern users want it to handle. Browsers aren't going to probably ever "diet" again. They'll only remove insecure features.

Re: Chrome unlikely to support XPath 3.1

#100

Post by londons_explore »

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…

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.

Post reply on HN