lobsters score: 11 · tags: browsers, web
Good night sweet prince.
My first job was in digital publishing. Docbook and XSLT and XQuery all the way down. My first conference was XML Prague 2013.
I still laugh about that conference. Michael Kay was presenting some frontend XSLT. We affectionately referred to him as man with beard, because we referred to each programming book in our office with a description of the front cover. The XSLT one had Michael on the cover, and by proxy he also inherited the name. Michael presented an implementation of multiplayer chess with XSLT. Which they had achieved… sort of. The state machine at its core at least. It was caveated that all the interactions needed JavaScript and state was transferred between two browser sessions by sending a tweet with the serialized game state. No mean feat I’m sure, given the nature of XSLT too. But it did make us giggle in the moment and we came away thinking… surely this won’t last?
Yet here we are 13 years later. I guess it lasted a bit longer than I had imagined.
score 1 · canonical
All of the mourning for XSLT in browsers is a mix of nostalgia and loss aversion.
Devs could have been using it for two decades and (to a rounding error) they haven’t.
The XSLT that browsers had just wasn’t useful. It wasn’t dynamic, so it was merely an equivalent of server-side templating, but with more latency, more buffering, and restricted to an old version of a language that has the same global selector composition problems that people dislike CSS for.
score 1 · canonical
About the Atom/RSS use case, to move away from XSLT, I wanted to do content negotiation. Unfortunately, while 1/3 of the RSS readers are advertising the appropriate MIME type ahead of text/html, 1/3 ranked at the same level and the last 1/3 ranked it behind. At the end, my feed is just using a meta refresh tag to redirect to the HTML version. I add a small bit of JS to add back the xml extension after the redirect.
score 2 · canonical
Counterpoint to the claim that “Oh, it’s Google being evil again, trampling over everyone! >:(”: https://meyerweb.com/eric/thoughts/2025/08/22/no-google-did-not-unilaterally-decide-to-kill-xslt/
the idea was raised in a periodic WHATNOT meeting (call), where someone at Mozilla was actually the one to bring it up, after it had come up in various conversations over the previous few months. After Mason opened the issue, members of the Mozilla and WebKit teams expressed (tentative, mostly) support for the idea of exploring this removal
tl;dr: Someone at Mozilla brought it up, and there was at least some level of initial agreement here among the browser vendors.
score 1 · canonical
I used XSLT extensively back in the day with DocBook and with my own schemas to maintain my website and other docs… but I always used xsltproc offline to translate the XML docs into HTML pages.
The fact that XSLT was supported in browsers was unknown to me and I only discovered that it was a thing recently when I first heard that XSLT support was going away. “Going away how?! It’s just a preprocessing tool!”
score 1 · canonical
That was not a unilateral decision mind you, Google said “jump” and other browser vendors said “how high?”
I’m baffled by this portrayal. As linked, it genuinely isn’t just Google: Mozilla and Apple are well-documented as having wanted to kill XSLT for some years, they just lacked the enthusiasm to push it. The closest I can get to this portrayal is that once Google said they were going to try again at killing it (they tried before in I think 2013 and gave up), the others said “great, we’ll see how they go with it and gladly remove our own if it’s going okay for them”.
But what Google specifically have done through the process is lied blatantly. They’ve kept on listing security as their primary reason for removing it, even though they made a near-perfect security-issue-free drop-in replacement before they were even willing to call it deprecated. I suspect it might genuinely have been easier to just ship that extension with the browser, freezing the code in a way that means it never needs any maintenance ever again.
(I have been increasingly anti-Google for more than a decade, but I think the strength of some’s focus on Google in the XSLT matter is at least a little misguided. I get the sense that one of the other browser makers might have initiated it before many more years if Google hadn’t.)
score 2 · canonical
I’m baffled by this portrayal.
Google pays Mozilla and Apple a tremendous amount of money, so it is comforting to think of them as the bad guy, but you’re right in the way that it’s probably not them.
I think the strength of some’s focus on Google in the XSLT matter is at least a little misguided.
You don’t think it’s a little suspicious that someone might spend so much money to make it harder for people to access these websites?
https://www.congress.gov/117/bills/hr3617/BILLS-117hr3617ih.xml
https://www.weather.gov/xml/current_obs/KABE.xml
https://www.europarl.europa.eu/politicalparties/index_en.xml
https://apps.tga.gov.au/downloads/sequence-description.xml
https://cwfis.cfs.nrcan.gc.ca/downloads/fwi_obs/WeatherStations_CWFIS_export.xml
https://converters.eionet.europa.eu/xmlfile/EPRTR_MethodTypeCode_1.xml
score 1 · canonical
FWIW, there have been multiple security bugs found in browser implementations of XSLT just since the deprecation was announced.
score 2 · canonical
(Opens link) …Upon availability of Mythos. Damn near every package I can name has had security bugs found since then.
score 1 · canonical
But, as I said, Google already built a drop-in replacement which, by being a regular extension using WASM, is not subject to security issues.
score 1 · canonical
So I hate Google as much as the next person, but this sounds like a fine outcome to me?
XSLT is a feature of the web platform used by a tiny majority of websites. They get to use a wasm polyfill so they can continue working, the rest of the world gets a simpler web platform.
Isn’t this quite similar to what happened to Flash in the end? We have a wasm polyfill called ruffle.rs that allows all the Flash apps to keep working but we also make the browsers leaner and safer for everyone by not shipping Flash.
score 2 · canonical
No this is not similar.
Flash was always an external install, so now either the website or the user install the polyfill (there are both options). And, obviously, Flash format is underdocumented so the polyfill needs some reverse engineering which is still ongoing.
XSLT is a presumably fully specified part of the standard. So switching to a sandboxed implementation is reasonable in any case, but the proper way to do it is to include the polyfill with the browser.
Having the polyfill and not including it with the browser, and not even making the warning banner link to the extension is a malicious increase of how much of a garbage treadmill the Web is, and further devalues the standards.
score 1 · canonical
Flash was always an external install
That is not correct. Flash was bundled with Internet Explorer for many years in different versions. Even Netscape had it. Same later with Safari and Chrome.
score 1 · canonical
IIRC, there were quite a number of incompatibilities between the different browser implementations and the standard itself. Given that part of the issue here was that nobody had the resources or will to continue fixing bugs and incompatibilities, I can understand why browsers have also been reluctant to make the extension built-in - they’d essentially be doing that work for something that doesn’t work properly and that will probably never be fixed, let alone updated to support newer version of the XSLT spec.
I don’t know that I entirely agree with the decision, but I can very much understand the motivation here, and I’m very sympathetic to the argument that this is just formalising and clarifying a state of affairs that has been implicitly the case for a while now.
score 1 · canonical
For a very long time there were also incompatibilities in how the HTML comments are parsed, so what? I don’t promise there aren’t now.
The state of affairs was not this. The state of affairs was the pretty-baseline number of bugs, although some of them were probably exploitable which is a drawback. Polyfill — that is already in extension stores! — is probably comparable to other implementations in bugginess, and hard to exploit. Browsers absolutely ship buggy parts without fixing things for decades, so it would be absolutely a status quo thing to switch the implementation to a safer one and keep not fixing bugs, and it would keep a nonzero amount of old sites (especially ones that are more valuable by not having updates and being the same snapshot) accessible with the normal baseline level of buggyness.
score 1 · canonical
The point was not that there were incompatibilities, but that there were incompatibilities with no pathway to them being fixed - as I understand it, the underlying library for Chrome/Safari was barely even in maintenance mode, and the only independent implementation, Firefox, didn’t have the resources to address the issues.
And the problem is that that remains even with the WASM version. Yes, that fixes the core security issues by sandboxing everything, but it doesn’t solve the fact that it’s still a buggy wart with no-one interested in supporting it. And to make matters worse, all browsers would be standardising on the same implementation, so now you’ve got a spec which is basically “whatever this library does”, which isn’t great (c.f. WebSQL).
So I can really understand the argument for cutting your losses and getting rid of XSLT altogether, especially given how little of the web it would affect, and the many alternative approaches. That said, I personally think it would have been easier to just adopt the WASM library as a pseudo-standard like how all browsers render PDFs natively, and accept that this library will never really be updated. And that said, I think the whole discussion is entirely overblown, and the at times conspiratorial claims from the original article and many of the comments here are an insane reaction to this whole saga that make me very glad I’m not one of the people making these decisions.
score 1 · canonical
XSLT is one of those technologies I’ve always thought was very cool; my very first website in 2000 was XHTML + XSLT. But I do wonder how we’ll feel about this decision in five years. Will this feel like Google Reader, missed a decade later; or like Flash, broadly considered a good removal from the web?
score 2 · canonical
XSLT suffered its worst defeat when it became clear that XHTML was not going to be the future of web development.
The whole elegance of it was based on the idea that it you would use an XML -> XML transformation language, and that XML schema validators could make sure that the source and destination schema were obeyed.
Well, in my view XML itself is now a living fossil so I don’t see much reason to invest in it. We just learned how to make better languages. It sucks that you can’t say what the text content of an XML document is until you download a separate schema file. I think now that we have JSON and
parse(jsonDocument)people have forgotten thatparse(xmlDocument)isn’t even correct. It HAS to beparse(xmlDocument, schema).So my stance is definitely odd: I’m willing to let the old thing die, but I think we forgot the lessons we should have learned https://xkcd.com/242/
I’ve built CSTML to restore the vision of a core symmetry between arbitrary documents and “HTML-schematized” documents. It doesn’t let schema validation rules influence parser rules, so you can just
parse(cstmlDocument).CSTML also supports schema validation through the “parse don’t validate” architecture. Schema valiators are parsers, and anything the parser can consume is considered valid according to that schema.
In theory this could realize the whole vision: users get the ability to have schematized domain-specific documents which are easy for non-technical users to maintain, and then transformations can be written to HTML-schematized CSTML (which looks like this: https://github.com/bablr-lang/bablr-docs/blob/trunk/src/content/docs/guides/cstml.cstml). If a transformation is able to know for sure that its input data follows a known schema, a well-implemented transformation will also be able to guarantee valid output for all possible inputs.
score 1 · canonical
parse(jsonDocument)
Unfortunately it’s not
parse(jsonDocument)though, is it? It’svalidate(schema, parse(jsonDocument))with bothvalidateandschemabeing left as exercises for the reader.
score 1 · canonical
As I say, CSTML, my horse in this ring, is targeting XML for replacement. That is why I have designed generalized schema validation rather than leaving it as an exercise for the reader like JSON does
score 1 · canonical
XSLT suffered its worst defeat when it became clear that XHTML was not going to be the future of web development.
This is a popular take, but I don’t understand it. XHTML is already directly interpretable by the browser. XSLT is for transforming things that are not (such as atom feeds) into HTML, etc.
Of course XSLT still continues to have a thriving life outside of web browsers also, but that’s perhaps a separate consideration.
score 2 · canonical
Xslt was an absolutely beautiful introduction to stateless programming and allowed lovely transitions from thing a to thing b. You can do a lot of the same with a json document, but not as elegantly and without as much thought (imo) and perhaps it has outlived its time, but I will miss it a sit introduced me to functional programming as made a huge difference. Also, shoutout to the woman who wrote pretty much all of the xslt books and would literally answer questions on line.
score 1 · canonical
But not XSLT in the browser, which has been stuck on v1 of the spec pretty much since it was first implemented, iirc.
score 1 · canonical
Right, you transform XML to XHTML. That’s why it matters that XHTML died.
In my mind XML was about semantic documents while HTML focused on display documents. It makes incredible amount of sense to build display documents from semantic documents
score 1 · canonical
It’s possible, but you lose the simplicity. You wouldn’t be working with the same parsing rules and the same DOM nodes end to end
score 1 · canonical
I have mixed feelings because I really like the XML document model. It’s a tree of nodes where each node has key-value pairs as attributes and zero or more children. Each child is another node or character data. This is a really nice generic structure that a huge number of things map to.
But the text serialisation of this is pretty horrible. Entities are painful. The way namespaces let you remap names is nice in theory (if two XML document types have a node with the same name, you can use both and disambiguate them with the namespace prefix), but also quite painful for parsing and it would be simpler to either disallow conflicting names in things that import two namespaces, or require that they have identical structure.
The text tree that IGK builds is isomorphic to XML (and generates XML on the back end for processing by other steps), but the input is more or less the same as SILE’s LaTeX-inspired syntax. Nodes are defined starting with a backslash then the name, so \foo{} is equivalent to XML’s <foo />. Attributes are specified in square brackets, so \foo[key=value]{} or \foo[key=“value”]{} are equivalent to XML’s <foo key=“value” />. Children go in the braces, so \foo{\bar{some} text}} is equivalent to <foo><bar>some</bar> text</foo> but is much easier to type.
It’s a shame that the serialisation format and the abstract model were so closely entwined.
I had the same reaction to XSLT: a declarative language for doing tree-to-tree transforms over this document model? Wonderful. That language written as a verbose AST encoded in a verbose markup language? Awful.
Some of the XML-based standards just gave up. SVG throws away XML structure in some places and just has strings that embed something that looks a lot like a PostScript command string (I’m not sure if it actually is PostScript).
If XML had had a better human-editable text serialisation and a standard well-supported, dense binary serialisation then I suspect things would have been much better. gzip-compressed XML is fairly dense, but now you have to chain two (complex, stateful) parsers together when a good binary serialisation could have also improved parsing efficiency.
It’s a shame most of the replacements have either a worse abstract model, have a tighter coupling of the abstract model to the serialisation, or both.
score 1 · canonical
Why is CDATASection part of the Document Object Model? Entities aren’t, they get flattened to Text, so it was already not round-trippable. Instead, a lot of things that read XML in low-level ways only support text or only support CDATA in particular places, even though they’re supposed to be entirely equivalent.
As for attributes… well, that’s probably the messiest area. They’re not really expressively necessary, and being limited to strings is frequently terrible and you invariably end up with microsyntaxes within attribute values, and attribute-or-element discussions abound. S-expressions do just fine without them. But attributes are also firmly what cement SGML/HTML/XML as markup languages. XML was never a great data language, but it got shoehorned a lot.
score 1 · canonical
I really like the XML document model.
I also like the tree model (XML Infoset). Although XML is not as abstract as ASN.1, does not strictly separate model from serialization, multiple serializations are possible and there are also binary ones (Fast Infoset, EXI…). Years ago I did a prototype alt2xml, which reads various formats and converts them on the fly to stream of SAX events. So you can feed e.g. INI, Java properties or JSON from one side and on the other side it produces stream of events that can be transformed regardless of the source format. So you can e.g. XSLT transform an INI file or query JSON input using XPath or validate .properties against XSD schema. It is not just a command line tool, it could be used as a library and it provides same interface (SAX parser) for various input format. However alt2xml is just a concept and working prototype. Later I did
relpipe-in-htmltablethat can query HTML tag soup with XPath.XSLT: a declarative language for doing tree-to-tree transforms over this document model? Wonderful. That language written as a verbose AST encoded in a verbose markup language? Awful.
I have mixed feelings about XSLT. I love that template matching and kind of elegance and effectivity. But sometimes you have to fight with its functional nature and immutability – yes, it makes some sense, but doing some tasks in this „pure“ way is bit too cumbersome and you find yourself thinking it would be nice if it were a little more imperative and having a loop and mutable variable would mean much more friendly code than recursion. And of course, the need to write all those language constructs (if, else, for, etc.) as XML elements does not help much. On the other hand, it is homoiconicity, we can have a template that generates templates… However for those who prefer different syntax, there is XQuery. I mixes data with language constructs quite well without need having everything as XML elements.
Some of the XML-based standards just gave up. SVG throws away XML structure in some places and just has strings that embed something that looks a lot like a PostScript command string (I’m not sure if it actually is PostScript).
I see this as a failure. In alternative history, it would be all XML, everything in the single tree, no need for additional parser for nested string data… and maybe it would create more pressure to timely deployment of efficient binary XML serialization.
score 1 · canonical
I’ve addressed each of these issues in CSTML. I don’t think any other language has as good a claim to be XML’s successor as CSTML does.
It’s still a tree of nodes each of which has embedded attributes and 0 or more children. I’ve just allowed some data to be stored on the relationship itself. This allows relationships to have names, which unlocks the natural ability to store syntax trees as documents. E.g.
<Add> left: <Number '2' /> op: '+' right: <Number '2' /></>I used JSON for attributes, my reasoning being that if people really want to stuff JSON data in attributes nothing is stopping them. It’s (much) easier to parse
<Node { attr: true } />with an interpolating parser because attrs is now one syntax tree node instead of 0 or N individual attribute bindings.I kicked out XML’s entities and used JSON’s system of escaping to ensure
parse(cstml)is the APII kicked out the idea of “raw text” (e.g. XML CDATA). All content must be properly quoted and escaped. This makes pretty-printing CSTML documents inherently safe. Pretty-printing is not inherently safe on either XML or HTML.
Bindings replace namespaces. Where in XML the name of the namespace is unimportant except as it maps to a URL, in CSTML the namespace must be referred to by its official name, just as named nodes must use their official name! It’s
<Namespace.Name>vs:Namespace: <Name>. There’s even two more significant reasons:Namespace:is better! One: it’s easier to parse with a stream parser, as the syntax is at every moment unambiguous when progressively revealed from left to right (not so for XML). And two: by making clear that:Namespace:isn’t part of the identity of the node (and indeed it is not) we make it possible to reuse the DOM node in a different namespace without needing to rebuild it.Close tag is just
</>because tag soup makes parsing terrible. If open tags always match exactly with close tags, all your parser needs to work correctly is a depth count.We have symmetrical SAX and DOM representations: https://gist.github.com/conartist6/8ce77513e70ade4924c23bf31e762023
By the way I built a userscript to highlight monospace code if it helps anyone: https://gist.github.com/conartist6/d95b1357fbb2b205d06e8ad03e1e466b It sure helps me read what I wrote!
score 1 · canonical
XSLT has much more use than viewing styled XML in WWW browser. And XSLT itself still works pretty well. However removing this browser feature is a shameful step.
One of my favorite use-cases for XSLT is that you can attach a stylesheet to a configuration file and user can see nicely formatted config with documentation, notes etc. I have it e.g. in SQL-DK.
score 2 · canonical
What’s the use case of XSLT which CSS doesn’t cover? I don’t think I’ve ever encountered a document which I wanted to open in a browser which used XSLT, and the whole “XML all the things” fad has been dead for a long time at this point
score 2 · canonical
CSS covers only the visual part. And you already need properly structured HTML.
In contrast, XSLT is a general transformation tool that has a tree structure on input and a tree structure or plain text on output. It is cumbersome at first sight but inside it hides elegance that is hard to replicate elsewhere.
- display config files in user-friendly way, add documentation, comments, maybe also some warnings or validations (however strict validations belong rather to XSD schema)
- upgrade/downgrade transformation for config or data files to translate them between versions
- various customizations, this can be done even on-the-fly when request/response is being sent (e.g. SOAP or other document)
- generate summary or reports
- generate or transform DocBook or DITA
- generate or transform LibreOffice documents
- generate EPUB (not only pages, but also metadata, table of contents etc.)
- same for other documentation/help formats
It can even work with collections of files (multiple inputs, multiple outputs).
And with tools like alt2xml, relpipe-in-htmltable (mentioned in other comments here), I can apply XSLT templates also on other format than XML.
score 1 · canonical
Centralizing the costs of presentation leads to monopolies and user abuse.
The best argument for separating out semantic documents are web sustainability and web accessibility
score 2 · canonical
“contact the maintainer of the site” — you broke the web Google, own it at least.
I’m not really sure what the criticism here is though. Google informing users of the website to contain the maintainers of the site to me seems to be the sensible action here. It’s not unlikely that users of those old sites might be more active than the people that created them, and that is a reasonable mechanism by which to make that transition possible.
score 0 · canonical
But contacting Google won’t fix the website; it won’t even be read by a human. The only actionable advice for a user who wants the content to continue to be available is to contact the site maintainer. This doesn’t absolve Google, but I don’t see any other message being useful.
score 3 · canonical
The only actionable advice for a user who wants the content to continue to be available is to…
switch to another browser.
(I know, it is fragmented and difficult, but whole web ecosystem controlled by a single corporation (Mozilla is just their puppet, well paid) is extremely unhealthy and dangerous)
score 1 · canonical
switch to another browser.
Which browser would you recommend that is continuing to support XSLT? Is it available on iPhones? Does your bank support it? You have to meet your users where they’re at.
score 2 · canonical