alt Hacker NewsGoogle is killing the open web, part 2
Comments
In part 1 of this article, the author wrote, "XSLT is an essential companion to RSS, as it allows the feed itself to be perused in the browser"
Actually, you can make an RSS feed user-browsable by using JavaScript instead. You can even run XSLT in JavaScript, which is what Google's polyfill does.
I've written thousands of lines of XSLT. JavaScript is better than XSLT in every way, which is why JavaScript has thrived and XSLT has dwindled.
This is why XSLT has got to go: https://www.offensivecon.org/speakers/2025/ivan-fratric.html
I don't disagree that Google is killing the open web. But XSLT is a pretty weak argument for showing that. It is an extremely complicated feature that is very seldom used. I am very doubtful dropping support is some evil political decision. It is much more likely they just don't want to sink resources into maintaining something that is almost never used.
For the specific use case of showing RSS and Atom feeds in the browser, it seems like a better solution would be to have built-in support in the browser, rather than relying on the use of XSLT.
This has nothing to do with the “open web”. I don’t know if the people saying this just don’t have a meaningful definition of what open means or what. “Open” doesn’t mean “supports everything anyone has ever shipped in a browser”. (Chrome should support Gopher, really? Gopher was literally never part of the World Wide Web.)
What’s happening is that Google (along with Mozilla and Safari) are changing the html spec to drop support for xslt. If you want to argue that this is bad because it “breaks the web”, that’s fine, but it has nothing at all to do with whether the web is “open”. The open web means anyone can run a web server. Anyone can write a web site. Anyone can build their own compatible browser (hypothetically; this has become prohibitively expensive). It means anyone can use the tech, not that the tech includes everything possible.
If you want to complain about Google harming the open web, there are some real examples out there. Google Reader deprecation probably hurt RSS more than anything else. AMP was/is an attempt to give Google tighter control over more web traffic. Chrome extension changes were pushed through seemingly to give Google tighter control over ad blockers. Gemini in the search results is an attempt to keep Google users from ever actually clicking through to web sites for information.
XSLT in the browser has been dead for years. The reality is that no browser developer has cared about xslt since 1.0. Don’t blame Google for the death of xslt when xslt 2.0 was standardized before Chrome was even released and no one else cared enough to implement it. The removal of xslt doesn’t change the openness of the web and the reality is that it breaks very little while eliminating a source of real security errors.
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.
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.
>Mozilla bent over to Google's pressure to kill off RSS by removing the “Live Bookmarks” features from the browser
They both were just responding to similar market demands because end users didn't want to use RSS. Users want to use social media instead.
>This is a trillion-dollar ad company who has been actively destroying the open web for over a decade
Google has both done more for and invested more into progressing the open web than anyone else.
>The WHATWG aim is to turn the Web into an application delivery platform
This is what web developers want and browsers our reacting to the natural demands of developers, who are reacting to demands of users. It was an evolutionary process that got it to that state.
>but with their dependency on the Blink rendering engine, controlled by Google, they won't be able to do anything but cave
Blink is open source and modular. Maintaining a fork is much less effort than the alternative of maintaining a different browser engine.
I think imma convert my blog to XML/XSLT. Nobody reads it anyway, but now I’ll be able to blame my lack of audience on chrome.
I’m no Google fan, but deprecating XSLT is a rare opportunity to shrink the surface area of the web’s “API” without upsetting too many people. It would be one less thing for independent browsers like Ladybird to worry about. Thus actually weakening Google’s chokehold on the browser market.
For the past 10-15 years, every time I look at web standards, it always feels like someone is trying to make browsers support their specific niche use case.
Seems like getting XSLT (and offering a polyfill replacement) is just a move in the direction of stopping applications from pushing their complexity into the browser.
Google is just one of the companies killing the open web. None of them will say it outright, but they'll just scrounge up enough "security" reasons for their decisions to seem palatable, even to the HN crowd.
They're just turning up the heat, even more so since AI became a thing.
Why can't the polyfill be enabled by default? It would fix the security issues and we wouldn't have to worry about breaking websites.
The JS polyfill also makes supporting modern XSLT feasible.
Prequel:
Google is killing the open web - https://news.ycombinator.com/item?id=44949857 - Aug 2025 (181 comments)
Also related. Others?
XSLT RIP - https://news.ycombinator.com/item?id=45873434 - Nov 2025 (459 comments)
Removing XSLT for a more secure browser - https://news.ycombinator.com/item?id=45823059 - Nov 2025 (337 comments)
Intent to Deprecate and Remove XSLT - https://news.ycombinator.com/item?id=45779261 - Nov 2025 (149 comments)
XSLT removal will break multiple government and regulatory sites - https://news.ycombinator.com/item?id=44987346 - Aug 2025 (146 comments)
Google did not unilaterally decide to kill XSLT - https://news.ycombinator.com/item?id=44987239 - Aug 2025 (128 comments)
"Remove mentions of XSLT from the html spec" - https://news.ycombinator.com/item?id=44952185 - Aug 2025 (535 comments)
Should we remove XSLT from the web platform? - https://news.ycombinator.com/item?id=44909599 - Aug 2025 (96 comments)
Do the up-and-coming new browsers/engines (Servo, Ladybird.. others?) plan to support XSLT? If they do already, do they want to remove it?
It is Chrome OS Platform nowadays, powered by Chrome market share, and helped by everyone shipping Electron garbage.
Isn't the decision made by all the browser vendors (including Apple and Mozilla)?
The day will come when DRM is used to protect the whole http body.
This page makes some wild claims, like Google wants to deprecate MathML, even though it basically just landed. Yeah, the Chrome team wasn't prioritizing the work and it came through Igalia, but the best time for Chrome to kill MathML would have been before it was actually usable on the web.
The post also fails to mention that all browsers want to remove XSLT. The topic was brought up in several meetings by Firefox reps. It's not a Google conspiracy.
I also see that the site is written in XHTML and think the author must just really love XML, and doesn't realize that most browser maintainers think that XHTML is a mistake and failure. Being strict on input in failing to render anything on an error is antithetical to the "user agent" philosophy that says the browser should try to render something useful to the user anyway. Forgiving HTML is just better suited for the messy web. I bet this fuels some of their anger here.
This guy seems pretty focused on XML based standards, but I think the reason XML based standards are dying is because people don't like working with XML.
Do you remember that chrome lost FTP support recently? The protocol was widely used and simple enough.
Isn't Google one of the few (if not only), major tech company that would want to keep alive the open web ... given their business model.
Okay, I was entertaining the author's position to a point, but I have to get off the train where they sing the praises of NPAPI.
Hey fam. I remember NPAPI. I wrote a very large NPAPI plugin.
The problem with NPAPI is that it lets people run arbitrary code as your browser. it was barely sandboxed. At best, it let any plugin do its level best to crash your browser session. At worst, it's a third-party binary blob you can't inspect running in the same thing you use to control your bank account.
NPAPI died for a good reason, and it has little to do with someone wanting to control your experience and everything to do with protecting you, the user, from bad actors. I think the author tips their hand a little too far here; the world they're envisioning is one where the elite hackers among us get to keep using the web and everyone else just gets owned by mechanisms they can't understand, and that's fine because it lets us be "wild" and "free" like we were in the nineties and early aughts again. Coupled with the author's downplaying of the security concerns in the XSLT lib, the author seems comfortable with the notion that security is less important than features, and I think there's a good reason that the major browser creators and maintainers disagree.
The author's dream, at the bottom, "a mesh of building blocks," is asking dozens upon dozens upon dozens of independent operators to put binary blobs in your browser outside the security sandbox. We stopped doing that for very, very good reasons.
Today I Learned: There's a built-in class called XSLTProcessor.
I like the idea they mentioned of "a browser made up of composable components, protocol handlers separate from primary document renderers separate from attachment handlers", and I had the same idea. (Not all browsers will have to be implemented in this way, and they are not necessarily all the same, but this can be helpful when you want this.)
There can be two kind of extensions, sandboxed VM codes (e.g. WebAssembly) and native codes; the app store will only allow sandboxed VM codes, and any native codes that you might want must be installed and configured manually.
There is also the issue of such things as: identification of file formats (such as MIME), character sets, proxies, etc.
I hade made up Scorpion protocol and file format which is intended to be between Gemini and "WWW as it should be if it was designed better". This uses ULFI rather than MIME (to avoid some of the issues of MIME), and supports TRON character code, and the Scorpion conversion file can be used to specify a way to handle unknown file formats (there are several ways that this can be specified, including by a uxn code).
So, an implementation can be versatile to support things that can be useful beyond only MIME and Unicode etc.
Adding some additional optional specifications to WWW might also help, e.g. a way to specify that certain parts of the document are supposed be overridden by the user specifications in the client when they are available (although in some cases the client could guess, e.g. if a CSS only selects by HTML commands and media queries and not by anything else (or no CSS at all), then it should be considered unnecessary and the user's specifications of CSS can be used instead if they have been specified). Something like the Scorpion conversion file would be another possibility to have, possibly by adding a response header.
The previous "Google is killing the open web" article also mentions some similar things, but also a few others:
> in 2015, the WHATWG introduces the Fetch API, purportedly intended as the modern replacement for the old XMLHttpRequest; prominently missing from the new specification is any mention or methods to manage XML documents, in favor of JSON
Handling XML or JSON should probably better be a separate function than the function for downloading files, though. (Also, DER is better for many things)
> in 2024, Google discontinues the possibility to submit RSS feeds for review to be included in Google News
This is not an issue having to do with web browsers, although it is related to the issues that do have to do with web browsers (not) handling RSS.
> 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 [...]; this effectively kills certificates commonly used for mutual authentication
While I think they should not have stopped supporting such certificates (whoever the certificate is issued to probably should better make their own decision), it is usually helpful to use different certificates for client authentication anyways, so this is not quite as bad as they say, although it is still bad.
(X.509 client authentication would also have many other benefits, which I had described several times in the past.)
> in 2021, Google tried to remove [alert(), prompt(), and confirm()], again citing “security” as reason, despite the proposed changes being much more extensive than the purported security threat, and better solutions being proposed
Another issue is blocking events and JavaScript execution (which can sometimes be desirable; in the case of frames it should be better to only block one frame though), and modal dialog boxes potentially blocking other functions in the browser (which is undesirable). For the former case, there other other things that can be done, though, such as a JavaScript object that controls the execution of another JavaScript context which can then be suspended like a generator function (without needing to be a generator function).
I don't think I'm plugged into the side of the Internet that considers XML "the backbone of an independent web."
I think XML has some good features, but in general infatuation with it as either a key representation or key transmission protocol has waned over the years. Everything I see on the wire these days is JSON or some flavor of binary RPC like protobuffer; I hardly ever see XML on the wire anymore.
> ...just in case the questionable “no politics” policies —which consistently prove to be weasel words for “we're right-wingers but too chicken to come out as such”— weren't enough to stay away from it.
I am sympathetic to the stance of the article, but this line really turned me off and made me wonder if I was giving the writer too much credit. This kind of "if you're not with me, then you suck" outlook is childish and off-putting.
I know it's hard for some terminally political people to understand, but some of us really, really think it's a strength to work with teammates who hold different opinions than our own.
"The WHATWG aim is to turn the Web into an application delivery platform, a profit-making machine for corporations where the computer (and the browser through it) are a means for them to make money off you rather than for you to gain access to services you may be interested in."
"Such vision is in direct contrast with that of the Web as a repository of knowledge, a vast vault of interconnected documents whose value emerges from organic connections, personalization, variety, curation and user control. But who in the WHATWG today would defend such vision?"
"Maybe what we need is a new browser war. Not one of corporation versus corporation -doubly more so when all currently involved parties are allied in their efforts to enclose the Web than in fostering an open and independent one- but one of users versus corporations, a war to take back control of the Web and its tools."
It should be up to the www user not the web developer to determine how they prefer the documents to appear on their screen
Contrast this with one or a few software programs, i.e, essentially a predetermined selection (no choice), that purport to offer all possible preferences to all www users, i.e., the so-called "modern" browser. These programs are distributed by companies that sell ad services and their business partners (Mozilla)
Documents can be published in a "neutral" format, JSON or whatever, and users can choose to convert this, if desired, to whatever format they prefer. This is more or less the direction the web has taken however at present the conversion is generally being performed by web developers using (frequently obfuscated) Javascript, outside the control of the user
Although from a technical standpoint, there is nothing that requires (a) document retrieval and (b) document display to be performed by the same program, commercial interests have tried to force users toward using one program for everything (a "do everything program")^1
When users run "do everything programs" from companies selling ad services and their business partners to perform both (a) and (b), they end up receiving "documents" they never requested (ads) and getting tracked
If users want such "do everything" corporate browsers, if they prefer "do everything programs", then they are free to choose them, but there should be other choices and it should be illegal to discriminate against other software as long as rules of "netiquette" are followed. A requirement to use some "do everything program" is not a valid rule
"There's more to the Internet than the World Wide Web built around the HTTP protocol and the HTML file format. There used to be a lot of the Internet beyond the Web, and while much of it still remains as little more than a shadow of the past, largely eclipsed by the Web and what has been built on top of it (not all of it good) outside of some modest revivals, there's also new parts of it that have tried to learn from the past, and build towards something different."
Internet subscribers pay a relatively high price for access in many countries
According to one RFC author the www became the "the new waist"
But to use expensive internet access only for "the web", especially a 100% commercial, obsessively surveilled one filled with ads, is also a "waste", IMHO
1. Perhaps the opposite of "do one thing well". America's top trillionaire wants to create another of these "do everything programs", one to rule them all. These "do everything programs" will always exist but they should never be the only viable options. They should never be "required"
"Nobody wants my nerd bullshit, part 42"
[dead]
[dead]
[flagged]
What you actually want is a web that isn't decided by the whims of massive monopolies, not XSLT. XSLT is not good. Google will not be caring that you do not comply, and that you don't install their polyfill; it's some real vote with your wallet middle-class style consumer activism. It's an illusion of control. If you don't eat the bugs, you'll starve, then everyone is eating the bugs.
Try having an opposition party that isn't appointing judges like Amit Mehta. Or pardoning torturers, and people who engineered the financial crash, and people who illegally spied on everyone, etc., etc. But good luck with that, we can't even break up a frozen potato monopoly.
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.