Comment by omgtehlion
9 days ago
> so it’s hard to make the case for keeping it.
How about “not breaking stuff” which can not be upgraded? Like old sites/services without active maintainers but still useful. Or hardware appliances that still work, but will not get firmware update ever. Let alone rss feeds, brought up multiple times in the linked thread.
Looks like builtin polyfill (similar to pdfjs in FF) would do. But google seems to be reluctant doing it.
When’s a reasonable time to pull the plug on out of fashion legacy stuff? Things can’t always remain backwards compatible forever. I think the places this is still in use can build contingencies where required
Why can’t things remain backwards compatible forever? In the 35 years that the Web has existed, browsers have come pretty damn close to meeting that standard. The one huge exception is the removal of plugin support around 2015, and the concomitant death of Flash and Java applets. There were also some major browser-specific APIs that got killed off, like ActiveX and NaCl. But when it comes to standardized, browser-native functionality… very little has ever been removed. I would prefer it if I could say the same thing in another 35 years.
> Why can’t things remain backwards compatible forever?
I already said why:
> The complexity and attack surface area isn’t justified by its utility, so it’s hard to make the case for keeping it.
If you read the GitHub issue that this submission links to, the issue points out security vulnerabilities and links to:
> Although XSLT in web browsers has been a known attack surface for some time, there are still plenty of bugs to be found in it, when viewing it through the lens of modern vulnerability discovery techniques. In this presentation, we will talk about how we found multiple vulnerabilities in XSLT implementations across all major web browsers. We will showcase vulnerabilities that remained undiscovered for 20+ years, difficult to fix bug classes with many variants as well as instances of less well-known bug classes that break memory safety in unexpected ways. We will show a working exploit against at least one web browser using these bugs.
— https://www.offensivecon.org/speakers/2025/ivan-fratric.html
1 reply →
Things can remain backwards compatible forever. That is what any good standard does. Web standards and much else in software is sadly a complete mess where too few care about all the downsides of instability.
I am a bit worried because for many years I used plugins like SinglePage to save web pages as HTML. That is not exactly future-safe since every relase of Chromium or Firefox has a list of things that were deprecated (and a list of things that changed, that might or might not break rendering of old pages). Old saved pages will eventually begin to degrade and some might eventually be unreadable without having to mess with virtual machines to run old browsers.
> Things can remain backwards compatible forever.
This is exactly the attitude that has left us with only three complete extant implementations of the web, two of which are controlled by an ad company.
Indeed, to me it seems that at some point, you either have to
a) freeze the standard
b) drop old stuff
c) accept that there is no standard
and with the web as a whole, we are firmly headed towards option c). So I find the short-sightedness of all people pushing back against this proposal unfortunate.
(Also note that dropping a barely-used Turing-complete language from the web is not comparable to removing deprecated HTML elements. The latter typically requires just a few lines of CSS in the UA style sheet, so I doubt anybody is considering doing that.)
5 replies →
If you want to build a stable platform: never.
Absolute stability in that manner is nearly never the goal. Plenty of web standards have been deprecated. They gently push things in a direction and cull what is seen as low value or high risk.
I'm not advocating for or against this specific item, just saying we shouldn't perpetually add and bloat future maintenance demands just because we want to support every single thing that's ever been built. We should be able to remove/delete/deprecate in a way that allows reasonable notice to those that could be effected. I'm certainly not advocating for sweeping breaking changes like may be found in some web frameworks, etc. We should expect that browsers move slowly. But there still needs to be some process for culling things IMO.
The web platform has repeatedly removed features like this in the past, and it’s the most stable platform in the history of the computer industry.
Lets remind ourselves that thanks to Google we also did not got WebGL 2.0 Compute, it was too much for Chrome team to spend their resources between WebGL 2.0 Compute and WebGPU.
How great that five years later WebGPU is something we can rely on in portable way. /s