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

41–50 of 114 posts

Re: Chrome unlikely to support XPath 3.1

#41

Post by cesarb »

znpy wrote: post #18
retrofuturism wrote: post #5

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

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

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.

Re: Chrome unlikely to support XPath 3.1

#42

Post by halflings »

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 counter to that goal."

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

Re: Chrome unlikely to support XPath 3.1

#43

Post by coldtea »

netheril96 wrote: post #23
the_other wrote: post #17

Earlier quoted context omitted.

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.

>MathML does not work well even in Safari and Firefox

Parent understood that, that's why they said "Don’t let perfect be the enemy of good".

They mean "It might not work too well, but it works well enough to use".

Re: Chrome unlikely to support XPath 3.1

#44

Post by coldtea »

cesarb wrote: post #41
znpy wrote: post #18

Earlier quoted context omitted.

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

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.

Usually most of the size is various UI assets, not features.

Re: Chrome unlikely to support XPath 3.1

#46

Post by coldtea »

jeffbee wrote: post #39
josephcsible wrote: post #27

Earlier quoted context omitted.

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

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

Like my mother used to say: "A standards working group decision should be binding to its members or there are no standards".

Re: Chrome unlikely to support XPath 3.1

#48

Post by goto11 »

csours wrote: post #45

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?

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.

Re: Chrome unlikely to support XPath 3.1

#49

Post by acqq »

samtheprogram wrote: post #40
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

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

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

Re: Chrome unlikely to support XPath 3.1

#50

Post by jeffbee »

coldtea wrote: post #46
jeffbee wrote: post #39

Earlier quoted context omitted.

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

Like my mother used to say: "A standards working group decision should be binding to its members or there are no standards".

That's not how WHATWG is governed.
Post reply on HN