When I first learned that XSLT was going away, I got curious how to achieve the same thing in JS (client-side templating that happens during page load, without any "flash of content"). It turns out there's a very nice way to do it, by using inline scripts that append elements next to document.currentScript. Lean Rada wrote about it here: https://leanrada.com/notes/inline-rendering-currentscript/ and I wrote about it as well: https://vladimirslepnev.me/write
Yeah. I want to note quickly that the currentScript method can do a bit more than that. For example, the page head can include script.js with the code for rendering the site shared header and footer. Then in the page body you can have inline scripts using the currentScript trick to add the header and footer in place, kinda like including shared templates. And it runs during page load, before even onLoad, so the page renders with header and footer straight away.
Shame back in the XHTML days XSLT was a spec that could have made website modularity so much cleaner. I once created an early website creation tool that merged separate components using XSLT it was really powerful in the days before javascript was usable without jQuery. However XHTML was dropped in favor of HTML5 and XSLT was pretty much useless after that. Its done well to survive this long I presume it was mainly kept to style XML files.
HTML5 could have taken the extra step of defining a canonical XML or XML-compatible DOM encoding, or at least encouraged it. But the anti-XML sentiment was explicit and spiteful. Still, popular XSLT processors are built to consume and even produce HTML5, I'm just not sure how thorough those capabilities are or whether they're based on any formal or informal standards. (Maybe the W3C has/had something like that, as part of it's attempts to rollup HTML5 snapshots into versioned standards?)
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.
That is one, but not the only thing. Non-xml html is just generally more forgiving.
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.
> Well an XHTML parser (and serializer) is a lot simpler
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.
XML/XHTML is a fairly strict language syntax wise compared to HTML, tags are either explicitly self-closing i.e. <img/> or terminated with a matching closing-tag, no exceptions.
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.
The idea would be to eventually deprecate "legacy" html, of course.
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!
Who would want to use a browser which couldn’t render html? Even if a better format arrived, there are millions of already existing html pages which people would want to be able to read.
All the problems of XML, such as the billion laughs attack, and reading local files as DTDs. It should have been XML-compatible strict parsing without pulling in all of XML's complexity that only hackers ever use.
With the benefit of hindsight, if the web had been that way from the beginning, I think we would have been better off. The moment you tested your content in any browser, you'd immediately see if it was broken.
But it wasn't something that could get introduced later, after all the broken content that already existed.
With all respect - the opposite is true. The web succeeded because HTML and HTTP are easy standards easily writable by humans with text editors. HTML was writable by non-programmers.
The low barrier to authoring was very important. No tools needed except notepad and a browser. Syntax easy to understand and write by hand.
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.
Forgiving is very helpful in enticing those whose content you'd like to parse to start producing content. There's no use in having the worlds greatest pipeline if nothing is being put in and moved through. See the tragedy of the death of flash and "surely someone will come along and make a great frictionless editor for canvas and webgl", only for all the creative energy ending up being sucked up and monetised by roblox, leaving the world worse off.
Until html5 it wasn't forgiving - it was ambiguous. Different browsers could (and did) interpret different malformed html in different ways.
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.
I see what you are saying, but I don't think catering to sloppy growth over correctness needs to happen at the document level. The unrigorous shouldn't be given access at this level, you can still make php and myspace at other layers and using other abstractions. I think sloppy growth has its place, but it also needs the right level.
Flash dying is a great victory for Open Source browsers. I don't miss a thing about that world; as an authoring tool, it was hugely overused, for things it should never have been used for, like literally anything other than games.
That's not obviously so. The adoption of JS wasn't particularly hindered by the fact that users have to match their brackets and generally avoid syntax errors.
i think xhtml happened before the wider world of web devs were ready for it. Component based architectures took longer to be adopted than I certainly expected.
It might actually work if reintroduced these days as long as we can consider many components to be valid documents.
> XHTML was dropped in favor of HTML5 and XSLT was pretty much useless after that
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.
Yeah, XSLT 1.0 has some really obvious missteps, so much so that to my knowledge basically nobody just implements XSLT 1.0. What they actually support is (most of) XSLT 1.0 plus a handful of EXSLT extensions (which are completely unofficial and not part of any XSLT spec, by the way). In my opinion the EXSLT stuff is the bare minimum needed to make XSLT 1.0 at least a passable language. Meanwhile, the XSLT spec evolved into 2.0 and 3.0, which as far as I'm aware, even to this day, has no complete open-source implementation.
At least Firefox will still have it, although with Mozilla being the way that it is, I wouldn't be surprised if they follow suit.
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).
I've been making Easel (https://easel.games) for four years so far! A place for teenagers to make multiplayer web games and share them with each other. Still a long way to go but this is the goal!
Why does it have to be web-based? Discoverability? There's Minecraft and Lego. I discovered the CLI of MSDOS when I was a kid. It was a world to explore for sure.
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.
>What's the simple goto for making web based games that kids can mess around with?
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.
I am still using XSLT. I have been using it for 26 years. I generate XML documents on the backend and turn them into HTML for various reports. XSLT has a lot of features and power that newer templating languages lack.
Are any of these newer templating languages worth me switching?
Semi-serious suggestion: wrap the files in an (X)HTML page that links to a Javascript file loading a full XML parser compiled to WebAssembly, which then does the full transformation live, in-browser. You wouldn't need to change your templates or your generation logic much if you structure the surrounding skeleton right!
Of course, you'd need to get over the lunacy of loading a full DOM transformation library into the browser DOM.
you also need to get over the fact that this doesn't work while disabling javascript, while built in xslt doesn't need javascript. on the other hand though it's not a big loss given that xslt isn't any safer. anyone who turns off javascript probably ought to have turned of xslt as well.
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.
My thought wasn't so much "do XSLT parsing in Javascript" and more "compile a C program to apply XSLT transformations using emscriptem and embed that". You can probably throw that concept into any slop machine and get a cursed compatibility library out of it.
Their comment isn’t clear if they’re doing the transform on the server before piping it down as HTML, which some implementations have done over the years as it provided access to newer XSLT features that browsers stagnated on.
In an XML document a "processing instruction" can trigger the XSLT processor to transform the document in another format.
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.
The cool thing with a wasm-based xslt implementation is there is no need for the browser vendors to gate-keep it. Just use the implementation you prefer.
Except XSLT dates back to the late 90s. WASM was not even a glint in the eyes of its creators. Mozilla even used XSLT internally to drive the GUI for their browser iirc. I think based on that there is a good reason it was incorporated into browsers.
If they were going to implement it themselves it would be unnecessary to faff around with webassembly. They could just keep the native code implementation that they already have.
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.
XSLT is not going away, it is only in-browser XSLT which is removed. If you are happy with XSLT there is no need to abandon it. Just perform the transformation on the backend.
Flash went away because Steve Jobs made an impassioned plea to find a better way and follow their humble browser which only had single digit percentages of marketshare at the time.
Even for enthusiastic Android vendors who saw it as a differentiating feature from iPhone, Flash still took three years from the iPhone launch to have its first release. Adobe was really in poor shape to port Flash to a new platform. Waiting for them as a vendor to bump their proprietary platform vs integrating support for the features into the browser would have cost years for mobile adoption.
> Adobe was really in poor shape to port Flash to a new platform
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
My first ever domain name, registered with my pocket money at the age of 13. Hopefully 2040 should bring world peace. One would hope.
Flash went away because Steve Jobs made an impassioned plea to find a better way and follow their humble browser which only had single digit percentages of marketshare at the time.
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.
Yes and no, canvas was fine for replacing flash, and JS performance was good enough quickly.
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).
Nobody uses XSLT and nobody maintains XSLT. You're free to support it in your own browser but it's not reasonable to expect Mozilla to support XSLT any more than it supports VRML.
I find it baffling that anyone still cares. RSS nerds like RSS because it can be consumed by software that displays it however the user wants. XSLT pages just function as normal webpages, there is no consuming it programatically because XSLT is the view language. The underlying XML/RSS is what you wanted, not the hodgepodged together crap on top of it.
Feels crazy to me that to date, this was the only widely supported way to pull in shared bits of HTML like headers, navigation, and footers without anything dynamic on either end. It’s such a basic and common use case to be so poorly covered.
i just got flashbacks to a past life where i handcrafted XSLT to pre-render output from a service as HTML server side. Of course the front end was running some asp.net version and Microsoft flavored XSLT had lots of quirks.
Good riddance. XSLT and EJB marked the dark ages of software development. For a half decade nothing made sense and programmers and management were going along with the charade until everyone collectively realized it was complete garbage and just stopped using it. I remember replacing an XSLT/EJB system that processed one order per minute with a C++ system written in a week that processed 10,000/minute. A team of a dozen programmers had been working on that XSLT disaster for years.
In retrospect I really think it was a deliberate plan by IBM and Sun to turn software development into such an awful, impenetrable quagmire that they would be the only ones who could build and maintain any system.
More than ten years ago a coworker wrote a tool to generate Swift from iOS storyboards, to pass data through segues and give us typed access to identifiers. First version of it used XSLT to transform the storyboard XML. A powerful, if niche technology.
I encode all the text, localization, provenance, pedagogical, and forced alignment data for my Latin language audiobook chapters[0] as TEI-XML. When I fetch a document out BaseX, I have an XQM module that wraps the document in a number of XML processing instructions (PIs), one being a pointer to the reader XSLT 1.0 stylesheet which does all the HTML rendering client-side.
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.
I'd consider getting your workflow running in wasm (in wasmtime on the server) and then you can migrate the same workflow to the client using the same wasm module. Nearly all LLVM based compilers can compile to wasm (WebAssembly).
Chrome is putting a big red button on any site using XSLT.
I'm for my RSS feed. It's ugly, I will have to move to another solution. It works fine on Firefox.
there was a wonderful wisiwyg xml editor that rendered the FO life from your xml using your xslt. syntext serna. they even open sources it in their hopes it would see some pick up.
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"?
In the age of LLMs I would expect that legacy code bet carried indefinitely. The LLMs will have it indefinitely in their training data, and with code "cheap" to produce now, what are the good reasons for dropping legacy code?
This mindset is why programs only ever seem to bloat more by the day. Code for a given functionality could cost 0 development maintenance and still not be worth including going forward.
Your presumption is that code is "cheap" because of LLMs. I am challenging the premise. Maintaining code in production for a product used by billions of people is not cheap, with or without LLMs. Perhaps your shitty disposable code that you write for yourself and never subject anyone else to is cheap, but if your code is in a large, complex codebase and has to actually work for everyone who uses it, not so much.
LLMs are only getting better and more competent, especially for code well-covered by tests. On such codebases it's definitely cheaper to maintain code with a LLM than by humans alone. I presume then that the XSLT implementation in Chrome is not well-tested.
I think that the issue is not the XSLT implementation (that could be contained), but its deep intégration in the XML stack which is part of web pages processing. Think about XML "processing instructions".
Browsers have been relying on libxml2 for ages. Nobody bothered to help libxml2 much, let alone pay for maintenance, but treated it like a security critical component so let their CVE teams loose on unsuspecting volunteers. libxml2 burned out, the project got abandoned, and now Google and everyone else are sweating about what to do with their XML parsing code.
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.
It is not because of specific known vulnerabilities. It is because it is old legacy unmaintained code which is rarely used and which has a large attack surface.
XSLT is rarely used, a significant attack surface, and the upstream libraries are riddled with vulnerabilities. LLMs make the problem worse by lowering the cost of finding new vulnerabilities.
The breakage that sticks out to me is that IIS in Windows Server outputs some reports as XML+XSLT and these have become nigh unusable for years now.
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?)
The article says as much in the opening. It also includes a statement from Microsoft noting they do not intend to carry this forward separately, with a salient comment in one of the Microsoft page citations:
> 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).
Edge has a separate feature set and deprecation cycle on top of Chromium hence it doesn't make sense to name it separately? I'm not sure I quite follow that logic.
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.
Chromium, not Chrome. Chrome itself is a proprietary browser with many additional features on top of Chromimum other Chromium browsers have to reimplement just to work to a basic level, such as playing DRM content or profile syncing, which might be adding to the confusion here. E.g. when Edge pulls in its DRM method it actually gets more support from certain services than what Google does with what Chrome pulls in.
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.
It is wild to look back at XHTML and see that the W3C were entirely correct about XML. They envisaged a world of schemas, client side templating, custom elements, dynamic forms, the works.
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.
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.
You could do some awesome things with XML/XSL. My favorite was RSS feeds or OPML collections of RSS feeds (both flavors of XML) calling an XSL transformation when viewed in a web browser instead of mined by computers for data; same with TEI files, although that was a bit more arcane. The idea was that you'd have one data file for machine use and a way to present that data to humans as a web page.
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.
> 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.
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.
I can't help but agree, and sometimes I think about the alternate version of the web where XML realized its full potential as the dominant technology. The obvious problem with XML is that the syntax is so verbose and redundant that it's only barely human-writable, but this is 100% a solvable problem.
Is that really accurate? In a world where HTML5 never happened, how would XHTML/XSLT solve the same problems that modern front-end Javascript frameworks do (interactive data-driven websites)? I say this as someone who thinks XSLT is a really useful technology, and doesn't want it to be deprecated.
That browser world would of been glorious without HTML5. Where Javascript wasn't in the browser and Tcl was (it was a contender); we would be working with plugin based browsers rather than built-in to the hood. That in turn would enable you to process incoming documents based in XSLT however you desired.
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
> ...we would be working with plugin based browsers rather than built-in to the hood...
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?
You can't claim the JavaScript technologies of now and apply them to Tcl of the 90's. Tcl is an ace language and well suited for the web.
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.
XSLT however has an absurdly steep learning curve, on top of it (like XML) being utterly verbose. There is a reason neither technology ever caught on outside of big enterprise or government projects.
Bless the Internet Archive for basically hosting a second copy of the internet with sufficient bandwidth to serve whatever is currently down, while this single site didn't survive the traffic it got individually
When I first learned that XSLT was going away, I got curious how to achieve the same thing in JS (client-side templating that happens during page load, without any "flash of content"). It turns out there's a very nice way to do it, by using inline scripts that append elements next to document.currentScript. Lean Rada wrote about it here: https://leanrada.com/notes/inline-rendering-currentscript/ and I wrote about it as well: https://vladimirslepnev.me/write
You can also style XML documents with CSS, like this:
Yeah. I want to note quickly that the currentScript method can do a bit more than that. For example, the page head can include script.js with the code for rendering the site shared header and footer. Then in the page body you can have inline scripts using the currentScript trick to add the header and footer in place, kinda like including shared templates. And it runs during page load, before even onLoad, so the page renders with header and footer straight away.
Agreed! And you aren't even restricted to currentScript; you can run arbitrary JS in an XML document, reformatting it however you like.
That Lean Rada article is really fun!
Instead of:
How about: Not as pretty, and you'd have to escape all the quotes, but still pretty usable.Hm, does document.write("...") still exist?
Does the old stuff ever go away?
Apparently XSLT does.
Good point. So did flash and java applets. Good riddance!
That won't work with trusted types enabled.
Well this works too:
Shame back in the XHTML days XSLT was a spec that could have made website modularity so much cleaner. I once created an early website creation tool that merged separate components using XSLT it was really powerful in the days before javascript was usable without jQuery. However XHTML was dropped in favor of HTML5 and XSLT was pretty much useless after that. Its done well to survive this long I presume it was mainly kept to style XML files.
HTML5 could have taken the extra step of defining a canonical XML or XML-compatible DOM encoding, or at least encouraged it. But the anti-XML sentiment was explicit and spiteful. Still, popular XSLT processors are built to consume and even produce HTML5, I'm just not sure how thorough those capabilities are or whether they're based on any formal or informal standards. (Maybe the W3C has/had something like that, as part of it's attempts to rollup HTML5 snapshots into versioned standards?)
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.
I'm curious, what exactly in the DOM is not XML-compatible?
From long-lost memory, I think it's implicitly closed tags (e.g. img).
That is one, but not the only thing. Non-xml html is just generally more forgiving.
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.
XML can handle implicitly closed tags, they call them "empty" in the spec here:
https://www.w3.org/TR/xml/#sec-starttags
Empty tags in XML are not implicitly closed. They require the explicit /.
XML can handle <img /> but not <img> followed by tagsoup (like HTML handles).
One thing I can think of is tag names being upper case in HTML and lower case in XHTML in the DOM.
> HTML5 could have taken the extra step of defining a canonical XML or XML-compatible DOM encoding, or at least encouraged 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.
> xhtml was just a bad idea creating tons of problems and solving none.
Well an XHTML parser (and serializer) is a lot simpler, which is a pretty meaningful problem to solve.
What problems does xhtml create?
> Well an XHTML parser (and serializer) is a lot simpler
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.
XML/XHTML is a fairly strict language syntax wise compared to HTML, tags are either explicitly self-closing i.e. <img/> or terminated with a matching closing-tag, no exceptions.
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...
> A HTML parser can become a XML parser by disabling a bunch of special-features
Even if this was true it would still increase complexity to have two parsing modes compared to just a html parser.
The idea would be to eventually deprecate "legacy" html, of course.
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!
Who would want to use a browser which couldn’t render html? Even if a better format arrived, there are millions of already existing html pages which people would want to be able to read.
All the problems of XML, such as the billion laughs attack, and reading local files as DTDs. It should have been XML-compatible strict parsing without pulling in all of XML's complexity that only hackers ever use.
The main one is that even a slightly broken XHTML document will fail to render. HTML is much more forgiving.
With the benefit of hindsight, if the web had been that way from the beginning, I think we would have been better off. The moment you tested your content in any browser, you'd immediately see if it was broken.
But it wasn't something that could get introduced later, after all the broken content that already existed.
With all respect - the opposite is true. The web succeeded because HTML and HTTP are easy standards easily writable by humans with text editors. HTML was writable by non-programmers.
The low barrier to authoring was very important. No tools needed except notepad and a browser. Syntax easy to understand and write by hand.
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.
I don't think "parsed strictly" makes something hard; on the contrary, I think it's helpful to make something easy. Clear feedback, easy to test.
But then, I've always preferred strongly typed over stringly typed.
This imagines HTML as code and not markup.
The reason HTML and markdown are more widely adopted than latex is because the former are more forgiving.
I am thinking of it as markup. I stand by the point: I think "forgiving" is not a feature in parsing; it's a bug.
Forgiving is very helpful in enticing those whose content you'd like to parse to start producing content. There's no use in having the worlds greatest pipeline if nothing is being put in and moved through. See the tragedy of the death of flash and "surely someone will come along and make a great frictionless editor for canvas and webgl", only for all the creative energy ending up being sucked up and monetised by roblox, leaving the world worse off.
Until html5 it wasn't forgiving - it was ambiguous. Different browsers could (and did) interpret different malformed html in different ways.
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.
I see what you are saying, but I don't think catering to sloppy growth over correctness needs to happen at the document level. The unrigorous shouldn't be given access at this level, you can still make php and myspace at other layers and using other abstractions. I think sloppy growth has its place, but it also needs the right level.
Flash dying is a great victory for Open Source browsers. I don't miss a thing about that world; as an authoring tool, it was hugely overused, for things it should never have been used for, like literally anything other than games.
The reason HTML is more widely used than latex is obviously because browsers support it natively.
That's not obviously so. The adoption of JS wasn't particularly hindered by the fact that users have to match their brackets and generally avoid syntax errors.
Yeah, I think SGML HTML as the first pass was a mistake. All my early websites were XHTML until people called them "bad"...
That's what browsers at the time did. But the format could be used with a lenient parser if anyone wanted that
The HTML spec actually includes how to parse broken HTML. https://html.spec.whatwg.org/multipage/parsing.html#parse-er...
> But the format could be used with a lenient parser if anyone wanted that
Congratulation on reinventing HTML.
HTML but allowing XML compatible syntax to be valid.
XHTML5 sort of gets us there, but parsing in standard HTML5 mode still won't do the right thing with eg <b />
i think xhtml happened before the wider world of web devs were ready for it. Component based architectures took longer to be adopted than I certainly expected.
It might actually work if reintroduced these days as long as we can consider many components to be valid documents.
There is nothing component-based about xhtml compared to html. It is just html with xml syntax.
It was reintroduced, in the form of jsx.
Sure there is some embedded JS in there as well but ignore that and JSX is thr XHTML comeback story.
And jsx was kind of weird because e4x existed (and was never widespread, and implementations of it went away).
I suppose the important part was that jsx needed to be compiled, which means it couldn't introduce any new security issues…
> XHTML was dropped in favor of HTML5 and XSLT was pretty much useless after that
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.
The XSLT 1.0 spec specifically was written pretty badly, though, to my recollection; I had a hard time at making sense of it
Yeah, XSLT 1.0 has some really obvious missteps, so much so that to my knowledge basically nobody just implements XSLT 1.0. What they actually support is (most of) XSLT 1.0 plus a handful of EXSLT extensions (which are completely unofficial and not part of any XSLT spec, by the way). In my opinion the EXSLT stuff is the bare minimum needed to make XSLT 1.0 at least a passable language. Meanwhile, the XSLT spec evolved into 2.0 and 3.0, which as far as I'm aware, even to this day, has no complete open-source implementation.
And the rendering was very slow back at the day.
At least Firefox will still have it, although with Mozilla being the way that it is, I wouldn't be surprised if they follow suit.
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).
Mozilla has announced that they intend to unship XSLT. https://groups.google.com/a/mozilla.org/g/dev-platform/c/ZRy...
I've been making Easel (https://easel.games) for four years so far! A place for teenagers to make multiplayer web games and share them with each other. Still a long way to go but this is the goal!
Why does it have to be web-based? Discoverability? There's Minecraft and Lego. I discovered the CLI of MSDOS when I was a kid. It was a world to explore for sure.
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.
> What's the simple goto for making web based games that kids can mess around with? It was Flash, and now it's nothing.
Pico-8, Picotron, Tic-80, GameMaker, Godot all have simple web exporter.
Realistically, right now, it's Roblox.
Which is also a pedophile safe-haven (as proven by Chris Hansen and associates) so I wouldn't let my kids use it.
>What's the simple goto for making web based games that kids can mess around with?
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.
I am still using XSLT. I have been using it for 26 years. I generate XML documents on the backend and turn them into HTML for various reports. XSLT has a lot of features and power that newer templating languages lack.
Are any of these newer templating languages worth me switching?
Semi-serious suggestion: wrap the files in an (X)HTML page that links to a Javascript file loading a full XML parser compiled to WebAssembly, which then does the full transformation live, in-browser. You wouldn't need to change your templates or your generation logic much if you structure the surrounding skeleton right!
Of course, you'd need to get over the lunacy of loading a full DOM transformation library into the browser DOM.
you also need to get over the fact that this doesn't work while disabling javascript, while built in xslt doesn't need javascript. on the other hand though it's not a big loss given that xslt isn't any safer. anyone who turns off javascript probably ought to have turned of xslt as well.
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.
My thought wasn't so much "do XSLT parsing in Javascript" and more "compile a C program to apply XSLT transformations using emscriptem and embed that". You can probably throw that concept into any slop machine and get a cursed compatibility library out of it.
Yes, because XSLT won't work in Chrome and Edge anymore.
Their comment isn’t clear if they’re doing the transform on the server before piping it down as HTML, which some implementations have done over the years as it provided access to newer XSLT features that browsers stagnated on.
Yes, I should have been clearer. I mean that I am generating HTML on the back end and not depending on the browser to have XSLT.
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.
You can still run JS or WebAssembly based XSLT transformer
This is what the browser vendors should have done, with links to the wasm modules for doing the transforming. It would have been better this way.
In an XML document a "processing instruction" can trigger the XSLT processor to transform the document in another format.
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.
The cool thing with a wasm-based xslt implementation is there is no need for the browser vendors to gate-keep it. Just use the implementation you prefer.
Except XSLT dates back to the late 90s. WASM was not even a glint in the eyes of its creators. Mozilla even used XSLT internally to drive the GUI for their browser iirc. I think based on that there is a good reason it was incorporated into browsers.
I mean now, instead of ripping it out and breaking sites, they should have implemnented the fallback via wasm.
If they were going to implement it themselves it would be unnecessary to faff around with webassembly. They could just keep the native code implementation that they already have.
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.
XSLT is not going away, it is only in-browser XSLT which is removed. If you are happy with XSLT there is no need to abandon it. Just perform the transformation on the backend.
No. Keep using XSLT server side.
A great way to convince you you've always been wrong:
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
Thank you for reminding me that we don't have Flash anymore. I'm counting blessings I forgot I had.
Flash went away because Steve Jobs made an impassioned plea to find a better way and follow their humble browser which only had single digit percentages of marketshare at the time.
Even for enthusiastic Android vendors who saw it as a differentiating feature from iPhone, Flash still took three years from the iPhone launch to have its first release. Adobe was really in poor shape to port Flash to a new platform. Waiting for them as a vendor to bump their proprietary platform vs integrating support for the features into the browser would have cost years for mobile adoption.
> Adobe was really in poor shape to port Flash to a new platform
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.
My first ever domain name, registered with my pocket money at the age of 13. Hopefully 2040 should bring world peace. One would hope.I always thought Flash was hated by Apple, because of the CPU burn which costs battery time.
It's not like it was great on Android either.
Flash was bad on every platform. If it wasn't vattery, it was accessibility, if it wasn't accessibility it was security.
The only good thing about flash were the authoring tool but it only appealed to content (games, websites) producers, never the users.
I'm pretty sure the Flash games were quite appealing to the users. The Flash navigation rollovers, restaurant menus -- I'm glad we're rid of those.
Have you seen the on screen keyboard displayed by apple tv ?
Is that good accessibility ?
2040: Butlerian Jihad
Flash went away because Steve Jobs made an impassioned plea to find a better way and follow their humble browser which only had single digit percentages of marketshare at the time.
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.
html5 canvas and javascript advancements made flash obsolete, reminder that you used to be able to run java in the browser!
Yes and no, canvas was fine for replacing flash, and JS performance was good enough quickly.
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).
That's unfortunate that audio got neglected, never knew that.
Nobody uses XSLT and nobody maintains XSLT. You're free to support it in your own browser but it's not reasonable to expect Mozilla to support XSLT any more than it supports VRML.
I find it baffling that anyone still cares. RSS nerds like RSS because it can be consumed by software that displays it however the user wants. XSLT pages just function as normal webpages, there is no consuming it programatically because XSLT is the view language. The underlying XML/RSS is what you wanted, not the hodgepodged together crap on top of it.
Anyone else getting a 403 trying to open the page? Like...after cloudflare confirmed humanity n stuff
yes
Feels crazy to me that to date, this was the only widely supported way to pull in shared bits of HTML like headers, navigation, and footers without anything dynamic on either end. It’s such a basic and common use case to be so poorly covered.
> this was the only widely supported way to pull in shared bits of HTML like headers, navigation, and footers without anything dynamic on either end
Framesets. Not great UI though.
i just got flashbacks to a past life where i handcrafted XSLT to pre-render output from a service as HTML server side. Of course the front end was running some asp.net version and Microsoft flavored XSLT had lots of quirks.
Good riddance. XSLT and EJB marked the dark ages of software development. For a half decade nothing made sense and programmers and management were going along with the charade until everyone collectively realized it was complete garbage and just stopped using it. I remember replacing an XSLT/EJB system that processed one order per minute with a C++ system written in a week that processed 10,000/minute. A team of a dozen programmers had been working on that XSLT disaster for years.
In retrospect I really think it was a deliberate plan by IBM and Sun to turn software development into such an awful, impenetrable quagmire that they would be the only ones who could build and maintain any system.
More than ten years ago a coworker wrote a tool to generate Swift from iOS storyboards, to pass data through segues and give us typed access to identifiers. First version of it used XSLT to transform the storyboard XML. A powerful, if niche technology.
I encode all the text, localization, provenance, pedagogical, and forced alignment data for my Latin language audiobook chapters[0] as TEI-XML. When I fetch a document out BaseX, I have an XQM module that wraps the document in a number of XML processing instructions (PIs), one being a pointer to the reader XSLT 1.0 stylesheet which does all the HTML rendering client-side.
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.
[0]: https://fabulae.orbilii.com
I'd consider getting your workflow running in wasm (in wasmtime on the server) and then you can migrate the same workflow to the client using the same wasm module. Nearly all LLVM based compilers can compile to wasm (WebAssembly).
XSLT is glorious, too bad.
There's a long discussion about XSLT removal here: https://github.com/whatwg/html/issues/11578#issuecomment-595... (the link is to the comment with this proposal https://github.com/doriantaylor/swet which already is much better than any templating proposal "the platform" is trying to push)
Chrome is putting a big red button on any site using XSLT. I'm for my RSS feed. It's ugly, I will have to move to another solution. It works fine on Firefox.
Ex: https://ache.one/en/rss.xml
> It works fine on Firefox.
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
there was a wonderful wisiwyg xml editor that rendered the FO life from your xml using your xslt. syntext serna. they even open sources it in their hopes it would see some pick up.
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"?
In the age of LLMs I would expect that legacy code bet carried indefinitely. The LLMs will have it indefinitely in their training data, and with code "cheap" to produce now, what are the good reasons for dropping legacy code?
The obvious answer is that LLMs are not quite the machine gods they're marketed as, innit.
This mindset is why programs only ever seem to bloat more by the day. Code for a given functionality could cost 0 development maintenance and still not be worth including going forward.
I don't understand what you're saying.
Your presumption is that code is "cheap" because of LLMs. I am challenging the premise. Maintaining code in production for a product used by billions of people is not cheap, with or without LLMs. Perhaps your shitty disposable code that you write for yourself and never subject anyone else to is cheap, but if your code is in a large, complex codebase and has to actually work for everyone who uses it, not so much.
LLMs are only getting better and more competent, especially for code well-covered by tests. On such codebases it's definitely cheaper to maintain code with a LLM than by humans alone. I presume then that the XSLT implementation in Chrome is not well-tested.
I think that the issue is not the XSLT implementation (that could be contained), but its deep intégration in the XML stack which is part of web pages processing. Think about XML "processing instructions".
> what are the good reasons for dropping legacy code?
Reducing attack surface.
That is a good reason. Is XSLT known for security problems the same way that CGI was?
Browsers have been relying on libxml2 for ages. Nobody bothered to help libxml2 much, let alone pay for maintenance, but treated it like a security critical component so let their CVE teams loose on unsuspecting volunteers. libxml2 burned out, the project got abandoned, and now Google and everyone else are sweating about what to do with their XML parsing code.
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.
It is not because of specific known vulnerabilities. It is because it is old legacy unmaintained code which is rarely used and which has a large attack surface.
Killing RSS, forcing Javascript on people.
XSLT is rarely used, a significant attack surface, and the upstream libraries are riddled with vulnerabilities. LLMs make the problem worse by lowering the cost of finding new vulnerabilities.
> LLMs make the problem worse by lowering the cost of finding new vulnerabilities.
LLMs make the problem easier because lowering the cost of fixing the vulnerabilities
A good plan... if you can afford to maintain your fork forever.
Google and MS could do it
Anyone getting 403 Forbidden?
I can't load this page.
Yea me too, not sure if hug of death or geo block
Web standards is a lie. Browser vendors just take down stuff because they don't bother.
What will we do for RSS/Atom feeds?
Style them with CSS. https://danfabulich.medium.com/beautify-your-rss-atom-feeds-...
Not style them?
Use css to style them instead?
XSLT RIP(https://xslt.rip/) 698 points|edent|11 months ago|464 comments https://news.ycombinator.com/item?id=45873434
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)
The breakage that sticks out to me is that IIS in Windows Server outputs some reports as XML+XSLT and these have become nigh unusable for years now.
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?)
Edge is Chrome.
The article says as much in the opening. It also includes a statement from Microsoft noting they do not intend to carry this forward separately, with a salient comment in one of the Microsoft page citations:
> 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).
I know, hence why it makes zero sense to name the fork explicitly on the title.
All downstream Chrome clones will follow papa Google eventually, as they won't keep stuff working on their own, cherry picking upstream.
Edge has a separate feature set and deprecation cycle on top of Chromium hence it doesn't make sense to name it separately? I'm not sure I quite follow that logic.
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.
This is a Chrome feature to start with.
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.
Chromium, not Chrome. Chrome itself is a proprietary browser with many additional features on top of Chromimum other Chromium browsers have to reimplement just to work to a basic level, such as playing DRM content or profile syncing, which might be adding to the confusion here. E.g. when Edge pulls in its DRM method it actually gets more support from certain services than what Google does with what Chrome pulls in.
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.
It is wild to look back at XHTML and see that the W3C were entirely correct about XML. They envisaged a world of schemas, client side templating, custom elements, dynamic forms, the works.
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.
They were wrong about one thing: tooling matters.
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.
You could do some awesome things with XML/XSL. My favorite was RSS feeds or OPML collections of RSS feeds (both flavors of XML) calling an XSL transformation when viewed in a web browser instead of mined by computers for data; same with TEI files, although that was a bit more arcane. The idea was that you'd have one data file for machine use and a way to present that data to humans as a web page.
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.
> 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.
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.
I can't help but agree, and sometimes I think about the alternate version of the web where XML realized its full potential as the dominant technology. The obvious problem with XML is that the syntax is so verbose and redundant that it's only barely human-writable, but this is 100% a solvable problem.
Is that really accurate? In a world where HTML5 never happened, how would XHTML/XSLT solve the same problems that modern front-end Javascript frameworks do (interactive data-driven websites)? I say this as someone who thinks XSLT is a really useful technology, and doesn't want it to be deprecated.
That browser world would of been glorious without HTML5. Where Javascript wasn't in the browser and Tcl was (it was a contender); we would be working with plugin based browsers rather than built-in to the hood. That in turn would enable you to process incoming documents based in XSLT however you desired.
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
> ...we would be working with plugin based browsers rather than built-in to the hood...
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?
You can't claim the JavaScript technologies of now and apply them to Tcl of the 90's. Tcl is an ace language and well suited for the web.
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.
XSLT however has an absurdly steep learning curve, on top of it (like XML) being utterly verbose. There is a reason neither technology ever caught on outside of big enterprise or government projects.
yet people will say that HTML5 is all you need or something
https://web.archive.org/web/20261017201132/https://doctor-se... while it gives 503
Bless the Internet Archive for basically hosting a second copy of the internet with sufficient bandwidth to serve whatever is currently down, while this single site didn't survive the traffic it got individually
Enjoyable framing, well said.
Getting 403 for this.
Firefox user here, don't care.
Chromium browser happenings are just nonsense.
503
So, this site breaks, we know that much
doctor-seo dot net has failed us. What is this world coming to?
Sorry guys, Site normally doesnt have that much traffic and server got jammed. Fixed it, and back again on track
Sorry :(
Oh hey! Nice fixing.
Wondered: is there a bit of a pun with Doctor SEO (like someone might doctor a picture w/Photoshop)?
Looks like the site broke