Getting rid of XSLT from the browser would be a mistake, no doubt about it.
You can see it clear as day in the github thread that they weren't asking permission, they were doing it no matter what, all their concerns about security just being the pretext.
It would have been more honest of them to just tell everyone to go fuck themselves.
The article is about intentional killing XSLT/XML in the browser. I think it is evolutionary: devs switched to JSON, AI agents don't care at all - they can handle anything; XML just lost naturally, like GOPHER
I think JSON is generally better than XML (although XML is better for some things, mostly it isn't), but JSON is not so good either; I think DER format is much better.
I love the little historical overview in the post. With more than 25 years of hindsight, the push against user-centred standards is so obvious. W3C is always better than whatever coolaid-du-jour big corps wants you to drink because (at the very least), someone actually thinks "how is this going to affect people using it" as opposed to Google/Apple's approach "How is this going to affect our revenue".
To be honest, in my recollection, in 2013 what the W3C was doing was actually seen as user hostile and HTML5 was seen as a good thing for users.
Part of the community really hated XHTML and its strictness. I remember Mozilla being at the vanguard then rather than Google.
I think the situation was and is a lot more messy and complicated than what the article presents but presenting it fully would make for a less compelling narrative.
Coders have this tendency to value ideology over practicality. What matters is something that works and people use, not a theoretical picture of how it could have worked in an alternative timeline.
Google is evil, but man, I never missed XSLT. I'm old enough to remember it and it gives me war flashbacks.
The good thing is that it makes you strong and resilient to pain over time. It's painfully unreadable. It's verbose (ask chatgpt to write a simple if statement). Loops? - here's your foreach and that's all we have. Debugging is for weak, stdout is your debugger.
It's just shit tech, period. I hope devs that write soul harvesting surveillance software at Google go to hell where they are forced to write endless xslt's. Maybe that's the reason they want to remove it from Chrome.
Google is a corporation maximizing shareholder value. That this goal is not aligned with serving the greater good and freedom should come as no surprise.
> in 2023, Google renames their chatbot from Bard to [Gemini][gemini] thereby completely eclipsing the 4-year-old independent protocol by the same name; this is possibly coincidental, which would make it the only unintentional attack on the open web by Google in the last 15 or so years —and at this point even that is doubtful;
So the theory is that Google chose the name of its AI -- easily one of the hardest and most revenue-impacting naming decisions it's made in years -- in order to create a name collision with a protocol nobody's heard of that's trying to revive GOPHER?
This is so obviously false that you have to re-read the rest of the article with the knowledge that the author is misunderstanding what they're seeing.
Much of what the author describes is increasing security and not wanting to work with XML.
Did you at least read the excerpt you posted? It says the opposite of your conclusion, this is not even the worse interpretation of what was said, it's plain false.
I suppose the definition of intentional is a bit murky here.
Yeah, you're right that Google probably didn't look at a list of open web technologies that they disagree with and choose one for their new tool. I guess I'll call that "malicious intention".
I'm sure that, however the name was picked, Google's lawyers looked for prior uses of the name. I'm sure it came up, and Google shrugged its shoulders in indifference. Maybe someone brought up the fact this would hurt some open standard or whatever, but nobody in power cared. Is this the same kind of malicious? Probably not, but it still shows that Google doesn't care about the open web and the collateral damage they cause.
“The reason implementations are riddled with CVEs is neglect”
Imo this misses the point a bit. If it is neglected and is going to keep producing bugs and not many people are developing on it, then it maybe makes sense to kill it.
This also means new browsers won’t have to implement it maybe?
Because those neglecting it are the same that want to remove it. So it's not “we want to remove it because it's neglected”, but “we want to remove it so we'll neglect it”. This is a pretty standard M.O. for the destruction of the commons.
If you look at the WHATWG GH issue, you'll see that two distinct, modern, maintained implementations of XSLT, one of which in Rust (so considerably less likely to be affected by memory bugs) have been proposed as alternatives to what's currently used in WebKit and Blink. The suggestions has been ignored without a motivation, because the neglect is the point.
To me, when google rename Bard to Gemini, they should have been dragged into court. But the Gemini people have no funds for this, so big money wins. But at the least a trademark complaint could have been filed.
In any case, I do not use google at all unless forced. My old gmail address is a "dump" where if a site asks for am email, they get that one. I only long into to gmail to delete the "spam" I get.
Other anecdotal experiences with Google and their specific attitude towards user/developer needs:
- Stable Array.sort (2008 – 2018): Of course it doesn't have to be stable, spec does not dictate it right now, it is good for performance, and some other browser even started to do this like we do: http://crbug.com/v8/90 .
- Users don't userstyle (2015– ) Of course we absolutely can an will remove this feature from the core, despite it is mandated by several specifications: https://bugs.chromium.org/p/chromium/issues/detail?id=347016 .
- SMIL murder attempt was addressed in the OP article (I think they keep similar sentiment towards MathML either) but luckily was eventually retracted. I guess/hope this XSLT will have similar "storm in the teacup" trajectory.
They have been killing open anything for a long time. Very similar to Microsoft. As an example, they have the power to block emails for a large portion of the Internet. This is used for good, like spam and scams, but also bad, like political viewpoints they don't like.
The same can be said about their search engine. This most likely has already altered the outcomes of elections and should have been investigated years ago.
I also think Google is doing many bad things with it (although many of the things are not specific to Google, they are doing most of it). Removing stuff, and also adding stuff that just makes it worse, as well.
Many of the things they add, or that other things are replaced with, are seems to just mostly benefit Google (and sometimes Cloudflare), rather than actually helping you. This is true of the new Web Authentication systems as much as with other things. (And, they seem to want to make you use bloated JavaScripts even if neither the author nor reader want to do.)
> in 2025 Google announces a change in their Chrome Root Program Policy that within 2026 they will stop supporting certificate with an Extended Key Usage that includes any usage other than server
I agree that Google should not have done that, but it is often more useful to use different certificates for clients anyways.
While I think XML is generally not as good as other formats (I think DER is generally better), it works better than some other formats for some things. This is not a reason to get rid of XSLT though; it is useful. There are other reasons to not require it (e.g. to simplify implementations, but they are currently too complicated mainly due to the newer stuff instead anyways), but that does not mean that it cannot be used, that it cannot be implemented, etc. (For example, a static site generator might convert XML+XSLT to HTML if you need it while also providing the original XML+XSLT files to anyone who wants them, therefore making server-side and client-side working.)
I agree that XML is much better for document content and markup than for configuration and other stuff. I think still there are problems with XML, although that problem can be avoided (and often is, now, since JSON is often used instead, but JSON has its own problems, too).
32 comments
[ 3.3 ms ] story [ 52.5 ms ] threadYou can see it clear as day in the github thread that they weren't asking permission, they were doing it no matter what, all their concerns about security just being the pretext.
It would have been more honest of them to just tell everyone to go fuck themselves.
Part of the community really hated XHTML and its strictness. I remember Mozilla being at the vanguard then rather than Google.
I think the situation was and is a lot more messy and complicated than what the article presents but presenting it fully would make for a less compelling narrative.
As is I don’t really buy it personally.
One way is to tell everyone to use Firefox (uBlock origin works there)
It is still an issue that the Mozilla Foundation is still 80% funded by Google though, so this needs to be solved first.
Somehow Firefox needs to be moved away from Mozilla if they cannot find an alternative funding source other than Google.
It would be a horrible existence to value anything else. What reason is there to get up in the morning if you think things couldn't be better?
Every Chrome installation or related fork, plus Electron shippments, counts.
The good thing is that it makes you strong and resilient to pain over time. It's painfully unreadable. It's verbose (ask chatgpt to write a simple if statement). Loops? - here's your foreach and that's all we have. Debugging is for weak, stdout is your debugger.
It's just shit tech, period. I hope devs that write soul harvesting surveillance software at Google go to hell where they are forced to write endless xslt's. Maybe that's the reason they want to remove it from Chrome.
So the theory is that Google chose the name of its AI -- easily one of the hardest and most revenue-impacting naming decisions it's made in years -- in order to create a name collision with a protocol nobody's heard of that's trying to revive GOPHER?
This is so obviously false that you have to re-read the rest of the article with the knowledge that the author is misunderstanding what they're seeing.
Much of what the author describes is increasing security and not wanting to work with XML.
Yeah, you're right that Google probably didn't look at a list of open web technologies that they disagree with and choose one for their new tool. I guess I'll call that "malicious intention".
I'm sure that, however the name was picked, Google's lawyers looked for prior uses of the name. I'm sure it came up, and Google shrugged its shoulders in indifference. Maybe someone brought up the fact this would hurt some open standard or whatever, but nobody in power cared. Is this the same kind of malicious? Probably not, but it still shows that Google doesn't care about the open web and the collateral damage they cause.
Imo this misses the point a bit. If it is neglected and is going to keep producing bugs and not many people are developing on it, then it maybe makes sense to kill it.
This also means new browsers won’t have to implement it maybe?
If you look at the WHATWG GH issue, you'll see that two distinct, modern, maintained implementations of XSLT, one of which in Rust (so considerably less likely to be affected by memory bugs) have been proposed as alternatives to what's currently used in WebKit and Blink. The suggestions has been ignored without a motivation, because the neglect is the point.
In any case, I do not use google at all unless forced. My old gmail address is a "dump" where if a site asks for am email, they get that one. I only long into to gmail to delete the "spam" I get.
- Stable Array.sort (2008 – 2018): Of course it doesn't have to be stable, spec does not dictate it right now, it is good for performance, and some other browser even started to do this like we do: http://crbug.com/v8/90 . - Users don't userstyle (2015– ) Of course we absolutely can an will remove this feature from the core, despite it is mandated by several specifications: https://bugs.chromium.org/p/chromium/issues/detail?id=347016 . - SMIL murder attempt was addressed in the OP article (I think they keep similar sentiment towards MathML either) but luckily was eventually retracted. I guess/hope this XSLT will have similar "storm in the teacup" trajectory.
The same can be said about their search engine. This most likely has already altered the outcomes of elections and should have been investigated years ago.
Many of the things they add, or that other things are replaced with, are seems to just mostly benefit Google (and sometimes Cloudflare), rather than actually helping you. This is true of the new Web Authentication systems as much as with other things. (And, they seem to want to make you use bloated JavaScripts even if neither the author nor reader want to do.)
> in 2025 Google announces a change in their Chrome Root Program Policy that within 2026 they will stop supporting certificate with an Extended Key Usage that includes any usage other than server
I agree that Google should not have done that, but it is often more useful to use different certificates for clients anyways.
While I think XML is generally not as good as other formats (I think DER is generally better), it works better than some other formats for some things. This is not a reason to get rid of XSLT though; it is useful. There are other reasons to not require it (e.g. to simplify implementations, but they are currently too complicated mainly due to the newer stuff instead anyways), but that does not mean that it cannot be used, that it cannot be implemented, etc. (For example, a static site generator might convert XML+XSLT to HTML if you need it while also providing the original XML+XSLT files to anyone who wants them, therefore making server-side and client-side working.)
XML for app configuration or basic data transfer formats = horrible.
Unfortunately I fear so many people got burned by the latter issues they forgot (or missed entirely) all the greatness of the first.
https://en.m.wikipedia.org/wiki/Efficient_XML_Interchange
It's XML of the size of brotli compressed Json.