Live data from Hacker News

Google is killing the open web, part 2

wok.oblomov.eu

21–30 of 362 posts

Re: Google is killing the open web, part 2

#22
post #15
post #7

Earlier quoted context omitted.

The drama around the XSLT stuff is ridiculous. It's a dead format that no one uses[1], no one will miss, no one wants to maintain, and that provides significant complexity and attack surface. It's unambiguously the right thing to do to remove it. No one who actually works in the web space disagrees. Yes, it's a problem that Chrome has too much market share, but XSLT's removal isn't a good demonstration of that. [1] Y…

> It's a dead format that no one uses[1], This has to be proven by Google (and other browser vendors), not by people coming up with examples. The guy pushing "intent to deprecate" didn't even know about the most popular current usage (displaying podcast RSS feeds) until after posting the issue and until after people started posting examples: https://github.com/whatwg/html/issues/11523#issuecomment-315... Meanwhile Go…

> Also, "no one uses it" is rich considering that XSLT's usage is 10x the usage of features Google has no trouble shoving into the browser and maintaining. Compare XSLT https://chromestatus.com/metrics/feature/timeline/popularity... with …

Comparing absolute usage of an old standard to newer niche features isn’t useful. The USB feature is niche, but very useful and helpful for pages setting up a device. I wouldn’t expect it to show up on a large percentage of page loads.

XSLT was supposed to be a broad standard with applications beyond single setup pages. The fact that those two features are used similarly despite one supposedly being a broad standard and the other being a niche feature that only gets used in unique cases (device setup or debugging) is only supportive of deprecating XSLT, IMO

Re: Google is killing the open web, part 2

#23

I don’t know. The author makes some arguments I could get entertain and get behind, but they also enumerate the immense complexity that they want web browsers to support (incl. Gopher). Whether or not Google deprecating XSLT is a “political” decision (in authors words), I don’t know that I know for sure, but I can imagine running the Chrome project and steering for more simplicity.

The case for JPEG XL is much better than that for XSLT. On the other hand, people who program in C will always be a little terrified of XML and everything around it since the parsing code will be complex and vulnerable.

Having a background in C/C++, that was the problem I ran into when I had to learn XSLT at translation company that used it to style documents across multiple formats. The upside of using XML was that you could store semantically rich info into the tags for the translators and designers. The downside, of course, with all the metadata, was that the files could be really large and the XSLT was usually specifically programmed for that particular document and very verbose so the XSLT template might only be used a couple times.

Re: Google is killing the open web, part 2

#24

I have yet to read an article complaining about XSLT deprecation from someone who can explain why they actually used it and why it’s important to them. > I will keep using XSLT, and in fact will look for new opportunities to rely on it. This is the closest I’ve seen, but it’s not an explanation of why it was important before the deprecation. It’s a declaration that they’re using it as an act of rebellion.

Yeah, the idea that it's some kind of foundation of the "open web" is quite silly.

I've used XSLT plenty for transforming XML data for enterprises but that's all backend stuff.

Until this whole kerfuffle I never knew there was support for it in the browser in the first place. Nor, it seems, did most people.

If there's some enterprise software that uses it to transform some XML that an API produces into something else client-side, relying on a polyfill seems perfectly reasonable. Or just move that data transformation to the back-end.

Re: Google is killing the open web, part 2

#25

Removing XSLT from browsers was long overdue and I'm saying that as ex-maintainer of libxslt who probably triggered (not caused) this removal. What's more interesting is that Chromium plans to switch to a Rust-based XML parser. Currently, they seem to favor xml-rs which only implements a subset of XML. So apparently, Google is willing to remove standards-compliant XML support as well. This is a lot more concerning.

It’s interesting to see the casual slide of Google towards almost internet explorer 5.1 style behavior, where standards can just be ignored “because market share”.

Having flashbacks of “ ”

Re: Google is killing the open web, part 2

#26
post #17

Earlier quoted context omitted.

Another bit of ridiculousness is pinning the removal on Google. Removing XSLT was proposed by Mozilla and unanimously supported with no objections by the rest of the WHATWG. Go blame Mozilla if you want somebody to get mad at, or least blame all the browser vendors equally. This has nothing to do with Chrome’s market share.

Google are the ones immediately springing into action. They only started collecting feedback on which sites may break after they already pushed "Intention to remove" and prepared a PR to remove it from Chromium.

> Google are the ones immediately springing into action.

You say that like it's a bad thing. The proposal was already accepted. The most useful way to get feedback about which sites would break is to actually make a build without XSLT support and see what breaks.

Re: Google is killing the open web, part 2

#27
post #19
post #9

Do you remember that chrome lost FTP support recently? The protocol was widely used and simple enough.

Widely used? By whom? Devs who don't understand rsync or scp? Give me a practical scenario where a box is running FTP but not SSH. Edit: then account for the fact that this rare breed of content uploader doesn't use an FTP client... there's absolutely no reason to have FTP client code in a browser. It's an attack surface that is utterly unnecessary.

Also, the protocol is pretty much a holdover from the earliest days, before encryption, or complicated NATs. I remember using it with just telnet a few times. It's pretty cool, but absolutely nobody should be using FTP these days. I remember saying this back in the 2005, and here we are 20 years later, someone still lamenting dropping FTP support from a browser? I think we're decades overdue.

Re: Google is killing the open web, part 2

#28

I have yet to read an article complaining about XSLT deprecation from someone who can explain why they actually used it and why it’s important to them. > I will keep using XSLT, and in fact will look for new opportunities to rely on it. This is the closest I’ve seen, but it’s not an explanation of why it was important before the deprecation. It’s a declaration that they’re using it as an act of rebellion.

What a horrible technology to wrap around your neck for rebellion's sake. XSLT didn't succeed because it's fundamentally terrible and was a bad idea from the very beginning.

But I suppose forcing one's self to use XSLT just to spite Google would constitute its own punishment.

Re: Google is killing the open web, part 2

#29
post #7

Earlier quoted context omitted.

The drama around the XSLT stuff is ridiculous. It's a dead format that no one uses[1], no one will miss, no one wants to maintain, and that provides significant complexity and attack surface. It's unambiguously the right thing to do to remove it. No one who actually works in the web space disagrees. Yes, it's a problem that Chrome has too much market share, but XSLT's removal isn't a good demonstration of that. [1] Y…

>Yes, I already know about your one European law example What example is that?

This page is styled via an XSLT transform: https://www.europarl.europa.eu/politicalparties/index_en.xml The drama mongers like to bring it up as an example of something that will be harmed by XSLT's removal, but it already has an HTML version, which is the one people actually use.
Post reply on HN