Chrome and Edge are removing XSLT: what breaks and what does not(doctor-seo.net) |
Chrome and Edge are removing XSLT: what breaks and what does not(doctor-seo.net) |
Chromium browser happenings are just nonsense.
<link rel="stylesheet"
href="style.css"
xmlns="http://www.w3.org/1999/xhtml" /> <script>document.currentScript.replaceWith(new Date().getFullYear())</script>
<svg onload="this.outerHTML=new Date().getFullYear()"/>
I lost any enthusiasm for XML after my experience with WDDX and XML-RPC, but as a foundation for HTML it was the best thing going. And maybe still is, given the absence of cross-toolchain contenders? Ditto for XSLT, at least if disregarding the choice to make the syntax homoiconic. In fact I circled back to XSLT long after it was clear it was a dead end. A good tool is a good tool, and the fact it remains so despite the wanton neglect only proves it.
Yeah and then we could have called it xhtml5. Too bad that does not exist. Oh wait https://html.spec.whatwg.org/multipage/xhtml.html
> But the anti-XML sentiment was explicit and spiteful.
No, xhtml was just a bad idea creating tons of problems and solving none.
It might actually work if reintroduced these days as long as we can consider many components to be valid documents.
Client-side XSLT was always pretty useless, but I dont see what HTML5 has to do with it?
The only real use case for client-side XSLT was for styling/layout back before CSS became widely supported. Improvements in CSS support made XSLT unnecessary.
I feel the same way about this that I do about removing Flash support: it's good that we're moving on to better things, but that doesn't help if there aren't better things to move on to.
What's the simple goto for making web based games that kids can mess around with? It was Flash, and now it's nothing. How do you set up an RSS feed to not just blast raw XML at the user? Soon it won't be XSLT any more, but I don't see a good replacement (even more annoying is the fact that browsers used to have features to handle RSS feeds by themselves, and XSLT was used to sidestep that problem, but now there's no more side to step).
Are any of these newer templating languages worth me switching?
I ignore every official statement about “support” and simply look at the horse's mouth: Microsoft hasn’t bothered to fix this in IIS, and likely never will.
It’s a dead product, “supported” only in a contractual sense, not a practical one.
(If you called support right now demanding fix for this, they’d tell you that it’s broken by design, have you tried moving to a recurring revenue service offering?)
Framesets. Not great UI though.
Alas, for laughably bad reasons we had to scrap all that for HTML5, Javascript and CSS; a stack so awful that most devs doing anything on the frontend immediately scramble to React, TypeScript, Tailwind, whatever it takes to avoid the underlying garbage.
A horrid state of affairs that will only get worse as time goes on.
It's a cool system, and I'll be bummed when I have to do this on the server. I already get warnings in the Firefox console about them soon deprecating XSLT support, so it's not just Chrome.
For now... This warning is logged in browser console and devtools for your page:
> XSLT will be removed from this web browser soon. See https://github.com/mozilla/standards-positions/issues/1287
Reducing attack surface.
LLMs make the problem easier because lowering the cost of fixing the vulnerabilities
alas that whole xml bubble moved into a business cloud, driven up there by complexity.
I think the biggest mistake of the consortia was to move from dsssl, the lisp, to xslt in unmaintainably arcane xml syntax, for a programming language that is.
does anyone here have some insight on why they went from dsssl to xslt? "because we can"?
I can't load this page.
Use css to style them instead?
Removing XSLT for a more secure browser(https://developer.chrome.com/docs/web-platform/deprecating-x...) 183 points|justin-reeves|1 year ago|337 comments https://news.ycombinator.com/item?id=45823059
Intent to Deprecate and Remove XSLT(https://groups.google.com/a/chromium.org/g/blink-dev/c/CxL4g...) 87 points|CharlesW|1 year ago|149 comments https://news.ycombinator.com/item?id=45779261
A look at XSLT 3.0 (2017)(https://www.xml.com/articles/2017/02/14/why-you-should-be-us...) 75 points|protomolecool|1 year ago|45 comments https://news.ycombinator.com/item?id=45026013
Show HN: I Built a XSLT Blog Framework(https://vgr.land/content/posts/20250821.xml) 116 points|vgr-land|1 year ago|68 comments https://news.ycombinator.com/item?id=45006098
Show HN: JavaScript-free (X)HTML Includes(https://github.com/Evidlo/xsl-website) 211 points|Evidlo|1 year ago|114 comments https://news.ycombinator.com/item?id=44988271
Should the web platform adopt XSLT 3.0?(https://github.com/whatwg/html/issues/11578) 133 points|protomolecool|1 year ago|108 comments https://news.ycombinator.com/item?id=44987552
XSLT removal will break multiple government and regulatory sites(https://github.com/whatwg/html/issues/11582) 160 points|colejohnson66|1 year ago|146 comments https://news.ycombinator.com/item?id=44987346
Google did not unilaterally decide to kill XSLT(https://meyerweb.com/eric/thoughts/2025/08/22/no-google-did-...) 103 points|bkardell|1 year ago|128 comments https://news.ycombinator.com/item?id=44987239
"Remove mentions of XSLT from the html spec"(https://github.com/whatwg/html/pull/11563) 388 points|troupo|1 year ago|535 comments https://news.ycombinator.com/item?id=44952185
Should we remove XSLT from the web platform?(https://github.com/whatwg/html/issues/11523) 73 points|edent|1 year ago|96 comments https://news.ycombinator.com/item?id=44909599
XSLT: A Precision Tool for the Future of Structured Transformation(https://www.xml.com/articles/2025/07/19/xslt-precision-tool-...) 58 points|protomolecool|1 year ago|59 comments https://news.ycombinator.com/item?id=44633384
XSLT – Native, zero-config build system for the Web(https://github.com/pacocoursey/xslt) 392 points|_kush|1 year ago|325 comments https://news.ycombinator.com/item?id=44393817
Intent to Unship: XSLT(https://groups.google.com/a/mozilla.org/g/dev-platform/c/ZRy...) 5 points|tambourine_man|2 months ago|1 comments
(this list is incomplete. but we just had a power outage (including getting zapped, so i am submitting this now to not lose it)
> For functionality and compatibility reasons, Microsoft Edge adopts nearly all of the Chromium project's changes to the web platform. However, Microsoft retains full control of the Microsoft Edge browser and may defer or reject changes.
Removed features don't always follow the same timelines either (and not just because of a lag in syncing to upstream Chromium).
All downstream Chrome clones will follow papa Google eventually, as they won't keep stuff working on their own, cherry picking upstream.
There used to be pictionary online, web-based, which used Shockwave. iSketch I think it was called. There's probably alternatives these days, but I wouldn't know them. And regarding the Roblox issue: yes, some **heads were drawing ** pictures. Screw those people. This is what you get when you interact with total strangers. It brings the worst in people. How to solve that? Play with strangers-lite. Play games with people who are local to you. Yes, issues may ensue, but at the very least you can contact each other as parents.
Pico-8, Picotron, Tic-80, GameMaker, Godot all have simple web exporter.
Which is also a pedophile safe-haven (as proven by Chris Hansen and associates) so I wouldn't let my kids use it.
Web games? Is that like Roblox on your school chromebook?
I think Roblox is the game design space for kids these days (though I would recommend parents to protect their kids from that game until they actually stop the paedophiles).
If you do want to target the browser, the sky is the limit. WASM has made any desktop game design platform compatible with browsers. Thanks to Ruffle, you can build flash games and they will even work on your iPhone, despite Steve Jobs' personal vendetta against Adobe's CEO.
RSS can have CSS stylesheets if you intentionally break the content type, so you can try your hand at making RSS feeds pretty. However, realistically, the kids aren't using RSS anymore. Browsers don't really support them, clients are run by stubborn people like me refusing to give up on what could have been, and RSS sources are dying out one by one.
Of course, you'd need to get over the lunacy of loading a full DOM transformation library into the browser DOM.
but that just aside. the last time this was discussed a year ago i actually tried to find a working solution to load xslt through javascript and could not find any.
i only got as far as verifying that js can be loaded from an xml mimetype. xslt implementations in js also exist. what's missing is the wrapper code to load the xslt library and run it over the xml and xslt files.
perhaps now with this seriously being needed by a few sites someone will have the time to get this working.
Step 1: Gain browser monopoly
Step 2: Generate fake security scare
Step 3: Gaslight everyone that only way to mitigate is to get rid of it completely like Flash.
Step 3a (corollary): There isn't anyone available that can fix the bugs because we spent all resources on UI/UX experimentation
The XHTML/XML/XSLT tooling was bad, and XSLT was hard to reason about. That meant that amateurs had no way to learn it, and those amateurs went to school and became the workforce.
The web became a winner because it was easy to get something working. And then Google made it a mission to make great developer tools in everyone's hands for free.
I think in 2026 we could build the tooling around a better experience, but it would require thinking about the developer experience first.
But, as a stack, the XML/XSL/XPath/etc combination was weak because XSLT was hard to comprehend and never updated. No browser supports XSLT 2 or 3; they froze support with 1. XSLT 2 was 2007, a year before HTML 5 was a thing, yet it never got picked up by browsers. Javascript was just easier to understand than XSLT. Development of XHTML was also glacial, and people wanted new tags, especially for video.
Turns out that tasks easily done by programming languages are best done by programming languages. Who knew?
JSON allowing frontends and backends to communicate in a way analogous to the "smart endpoints, dumb pipes" model for networking saved the Web. The XML adherents wanted the inverted model, which was always insanely difficult to reason about and led to entirely XML-specific security threats.
It would of been glorious having any programming language usable within the browser. Craft your own features rather than what's given to you now. It's only now that we're gaining the ability to use other languages via WASM.
Tcl was a contender to Javascript in the browser but Javascript won because it didn't require a plugin. And as Tcl never became the browser's default scripting environment juxtaposition Flash eventually lost because the browser platform evolved to make its proprietary plug-in unnecessary
<svg onload="this.replaceWith(new Date().getFullYear())"/>Ripping out the least common and most dangerous parts of XML parsing makes a lot of sense if you want to keep using the unmaintained library without actually having to put in the work to maintain it.
The libxml2 maintainer forked the repo and released it as AGPL, a license which does to Google what garlic does to vampires, unless you pay up.
I suppose the important part was that jsx needed to be compiled, which means it couldn't introduce any new security issues…
It would be conceptually nice to me to use wherever the puck is going in terms of a templating language that can work in the browser also.
How is that different from sites using Java applets, which were pretty much universally loathed when we had them?
> ...Tcl...
How is Tcl better than Javascript?
> ...Flash...
I'm not sure I really understand what point you're making here. Are you saying that the native browser APIs evolving to make Flash obsolete is a bad thing? If I'm reading you correctly you're saying that websites being free to use their own proprietary plugins is somehow better than HTML5/Javascript?
What shows is that the old stigma of programming held everything back and most of that was Oracle. Still the same today with Google, Facebook and so.
Java Applets were phenomenal and way ahead of their time. It just got caught up in the swamp and broadband wasn't available to enable the technology to flourish. I never loathed them, I loved them. 3D graphics in the browser; we still struggle with that today.
Everything back then was a pain but is anything easier now? Tried using Windows 11? Even Linux has lost its charm.
WebGL isn't mature enough and Apple is cutting OpenGL from their OS. Where is the HTML5 equivalent of Flash? I have yet to see it other than Ruffle.
If the plugins were adopted, and browsers were adaptable to the plugins that would decuffed the browser rather than the current trend of the internet where the schematics are now vastly dominated and ruled by Google & co cuffing the browser and any other future browser for that matter in to nose dive spiral.
Firefox is the only major alternative and is only floundering because of Google.
If plugins were the browser from the get-go then any shift of plugins could rock the boat.
> Are you saying that the native browser APIs evolving to make Flash obsolete is a bad thing?
Pretty much yes. HTML 5 was Googles push for dominance, JavaScript was too. Not sure if intentionally but they sure at it now. "Don't be evil" I seem to recall.
Without it's merits, it would too have it's own problems but I would wager that the internet ecosystem would be broader and more united than what it is now.
Extensions don't count as it's difficult to use another programming language in the browser unless it's tied to WASM or built in. And even then you're further restricted where features are torn out.
Adblockering in chrome et cetera. 1999.
So an XML document would be parsed and processed by the XML engine, trigger XSLT processor, which would then trigger again the XML processor again and the HTML processor.
So XSLT processing for XML/XHTML is deeply embedded. Dropping it removes a lot of corner cases that AI is good at exploiting.
If you make a mistake and use incorrect syntax in html, the browser will do its best to recover. In xhtml, it would just completely fail. Which approach is better is debatable.
Not that it's exactly a shock they don't care about XSLT either (how many do these does) but carrying a patch set for different functionality against upstream is something individual users on HN (including myself) do when they like, let alone entire companies shipping browser products.
Everyone likes to have their private branch, until they discover how many hours they need to keep up with upstream, especially if upstream doesn't care one iota about them.
I've been maintaining my patcheset to it for 5 years as one dude who's $dayjob is not coding. It just got a lot easier with LLMs recently as well. And of course companies have been carrying larger much larger changesets than I have been for many years.
Hell, even Firefox has multiple forks which deviated to keep old engines/UIs/features for many years and it has a tiny market share/little to no 3rd party company backed spins in comparison.
But it seems like you don't have much interest in all of this, just repeating that an upstream source is involved therefore you believe there can be no differences worth noting or discussing. Your loss, not the title's.
Well an XHTML parser (and serializer) is a lot simpler, which is a pretty meaningful problem to solve.
What problems does xhtml create?
Perhaps, but a combined html and xhtml parser is more complex than just a html parser. Since html already is entrenched, xhtml would be in addition to html, not instead of.
HTML has special rules depending on the tag's type, ie a bunch of them are just written (<img>) and the parser doesn't even really want to see a matching closing tag, or tags like <script> that has a special mode that stops being a HTML parser up until </script> is found. (1)
A HTML parser can become a XML parser by disabling a bunch of special-features and supporting self-closing tags (depending on XML level).
A XML parser needs a ton of "hacks" to become a HTML parser.
Also browsers needs an XML parser anyhow to support svg that's an xml-based format, also the DOM spec is written to support namespaces's like XML.
XSLT did complicate things, and most importantly it seems many relied on that one old implementation written in the 90s that was a swiss-cheese when it came to security concerns that nobody wanted to spend money on maintaining.
(1): https://html.spec.whatwg.org/multipage/parsing.html#script-d...
But it wasn't something that could get introduced later, after all the broken content that already existed.
The problem is that XSLT has so few users that the browser writers don't want to waste any more time on it. Those few people who wrote their site around it will have to either rewrite it to use something else or add some third party webassembly implementation themselves.
You're half right.
Yes, Jobs killed Flash. But he did it because Flash on mobile was a battery killer. And when the original iPhone came out (one of which I still have), battery technology wasn't as advanced as it is now.
Before I got my wife's hand-me-down iPhone, I had one of the few mobile phones that supported Flash. On the few occasions when I used the web browser, I lived in fear that I'd land on a web site that was using Flash because I knew it would tear through the phone's battery in less than 10 minutes.
Ever notice that the people on HN who pine for the good-ol'-days of Flash only remember games? Never the Flash ads and intrusive videos.
Jobs did the future a favor.
I wouldn't say poor. Adobe had its own creative-software empire to up-keep. Photoshop, Illustrator, After Effects, and its web-authoring products gave it enormous influence over creative professionals. Macromedia's Dreamweaver and Flash were serious competitors in web design and interactive media. Adobe needed the missing monopoly cards; Flash, Fireworks and Dreamweaver were them.
Flash was security ridden yes, Flash required a plugin, yes; I don't think supported AppleOS at the time. These could of all been solved but I would agree that to refactor the software would of been an expensive take.
Jobs + HTML5, WebGL, JS all had entered the ring and finished the blow.
I miss it. Growing up with the internet in 2003, 2010's was the end of the wild world web. 2020's was the era of walled gardens for which we now have LLM's for the theme park and we're now entering 2030 where the internet is on fire with creativity now wrung between Yes Ai and No Ai.
Domain name:
lordsephiroth.co.uk
Relevant dates:
Registered on: 18-Nov-2003
Audio however was a crapshoot for years, especially for games.
Even basic WebAudio took until 2015, and the final piece to match Flash being AudioWorklet was only first available in 2018(Chrome) and took until April _2021_ land in Safari.
So before 2021 you needed to either write your own abstractions to support multiple API's with different execution models with so-so capabilties to be somewhat on-par with what Flash provided or even for years resort to simpler solutions (ie just samples).
Congratulation on reinventing HTML.
XHTML5 sort of gets us there, but parsing in standard HTML5 mode still won't do the right thing with eg <b />
But I don’t think the ambiguous html parsing made it easier. If anything it made it more difficult since you had to test in multiple browsers. Eg a table which was not properly closed would render in IE but not render in Netscape.
But then, I've always preferred strongly typed over stringly typed.
The reason HTML and markdown are more widely adopted than latex is because the former are more forgiving.
Even if this was true it would still increase complexity to have two parsing modes compared to just a html parser.
Whether that kind of backwards-incompatible breakage would ever become acceptable is a completely different story. But we ditched Flash, ActiveX, Silverlight, and Java applets, so who knows what could have been!
The only good thing about flash were the authoring tool but it only appealed to content (games, websites) producers, never the users.
Is that good accessibility ?
Once there was a standardized interpretation for malformed html, there was a chance that we could have treated that as a transparent conversion layer to xhtml. That isn't how WHATWG went, however.