Ironically, that text is all you get if you load the site from a text browser (Lynx etc.) It doesn't feel too different from <noscript>This website requires JavaScript</noscript>...
I now wonder if XSLT is implemented by any browser that isn't controlled by Google (or derived from one that is).
I should've worded differently. By the narrative of this website, Google is "paying" Mozilla & Apple to remove XSLT, thus they are "controlled" by Google.
I personally don't quite believe it's all that black and white, just wanted to point out that the "open web" argument is questionable even if you accept this premise.
I'm strongly against the removal of XSLT support from browsers—I use both the JavaScript "XSLTProcessor" functions [0] and "<?xml-stylesheet …?>" [1] on my personal website, I commented on the original GitHub thread [2], and I use XSLT for non-web purposes [3].
But I think that this website is being hyperbolic: I believe that Google's stated security/maintenance justifications are genuine (but wildly misguided), and I certainly don't believe that Google is paying Mozilla/Apple to drop XSLT support. I'm all in favour of trying to preserve XSLT support, but a page like this is more likely to annoy the decision-makers than to convince them to not remove XSLT support.
> but a page like this is more likely to annoy the decision-makers than to convince them to not remove XSLT support.
You cannot “convince decision-makers” with a webpage anyway. The goal of this one is to raise awareness on the topic, which is pretty much the only thing you can do with a mere webpage.
For some reason people seem to think raising awareness is all you need to do. That only works if people already generally agree with you on the issue. Want to save endangered animals? raising awareness is great. However if you're on an issue where people are generally aware but unconvinced, raising more awareness does not help. Having better arguments might.
> For some reason people seem to think raising awareness is all you need to do.
I don't think many do.
It's just that raising awareness is the first step (and likely the only one you'll ever see anyway, because for most topics you aren't in a position where convincing *you* in particular has any impact).
The easier thing might have been if Chrome & co opted to include any number of polyfills in JS bundled with the browser instead of making an odd situation where things just break.
I think you can recognize that the burden of maintaining a proven security nightmare is annoying while simultaneously getting annoyed for them over-grabbing on this.
Which would be a totally sensible thing you do. Especially if jpeg was a rarely used image format with few libraries supporting it, the main one being unmaintained.
IMHO, Google had become the most powerful tech company out there! It has a strong monopoly in almost every aspect of our lives and it is becoming extremely difficult to completely decouple from it. My problem with this is that it now dictates and influences what can be done, what is allowed and what not, and, with its latest Android saga (https://news.ycombinator.com/item?id=45017028), it's become worrying.
With browser being as complicated as they are, I kind of support this decision.
That said, I never used XSLT for anything, and I don’t see how is its support in browsers tied to RSS. (Sure you could render your page from your rss feed but that seems like a marginal use case to me)
Sure there are examples of websites using XSLT, but so far I've only seen the dozen or maybe two dozen, and it really looks like they are extremely rare. And I'm pretty sure the EU parliament et. al. will find someone to rework their page.
This really is just a storm in a waterglass. Nothing like the hundreds or tens of thousands of flash and java applet based web pages that went defunct when we deprecated those technologies.
In Safari at least clicking a rss link prompts you to open it in a rss reader, which I think is a superior experience. Reading a rss feed in browser is not without use, but I’d argue that that’s mostly the job of the site itself.
This is useful because feed URLs look the same as web page URLs, so users are inclined to click on them and open them in a web browser instead of an RSS reader. (Many users these days don't even know what an RSS reader is). The stylesheet allows them to view the feed in the browser, instead of just being shown the XML source code.
Why is this so critical? We dont due this for any other format. If you put an ms office document on a page, we dont have the browser render it, we download it and pass it off to a dedicated program. Why is RSS so special here?
I don't think it's a critical feature, but it is nice-to-have.
Imagine if you opened a direct link to a JPEG image and instead of the browser rendering it, you'd have to save it and open it in Photoshop locally. Wouldn't that be inconvenient?
Many browsers do support opening web-adjacent documents directly because it's convenient for users. Maybe not Microsoft Word documents, but PDF files are commonly supported.
You can do the transformation server-side, but it's not trivial to set it up. It would involve detecting the web browser using the "Accept" header (hopefully RSS readers don't accept text/html), then using XSLT to transform the XML to XHTML that is sent to the client instead, and you probably need to cache that for performance reasons. And that's assuming the feed is just a static file, and not dynamically generated.
In theory you could do the transformation client side, but then you'd still need the server to return a different document in the browser, even if it's just a stub for the client-side code, because XML files cannot execute Javascript on their own.
Another option is to install a browser extension but of course the majority of users will never do that, which minimizes the incentive for feed authors to include a stylesheet in the first place.
This site is a bit of a Rorschach test as it plays both sides of this argument: bad Google for killing XSLT, and the silliness of pushing for XSLT adoption in 2025.
"Tell your friends and family about XSLT. Keep XSLT alive! Add XSLT to your website and weblog today before it is too late!"
My first graduate job at a large British telco involved a lot of XML...
- WSDL files that were used to describe Enterprise services on a bus. These were then stored and shared in the most convoluted way in a Sharepoint page <shudders>
- XSD definitions of our custom XML responses to be validated <grimace>
- XSLTs to allow us to manipulate and display XML from other services, just so it would display properly on Oracle Siebel CRM <heavy sweats>
I know you're being sarcastic, but to be pedantic WebGPU (usually) uses canvas. Canvas is the element, WebGPU is one of the ways of rendering to a canvas, in addition to WebGL and CanvasRenderingContext2D.
And even that isn't enough; no browser supports WebGPU on all platforms out of the box. https://caniuse.com/webgpu
Chrome supports it on Windows and macOS, Linux users need to explicitly enable it. Firefox has only released it for Windows users, support on other platforms is behind a feature flag. And you need iOS 26 / macOS Tahoe for support in Safari. On mobile the situation should be a bit better in theory, though in my experience mobile device GPU drivers are so terrible they can't even handle WebGL2 without huge problems.
While I agree with the sentiment, I loathe these "retro" websites that don't actually look like how most websites looked back then. It's like how people remember the 80s as neon blue and pink when it was more of a brownish beige.
>While I agree with the sentiment, I loathe these "retro" websites that don't actually look like how most websites looked back then.
Countless websites on Geocities and elsewhere looked just like that. MY page looked like that (but more edgy, with rotating neon skull gifs). All those silly GIFs were popular and there were sites you could find and download some for personal use.
>It's like how people remember the 80s as neon blue and pink when it was more of a brownish beige.
In North Platte or Yorkshire maybe. Otherwise plenty of neon blue and pink in the 80s. Starting from video game covers, arcades, neon being popular with bars and clubs, far more colorful clothing being popular, "Memphis" style graphic design, etc.
This look with animations and bright text on dark repeated backgrounds was definitely popular for a while in the late 90s. You wouldn’t see it on larger sites like Yahoo or CNN, but it was definitely not unheard of for personal sites.
Gray backgrounds where also popular, with bright blue for unvisited links and purple for visited links. IIRC this was inspired by the default colors of Netscape Navigator 2.
If there is no white 1x1 pixel that is stretched in an attempt to make something that resembles actual layout, or multiple weird tables, I always ask: are they even trying.
In all seriousness- they got quite a good run with xslt. Time to let it rest.
1x1 pixels for padding and aligning were absolutely a thing in the late 90s (1997+). Don't know what alternative history you have in mind, but it was used at the "table layout" era.
What came later was the float layout hell- sorry, "solution".
I once got into a cab in NYC on Halloween and the driver said to me, hey, you really nailed that 80s hairstyle, thinking I had styled it for Halloween. I had to tell him dude, I’m from the 80s.
Looks like more of a retro-fun site, than a protest. Most serious websites of 90's had more like light brownish background with black text with occasional small image on the side, double borders for table cells, Times font, horizontal rules, links with bold font in blue color, side-bar with navigation links, bread-crumbs at the top telling where you are now, may be also next-prev links at the bottom, and a title banner at the top.
Game sites and other "desperate-for-attention" sites have the animated gifs all over, scrolling or blinking text, dark background with bright multi-colored text with different font sizes and types and sound as well, looking pretty chaotic.
> For over a decade, Chrome has supported millions of organizations with more secure browsing – while pioneering a safer, more productive open web for all.
… and …
> Our commitment to Chromium and open philosophy to integration means Chrome works well with other parts of your tech stack, so you can continue building the enterprise ecosystem that works for you.
Per the current version of https://developer.chrome.com/docs/web-platform/deprecating-x..., by August 17, 2027, XSLT support is removed from Chrome Enterprise. That means even Chrome's enterprise-targeted, non-general-web browser is going to lose support for XSLT.
Most people who use xslt like the grandparent described were never using it on the client side but on the server side. Nothing google chrone does will effect the server side.
To clarify: initially, the first web browser evolved from a SGML-based documentation browser at CERN. This was the first vision of the web: well-structured content pages, connected via hyperlinks (the "hyper" part meaning that links could point beyond the current set of pages). So, something like a global library. Many people are still nostalgic to this past.
Surprisingly, the "hyperlinked documents" structure was universal enough to allow rudimentary interactive web applications like shops or reservation forms. The web became useful to commerce. At first, interactive functionality was achieved by what amounted to hacks: nav blocks repeated at every page, frames and iframes, synchronous form submissions. Of course, web participants pushed for more direct support for application building blocks, which included Javascript, client-side templates, and ultimately Shadow DOM and React.
XSLT is ultimately a client-side template language too (can be used at the server side just as well, of course). However, this is a template language for a previous era: non-interactive web of documents (and it excels at that). It has little use for the current era: web of interactive applications.
XSLT has a life outside the browser and remains valuable where XML is the way data is exchanged. And RSS does not demand XSLT in the browser so far as I know. I think RIP is a bit excessive.
Please kill it, and then let's sit on a table with all adults people and decide what else should be killed. Maybe specify a minimum subset of modern feature a browser must support, please let's do it, it could light on again browser competition, projects like lady browser should not implement obscure backwrads compatible layout spec... What about the not modern web sites? The browser will ask to download an extra wasm module for opening something like https://www.spacejam.com/1996/
Youtube has pretty much always supported RSS and still does. Google killed their RSS reader, but if they wanted to kill RSS they wouldn't put it in their video platform.
When it comes to killing web technology, Google is mostly killing their own weird APIs that nobody ended up using or pruning away code that almost nobody uses according to their statistics.
Website is overly dramatic. Google doesn't hate XSLT, it is simply no one wants to maintain libxslt and it is full of security issues. Given how rarely it is used, it is just not worth the time + money. If the author wants to raise money to pay a developer willing to maintain libxslt, Google might revise the decision.
> or $0? Probably not. For $40m/year, I bet you could create an entire company
No sane commercial entity will dump even a cent into supporting an unused technology.
You have better luck pitching this idea to your senator to set up an agency for dead stuff - it will create tens or hundreds of jobs. And what's $40mm in the big picture?
> it is simply no one wants to maintain libxslt and it is full of security issues. Given how rarely it is used, it is just not worth the time + money.
As for money: Remind me what was Google's profit last year?
As for usage: XSLT is used on about 10x more sites [1] than Chrome-only non-standards like USB, WebTransport and others that Google has no trouble shoving into the browser
For me the usage argument sounds like an argument to kill the other standards rather than to keep this one.
Browsers should try things. But if after many years there is no adoption they should also retire them. This would be no different if the organization is charity or not.
Their products are built on open source. Android and Chrome come to my mind, but also their core infrastructure, it's all Linux and other FOSS under the hood.
Besides, xkcd #2347 [1] is talking about precisely that situation - there is a shitload of very small FOSS libraries that underpin everything and yet, funding from the big dogs for whom even ten fulltime developer salaries would be a sneeze has historically lacked hard.
Given that XSLT transforms XML into HTML, why has no one simply built a server side XSLT system? So these existing sites that use XSLT can just adopt that, and not need to rely on browser support.
I remember Gentoo Linux had all its official documentation in a system just like that, maybe 15-20 years ago. It was written and stored as XML, XSLT-processed and rendered into HTML on the webservers.
It is misleading in so far that XSLT is an independent standard [1] and isn't owned by Google, so they cannot "kill it", or rather they'd have to ask W3C to mark it as deprecated.
What they can do is remove support for XSLT in Chrome and thus basically kill XSLT for websites. Which until now I didn't even know was supported and used.
XSLT can be used in many other areas as well, e.g. for XSL-FO [2]
I don't think XSLT was invented for the purpose of rendering XML into HTML in the first place. Perhaps it never should have been introduced in browsers to begin with?
Also: "the needs of users and authors (i.e. developers) should be treated as higher priority than those of implementors (i.e. browser vendors), yet the higher priority constituencies are at the mercy of the lower priority ones": https://dev.to/richharris/stay-alert-d
The google graveyard is for products Google has made. It's not for features that were unshipped. XSLT will not enter the Google graveyard for that reason.
>We must conclude Google hates XML & RSS!
Google reader was shutdown due to usage declining and lack of willingness for Google to continue investing resources into the product. It's not that Google hate XML and RSS. It's that end users and developers don't use XSLT and RSS enough to warrant investing into it.
>by killing [RSS] Google can control the media
The vast majority of people in the world do not get their news by RSS. It's never would have taken over the media complex. There are other surfaces for news like X which Google is not able to control. Google is not the only surface where news can surface.
> Google are now trying to control LEGISLATION. With these technologies removed what is stopping Google?
It is quite a reach to say that Google removing XSLT will give them control over government legislation. They are completely unrelated.
>How much did Google pay for this support?
Google is not paying for support. These browsers have essentially a revenue sharing agreements with the traffic they provide Google with. The payments are for the traffic to Google.
(IIRC her salary increased something like 10 folds over the past 15 years or so)
Edit: It has jumped from $490k[1] to $6.25M[2] from 2009 to 2024.
Edit 2: by looking the figures up, I learned that she's gone at last, good riddance (though I highly doubt her successor is going to take a 12-fold pay cut)
It's truly troubling to see a trillion dollar corporation claim that the reason for removing a web browser feature that has existed since the 90s is because the library powering it was unmaintained for 6 months, and has security issues. The same library that has been maintained by a single developer for years, without any corporate support, while corporations reaped the benefits of their work.
Say what you will about how this is technically allowed in open source, it is nothing short of morally despicable. A real https://xkcd.com/2347/ situation.
It would cost Google practically nothing to step up and fix all security issues, and continue maintenance if they wanted to. To say nothing of simply supporting the original maintainer financially.
But IMO the more important topic within this whole saga is that libxml2 maintenance will also end this year. Will we also see support for XML removed?
> Say what you will about how this is technically allowed in open source, it is nothing short of morally despicable. A real https://xkcd.com/2347/ situation.
> But IMO the more important topic within this whole saga is that libxml2 maintenance will also end this year. Will we also see support for XML removed?
No, because xml has meaningful usage on the web. The situations are very different.
The author is frontend designer and has a nice website, too: https://dbushell.com/
I like the personal, individual style of both pages.
Heh, I honestly thought the domain name stood for "D-Bus Hell" and not their own name.
I now wonder if XSLT is implemented by any browser that isn't controlled by Google (or derived from one that is).
I personally don't quite believe it's all that black and white, just wanted to point out that the "open web" argument is questionable even if you accept this premise.
But I think that this website is being hyperbolic: I believe that Google's stated security/maintenance justifications are genuine (but wildly misguided), and I certainly don't believe that Google is paying Mozilla/Apple to drop XSLT support. I'm all in favour of trying to preserve XSLT support, but a page like this is more likely to annoy the decision-makers than to convince them to not remove XSLT support.
[0]: https://www.maxchernoff.ca/tools/Stardew-Valley-Item-Finder/
[1]: https://www.maxchernoff.ca/atom.xml
[2]: https://github.com/whatwg/html/pull/11563#issuecomment-31909...
[3]: https://github.com/gucci-on-fleek/lua-widow-control/blob/852...
You are on some very very small elite team of web standards users then
Intentionally in a humourous way, yes
You cannot “convince decision-makers” with a webpage anyway. The goal of this one is to raise awareness on the topic, which is pretty much the only thing you can do with a mere webpage.
I don't think many do.
It's just that raising awareness is the first step (and likely the only one you'll ever see anyway, because for most topics you aren't in a position where convincing *you* in particular has any impact).
They should probably be called "decision-maders"
Why? Last time this came up the consensus was that libxstl was barely maintained and never intended to be used in a secure context and full of bugs.
I'm full in favour of removing such insecure features that barely anyone uses.
I think if the XSLT people really wanted to save it the best thing to do would have been to write a replacement in Rust. But good luck with that.
I think you can recognize that the burden of maintaining a proven security nightmare is annoying while simultaneously getting annoyed for them over-grabbing on this.
It's like removing JPEG support because libjpg is insecure!
I strongly encourage building a website entitled, something like keepXSLTAlive.tld to advocate for XSLT as the other guys did https://keepandroidopen.org/ for Android (https://news.ycombinator.com/item?id=45742488), or keep this current site (https://xslt.rip/) but update the UI a little bit to better reflect the protest vibe.
That said, I never used XSLT for anything, and I don’t see how is its support in browsers tied to RSS. (Sure you could render your page from your rss feed but that seems like a marginal use case to me)
This really is just a storm in a waterglass. Nothing like the hundreds or tens of thousands of flash and java applet based web pages that went defunct when we deprecated those technologies.
In the golden old days of 2018, browsers at least applied some styling https://evertpot.com/firefox-rss/
You can still manually apply styling using xslt https://www.cedricbonhomme.org/blog/index.xml
Unless I'm using XSLT without knowing, you can do this with the xml-stylesheet processing instruction
https://boehs.org/in/blog.xml
Random example: https://lepture.com/en/feed.xml
This is useful because feed URLs look the same as web page URLs, so users are inclined to click on them and open them in a web browser instead of an RSS reader. (Many users these days don't even know what an RSS reader is). The stylesheet allows them to view the feed in the browser, instead of just being shown the XML source code.
Imagine if you opened a direct link to a JPEG image and instead of the browser rendering it, you'd have to save it and open it in Photoshop locally. Wouldn't that be inconvenient?
Many browsers do support opening web-adjacent documents directly because it's convenient for users. Maybe not Microsoft Word documents, but PDF files are commonly supported.
Or can't you polyfill this / use a library to parse this?
In theory you could do the transformation client side, but then you'd still need the server to return a different document in the browser, even if it's just a stub for the client-side code, because XML files cannot execute Javascript on their own.
Another option is to install a browser extension but of course the majority of users will never do that, which minimizes the incentive for feed authors to include a stylesheet in the first place.
"Tell your friends and family about XSLT. Keep XSLT alive! Add XSLT to your website and weblog today before it is too late!"
- WSDL files that were used to describe Enterprise services on a bus. These were then stored and shared in the most convoluted way in a Sharepoint page <shudders>
- XSD definitions of our custom XML responses to be validated <grimace>
- XSLTs to allow us to manipulate and display XML from other services, just so it would display properly on Oracle Siebel CRM <heavy sweats>
Just kidding, Canvas is obsolete technology, this should obviously be done with WebGPU
Chrome supports it on Windows and macOS, Linux users need to explicitly enable it. Firefox has only released it for Windows users, support on other platforms is behind a feature flag. And you need iOS 26 / macOS Tahoe for support in Safari. On mobile the situation should be a bit better in theory, though in my experience mobile device GPU drivers are so terrible they can't even handle WebGL2 without huge problems.
Countless websites on Geocities and elsewhere looked just like that. MY page looked like that (but more edgy, with rotating neon skull gifs). All those silly GIFs were popular and there were sites you could find and download some for personal use.
>It's like how people remember the 80s as neon blue and pink when it was more of a brownish beige.
In North Platte or Yorkshire maybe. Otherwise plenty of neon blue and pink in the 80s. Starting from video game covers, arcades, neon being popular with bars and clubs, far more colorful clothing being popular, "Memphis" style graphic design, etc.
Gray backgrounds where also popular, with bright blue for unvisited links and purple for visited links. IIRC this was inspired by the default colors of Netscape Navigator 2.
https://geocities.restorativland.org/Area51/
> was more of a brownish beige.
Did you never watch MTV?
If there is no white 1x1 pixel that is stretched in an attempt to make something that resembles actual layout, or multiple weird tables, I always ask: are they even trying.
In all seriousness- they got quite a good run with xslt. Time to let it rest.
In the 90s, sites did kinda look like that.
What came later was the float layout hell- sorry, "solution".
I once got into a cab in NYC on Halloween and the driver said to me, hey, you really nailed that 80s hairstyle, thinking I had styled it for Halloween. I had to tell him dude, I’m from the 80s.
Bleed through from the 70s
Game sites and other "desperate-for-attention" sites have the animated gifs all over, scrolling or blinking text, dark background with bright multi-colored text with different font sizes and types and sound as well, looking pretty chaotic.
It's just direct browsing support for rendering using XSLT that's removed.
> For over a decade, Chrome has supported millions of organizations with more secure browsing – while pioneering a safer, more productive open web for all.
… and …
> Our commitment to Chromium and open philosophy to integration means Chrome works well with other parts of your tech stack, so you can continue building the enterprise ecosystem that works for you.
Per the current version of https://developer.chrome.com/docs/web-platform/deprecating-x..., by August 17, 2027, XSLT support is removed from Chrome Enterprise. That means even Chrome's enterprise-targeted, non-general-web browser is going to lose support for XSLT.
Surprisingly, the "hyperlinked documents" structure was universal enough to allow rudimentary interactive web applications like shops or reservation forms. The web became useful to commerce. At first, interactive functionality was achieved by what amounted to hacks: nav blocks repeated at every page, frames and iframes, synchronous form submissions. Of course, web participants pushed for more direct support for application building blocks, which included Javascript, client-side templates, and ultimately Shadow DOM and React.
XSLT is ultimately a client-side template language too (can be used at the server side just as well, of course). However, this is a template language for a previous era: non-interactive web of documents (and it excels at that). It has little use for the current era: web of interactive applications.
If people continue to use XML-supporting technology, these open standards will continue to thrive.
I'm sure this site will be supported eventually by the Ladybird Web browser - can't wait to switch to it next August.
When do we place this kind of “web nativist" art direction opposite to that of Project Firewall.
AFAIK the "google graveyard" is just for google products they have killed off.
When it comes to killing web technology, Google is mostly killing their own weird APIs that nobody ended up using or pruning away code that almost nobody uses according to their statistics.
It has RSS feeds for individual channels. It does not _support_ RSS in any meaningful way.
For $0? Probably not. For $40m/year, I bet you could create an entire company that just maintains and supports all these "abandoned" projects.
No sane commercial entity will dump even a cent into supporting an unused technology.
You have better luck pitching this idea to your senator to set up an agency for dead stuff - it will create tens or hundreds of jobs. And what's $40mm in the big picture?
[1] https://github.com/pizlonator/fil-c/tree/deluge/projects/lib...
As for money: Remind me what was Google's profit last year?
As for usage: XSLT is used on about 10x more sites [1] than Chrome-only non-standards like USB, WebTransport and others that Google has no trouble shoving into the browser
[1] Compare XSLT https://chromestatus.com/metrics/feature/timeline/popularity... with USB https://chromestatus.com/metrics/feature/timeline/popularity... or WebTransport: https://chromestatus.com/metrics/feature/timeline/popularity... or even MIDI (also supported by Firerox) https://chromestatus.com/metrics/feature/timeline/popularity...
Browsers should try things. But if after many years there is no adoption they should also retire them. This would be no different if the organization is charity or not.
Last i checked, google isn't a charity.
Besides, xkcd #2347 [1] is talking about precisely that situation - there is a shitload of very small FOSS libraries that underpin everything and yet, funding from the big dogs for whom even ten fulltime developer salaries would be a sneeze has historically lacked hard.
[1] https://xkcd.com/2347/
They moved everything into a wiki later.
EDIT: Oh, their developers' manual is still done like that: https://github.com/gentoo/devmanual into https://devmanual.gentoo.org/
What they can do is remove support for XSLT in Chrome and thus basically kill XSLT for websites. Which until now I didn't even know was supported and used.
XSLT can be used in many other areas as well, e.g. for XSL-FO [2]
[1] https://www.w3.org/TR/xslt-30/ [2] https://en.wikipedia.org/wiki/XSL_Formatting_Objects
I cannot tell if this is satire or not, very well done
Also: "the needs of users and authors (i.e. developers) should be treated as higher priority than those of implementors (i.e. browser vendors), yet the higher priority constituencies are at the mercy of the lower priority ones": https://dev.to/richharris/stay-alert-d
The google graveyard is for products Google has made. It's not for features that were unshipped. XSLT will not enter the Google graveyard for that reason.
>We must conclude Google hates XML & RSS!
Google reader was shutdown due to usage declining and lack of willingness for Google to continue investing resources into the product. It's not that Google hate XML and RSS. It's that end users and developers don't use XSLT and RSS enough to warrant investing into it.
>by killing [RSS] Google can control the media
The vast majority of people in the world do not get their news by RSS. It's never would have taken over the media complex. There are other surfaces for news like X which Google is not able to control. Google is not the only surface where news can surface.
> Google are now trying to control LEGISLATION. With these technologies removed what is stopping Google?
It is quite a reach to say that Google removing XSLT will give them control over government legislation. They are completely unrelated.
>How much did Google pay for this support?
Google is not paying for support. These browsers have essentially a revenue sharing agreements with the traffic they provide Google with. The payments are for the traffic to Google.
What the hell is Mozilla doing with that money? How useless are all those people?
(IIRC her salary increased something like 10 folds over the past 15 years or so)
Edit: It has jumped from $490k[1] to $6.25M[2] from 2009 to 2024.
Edit 2: by looking the figures up, I learned that she's gone at last, good riddance (though I highly doubt her successor is going to take a 12-fold pay cut)
[1]: https://static.mozilla.com/foundation/documents/mf-2009-irs-... page 8
[2]: https://assets.mozilla.net/annualreport/2024/b200-mozilla-fo... page 8 as well.
Say what you will about how this is technically allowed in open source, it is nothing short of morally despicable. A real https://xkcd.com/2347/ situation.
It would cost Google practically nothing to step up and fix all security issues, and continue maintenance if they wanted to. To say nothing of simply supporting the original maintainer financially.
But IMO the more important topic within this whole saga is that libxml2 maintenance will also end this year. Will we also see support for XML removed?
I think https://xkcd.com/1172/ is more fitting.
> But IMO the more important topic within this whole saga is that libxml2 maintenance will also end this year. Will we also see support for XML removed?
No, because xml has meaningful usage on the web. The situations are very different.
They're really not. If "meaningful usage" was a factor, Google should stop maintaining AMP, USB, WebTransport, etc.[1]
If security and maintenance are a concern, then they should definitely also remove XML, since libxml2 has the same issues as libxslt.
[1]: https://news.ycombinator.com/item?id=45873787