"Remove mentions of XSLT from the html spec"
github.com
Related: Should we remove XSLT from the web platform? - https://news.ycombinator.com/item?id=44909599
github.com
- This isn't Chrome doing this unilaterally. https://github.com/whatwg/html/issues/11523 shows that representatives from every browser are supportive and there have been discussions about this in standards meetings: https://github.com/whatwg/html/issues/11146#issuecomment-275...
- You can see from the WHATNOT meeting agenda that it was a Mozilla engineer who brought it up last time.
- Opening a PR doesn't necessarily mean that it'll be merged. Notice the unchecked tasks - there's a lot to still do on this one. Even so, give the cross-vendor support for this is seems likely to proceed at some point.
It's an issue open on the HTML spec for the HTML spec maintainers to consider. It was opened by a Chrome engineer after at least two meetings where a Mozilla engineer raised the topic, and where there was apparently vendor support for it.
This is happening after some serious exploits were found: https://www.offensivecon.org/speakers/2025/ivan-fratric.html
And the maintainer of libxslt has stepped down: https://gitlab.gnome.org/GNOME/libxml2/-/issues/913
[1] https://blog.startifact.com/posts/xee/
It's not just a matter of replacing the libxslt; libxslt integrates quite closely with libxml2. There's a fair amount of glue to bolt libxml2/libxslt on to Blink (and WebKit); I can't speak for Gecko.
Even when there's no work on new XML/XSLT features, there's a passive cost to just having that glue code around since it adds quirks and special cases that otherwise wouldn't exist.
My understanding is that browsers specifically use the 1999 version and changing this would break compat
To be completely honest, though, I'm not sure what people expect to get out of it. I dug into this a while ago for a rather silly reason and I found that it's very inside baseball, and unless you really wanted to get invested in it it seems like it'd be hard to meaningfully contribute.
To be honest if people are very upset about a feature that might be added or a feature that might be removed the right thing to do is probably to literally just raise it publicly, organize supporters and generally act in protest.
Google may have a lot of control over the web, but note that WEI still didn't ship.
The bug trackers are also a fine place to provide community feedback. For example there's plenty of comments providing use cases that weren't hidden. But if you read the hidden ones (especially on the issue rather than PR) there's some truly unhinged commentary that rightly resulted in being hidden and unfortunately locking of the thread.
Ultimately the way the community can influence decisions is to not be completely unhinged.
Like someone else said the other way would be to just use XSLT in the first place.
Your other opportunity is to put together a credible plan to resource the XSLT implementations in the various browsers. I underline, highlight, bold, and italicize the word "credible" here. You are facing an extremely uphill battle from the visible lack of support for the development; any truly credible offer should have come many years ago. Big projects are well aware of the utility of last-minute, emotionally-driven offers of support in the midst of a burst of publicity, viz, effectively zero.
I don't know that the power is as imbalanced as people think here so much as a very long and drawn out conversation has been had by the web as a whole, on the whole the web has agreed this is not a terribly useful technology by vast bulk of implementation work, and this is the final closing chapter where the browsers are basically implementing the will of the web. The standard for removal isn't "literally 0 usage in the entire world", and whatever the standard is, if XSLT isn't on the "remove" side of it, that would just be a sign it needs to be tuned up because XSLT is a complete non-entity on the web. If you are not feeling like your voice is being respected it's because it's one of literally millions upon millions; what do you expect?
[1]: I know exceptions are reading this post, but you are exceptions. And not terribly common ones.
The main thing that seems unaddressed is the UX if a user opens a direct link to an XML file and will now just see tag soup instead of the intended rendering.
I think this could be addressed by introducing a <?human-readable ...some url...?> processing instruction that browsers would interpret like a meta tag redirect. Then sites that are interested could put that line at the top of their XML files and redirect to an alternative representation in HTML or even to a server-side or WASM-powered XSLT processor for the file.
Sort of like an inverse of the <link rel="alternate" ...> solution that the post mentioned.
The only thing this doesn't fix is sites that are abandoned and won't update or are part if embedded devices and can't update.
HTTP has already had this since the 90s. Clients send the Accept HTTP header indicating which format they want and servers can respond with alternative representations. You can already respond with HTML for browsers and XML for other clients today. You don’t need the browser to know how to do the transformation.
* side effect free (a pure data to data transformation)
* stable, from a spec perspective, for decades
* completely client-side
Isn't this basically an A+ report card for any attempt at making a powerful general tool? The fact that the suggested solution in the absence of XSLT is to toil away at implementing application-specific solutions forever really feels like working toward the wrong direction.
This would work without special syntax in the XML file.
... Largely because of lack of help from major users such as browsers.
Speaking from personal experience, working on libxslt... not easy for many reasons beyond the complexity of XSLT itself. For instance:
- libxslt is linked against by all sorts of random apps and changes to libxslt (and libxml2) must not break ABI compatibility. This often constrains the shape of possible patches, and makes it that much harder to write systemic fixes.
- libxslt reaches into libxml and reuses fields in creative ways, e.g. libxml2's `xmlDoc` has a `compression` field that is ostensibly for storing the zlib compression level [1], but libxslt has co-opted it for a completely different purpose [2].
- There's a lot of missing institutional knowledge and no clear place to go for answers, e.g. what does a compile-time flag that guards "refactored parts of libxslt" [3] do exactly?
[1] https://gitlab.gnome.org/GNOME/libxml2/-/blob/ca10c7d7b513f3...
[2] https://gitlab.gnome.org/GNOME/libxslt/-/blob/841a1805a9a9aa...
[3] https://gitlab.gnome.org/GNOME/libxslt/-/blob/841a1805a9a9aa...
Out of those three projects, two are notoriously under-resourced, and one is notorious for constantly ramming through new features at a pace the other two projects can't or won't keep up with.
Why wouldn't the overworked/underresourced Safari and Firefox people want an excuse to have less work to do?
This appeal to authority doesn't hold water for me because the important question is not 'do people with specific priorities think this is a good idea' but instead 'will this idea negatively impact the web platform and its billions of users'. Out of those billions of users it's quite possible a sizable number of them rely on XSLT, and in my reading around this issue I haven't seen concrete data supporting that nobody uses XSLT. If nobody really used it there wouldn't be a need for that polyfill.
Fundamentally the question that should be asked here is: Billions of people use the web every day, which means they're relying on technologies like HTML, CSS, XML, XSLT, etc. Are we okay with breaking something that 0.1% of users rely on? If we are, okay, but who's going to tell that 0.1% of a billion people that they don't matter?
The argument I've seen made is that Google doesn't have the resources (somehow) to maintain XSLT support. One of the googlers argued that new emerging web APIs are more popular, and thus more deserving of resources. So what we've created is a zero-sum game where any new feature added to the platform requires the removal of an existing feature. Where does that game end? Will we eventually remove ARIA and/or screen reader support because it's not used by enough people?
I think all three browser vendors have a duty to their users to support them to the best of their ability, and Google has the financial and human resources to support users of XSLT and is choosing not to.
Billions of people use the web every day. Should the 99.99% of them be vulnerable to XSLT security bugs for the other 0.01%?
Is there a spending on junk projects issue with Firefox?
https://galaxy.ai/youtube-summarizer/is-mozilla-wasting-mone...
Seriously though, if I were forced to maintain every tiny legacy feature in a 20 year old app... I'd also become a "former" dev :)
Even in its heyday, XSLT seemed like an afterthought. Probably there are a handful of legacy corporate users hanging on to it for dear life. But if infinitely more popular techs (like Flash or FTP or non HTTPS sites) can be deprecated without much fuss... I don't think XSLT has much of a leg to stand on...
1. not trillion dollar tech companies
or
2. not 99% funded from a trillion dollar tech company.
I have long suspected that Google gives so much money to Mozilla both for the default search option, but also for massive indirect control to deliberately cripple Mozilla in insidious ways to massively reduce Firefox's marketshare. And I have long predicted that Google is going to make the rate of change needed in web standards so high that orgs like Mozilla can't keep up and then implode/become unusable.
Glad to see the disdain for the actual users of their software remains.
[1] https://github.com/whatwg/html/issues/2894 [2] https://www.theregister.com/2021/08/05/google_chrome_iframe/
(FWIW I agree alert and XSLT are terrible, but that ship sailed a long time ago.)
Did anybody bother checking with Microsoft? XML/XSLT is very enterprisey and this will likely break a lot of intranet (or $$$ commercial) applications.
Secondly, why is Firefox/Gecko given full weight for their vote when their marketshare is dwindling into irrelevancy? It's the equivalent of the crazy cat hoarder who wormed her way onto the HOA board speaking for everyone else. No.
This is also not a fair framing. There are lots of good reasons to deprecate a technology, and it doesn't mean the users don't matter. As always, technology requires tradeoffs (as does the "common good", usually.)
Because otherwise everybody has to repeat same work again and again, programming how - instead of focusing on what, declarative way.
Then data is not free, but caged by processing so it can't exist without it.
I just want data or information - not processing, not strings attached.
I don't see any need to run any extra code over any information - except to keep control and to attach other code, trackers etc. - just, I'm not Google, no need to push anything (just.. faster JS engine instead of empowering users somehow made a browser better ? (no matter how fast, you can't) - for what ? (of what I needed) - or instead of something, that they 'forgot' with a wish they could erase it ?)
Probably more like 0.0001% these days. I doubt 0.1% of websites ever used it.
Yup. Just like the removal of confirm/prompt that had vendor support and was immediately rushed. Thankfully to be indefinitely postponed.
Here's Google's own doc on how a feature should be removed: https://docs.google.com/document/d/1RC-pBBvsazYfCNNUSkPqAVpS...
Notice how "unilateral support by browser vendors" didn't even look at actual usage of XSLT, where it's used, and whether significant parts would be affected.
Good times.
>very, very few websites
Doesn't include all the corporate web sites that they are probably blocked from getting such telemetry for. These are the users that are pushing back.
2. They have a semi-internal document https://docs.google.com/document/d/1RC-pBBvsazYfCNNUSkPqAVpS... that explicitly states: small usage percentage doesn't mean you can safely remove a feature
--- start quote ---
As a general rule of thumb, 0.1% of PageVisits (1 in 1000) is large, while 0.001% is considered small but non-trivial. Anything below about 0.00001% (1 in 10 million) is generally considered trivial.
There are around 771 billion web pages viewed in Chrome every month (not counting other Chromium-based browsers). So seriously breaking even 0.0001% still results in someone being frustrated every 3 seconds, and so not to be taken lightly!
--- end quote ---
3. Any feature removal on the web has to be a) given thorough thought and investigation which we haven't seen. Library of congress apparently uses XSLT and Chrome devs couldn't care less
Here's we're talking about killing off XSLT used in the intended, documented, standard way.
The other suggestions ignored seemed to be "if this is about security, then fund the OSS, project. Or swap to a newer safer library, or pull it into the JS sandbox and ensure support is maintained." Which were all mostly ignored.
And "if this is about adoption then listen to the constant community request to update the the newer XSLT 3.0 which has been out for years and world have much higher adoption due to tons of QoL improvements including handling JSON."
And the argument presented, which i don't know (but seems reasonable to me), is that XSLT supports the open web. Google tried to kill it a decade ago, the community pushed back and stopped it. So Google's plan was to refuse to do anything to support it, ignore community requests for simple improvements, try to make it wither then use that as justification for killing it at a later point.
Forcing this through when almost all feedback is against it seems to support that to me. Especially with XSLT suddenly/recebtly gaining a lot of popularity and it seems like they are trying to kill it before they have an open competitor in the web.
this is a perfectly reasonable course of action if the feedback is "please don't" but the people saying "please don't" aren't people who are actually using it or who can explain why it's necessary. it's a request for feedback, not just a poll.
I'd presume that most of those people are using it in some capacity, it's just that their numbers are seen as too minor to influence the decision.
> explain why it's necessary
No feature is strictly necessary, so that's a pretty high standard.
I think the idea of that is reasonable. If I used XSLT on my tiny, low-traffic blog, I think it's reasonable for browser devs to tell me to update my code. Even if 100 people like me said the same thing, that's still a vanishingly small portion of the web, a rounding error, protesting it.
I'd expect the protests to be disproportionate in number and loudness because the billion webmasters who couldn't care less aren't weighing in on it.
Now, I'm not saying this with a strong opinion on this specific proposal. It doesn't affect me either way. It's more about the general principle that a loud number of small webmasters opposing the move doesn't mean it's not a good idea. Like, people loudly argued about removing <marquee> back in the day, but that happened to be a great idea.
They didn't even do the tiniest bit of research, as people in the discussions clearly showed, and there are high impact sites that would be affected by this including Congress and Library of Congress: https://news.ycombinator.com/item?id=44958929
The other reason is that SVG took a very long time to get good, and when it did I wanted to use XSL and SVG together.
Now SVG has got good and they are removing it :(
Unlike your average Angular project. Building on top of minified Typescript is rather unreasonable and integrating with JSON means you have a less than reliable data transfer protocol without schema, so validation is a crude trial and error process.
There's no elegance in raw XML et consortes, but the maturity of this family means there are also very mature tools so in practice you don't have to look at XML or XSD as text, you can just unmarshal it into your programming language of choice (that is, if you choose a suitable one) and look at it as you would some other data structure.
Fixed that typo for you.
I'm very practically using Debian Linux on ChromeOS to develop test and debug enterprise software. I even compile and run some native code. It is very much more than just the web.
The discussions don't address that. That surprises me, because these seem to be the people in charge of the spec.
The promise is, "This is HTML. Count on it."
Now it would be just, "This is HTML for now. Don't count on it staying that way, though."
Not saying it should never be done, but it's a big deal.
They are removing XSLT just for being a long-tail technology. The same argument would apply to other long-tail web technologies.
So what they're really proposing is to cut off the web's long tail.
(Just want to note: The list of long-tail web technologies will continue to grow over time... we can expect it to grow roughly in proportion to the rate at which web technologies were added around 20 years in the past. Meaning we can expect an explosion of long-tail web technologies soon enough. We might want to think carefully about whether the people currently running the web value the web's long tail the way we would like.)
(For the same reason, they dropped the name HTML5 and are only talking about "HTML". Who needs version numbers if there is no future and no past anyway?)
https://whatwg.org/faq#living-standard https://github.com/whatwg/html/blob/main/FAQ.md#html-standar...
Seems hard to square removing XSLT with that.
There's a sweet spot between giving people enough time and tools to make a transition while also avoiding having your platform implode into a black hole of accumulated complexity. Neither end of the spectrum is healthy.
If this was just Android that would be an issue between Google and their developers/users, but this is everybody.
I get that people are more reacting to the prospect of browsers removing existing support, but I was pretty surprised by how short the PR was. I assumed it was more intertwined.
If this was just about, e.g., organizing web standards docs for better separation of concerns, I think a lot of people would be reacting to it quite differently.
If they were one of the voices for "the browser should be lightweight and let JS libs handle the weird stuff" I would respect this action, but Google is very very not that.
That's a concise way to put it. IMHO this is also the main problem of the standard.
However I think XSLT isn't only long tail but also a curiosity with just academic value. I've being doing some experimentation and prototyping with XSLT while it was still considered alive. So even if you see some value in it, the problems are endless:
* XSLT is cumbersome to write and read
* XML is clunky, XSLT even more so
* yes there's SLAX, which is okay-ish but it becomes clear very fast that it's indeed just Syntax sugar
* there's XSLT 2.0 but there's no software support
* nobody uses it, there's no network effect in usage
I think a few years ago I stumbled upon a CMS that uses it and once I accidentally stumbled upon a Website that uses XSLT transformation for styling. That's all XSLT I ever saw in the wild being actually used.
All in all XSLT is a useless part of the way to large long tail preventing virtually everyone from writing spec compliant web browser engines.
> The promise is, "This is HTML. Count on it."
I think after HTML4 and XHTML people saw that a fully rigid standard isn't viable, so they made HTML5 a living standard with a plethora of working groups. Therefore the times where this was ever supposed to be true are long over anyway.
So indeed the correct way forward would be to remove more parts of a long tail that's hardly in use and stopping innovation. And instead maybe keeping a short list of features that allow writing modern websites.
(Also nobody is stopping anyone from using XSLT as primary language that compiles to HTML5/ES5/CSS)
Should we remove XSLT from the web platform? – 4 days ago (89 comments):
https://news.ycombinator.com/item?id=44909599
XSLT – Native, zero-config build system for the Web – 27th June 2025 (328 comments):
https://news.ycombinator.com/item?id=44949857
Google is killing the open web, today, 127 comments
Imagine that tomorrow, Google announces plans to stop supporting HTML and move everyone to its own version of "CompuServe", delivered only via Google Fiber and accessible only with Google Chrome. What headline would you suggest for that occasion? "Google is killing the open web" has already been used today on an article about upcoming deprecation of XSLT format.
I've taken the flags off that post now.
The flagged post is a perfect example. It contains just a fraction of factual information, but it was enough for bot farms to engage. Manipulators get mad at truth.
The browsers today are too bloated and it is difficult to create a new browser engine. I wish there were simpler standards for "minimal browser", for example, supporting only basic HTML tags, basic layout rules, WASM and Java bytecode.
Many things, like WebAudio or Canvas, could be immplemented using WASM modules, which as a side effect, would prevent their use for fingerprinting.
XSLT is a specification for a "template engine" and not a specific engine. There are dozens of XSLT implementations.
Mozilla notably doesn't use libxslt but transformiix: https://web.mit.edu/ghudson/dev/nokrb/third/firefox/extensio...
> and not Jinja for example?
Jinja operates on text, so it's basically document.write(). XSLT works on the nodes itself. That's better.
> Also it can be reimplemented using JS or WASM.
Sort of. JS is much slower than the native XSLT transform, and the XSLT result is cacheable. That's huge.
I think if you view XSLT as nothing more than ancient technology that nobody uses, then I can see how you could think this is ok, but I've been looking at it as a secret weapon: I've been using it for the last twenty years because it's faster than everything else.
I bet Google will try and solve this problem they're creating by pushing AMP again...
> The browsers today are too bloated
No, Google's browser today is too bloated: That's nobody's fault but Google.
> and it is difficult to create a new browser engine
I don't recommend confusing difficult to create with difficult to sell unless you're looking for a reason to not do something: There's usually very little overlap between the two in the solution.
Perhaps there's an alternative universe where javascript lost and an elegant, declarative XSLT could declaratively present data and incrementally download only what's needed, allowing compact and elegant websites.
But in our universe today, this mapping language wound-up a half-thought-idea that just kicked around for a long time in the specs without ever making sense.
Serving a server-generated HTML page could be even faster.
Except it isn't.
Lots of things could be faster than they are.
The XSLT can also be served once, and then cached for a very long time period, and the XML can be very small.
Nobody is going to process million of DOM nodes with XSLT because the browser won't be able to display them anyway. And one can write a WASM implementation.
You're right nobody processes a million DOM nodes with XSLT in a browser, but you're wrong about everything else: WASM has a huge startup cost.
Consider applying stylesheet properties: XSLT knows exactly how to lay things out so it can put all of the stylesheet properties directly on the element. Pre-rendered HTML would be huge. CSS is slow. XSLT gets you direct-attach, small-payload, and low-latency display.
XSLT is a templating language (like HTML is a content language), not a template engine like Blink or WebKit is a browser engine.
> Also it can be reimplemented using JS or WASM.
Changing the implementation wouldn't involve taking the language out of the web platform. There wouldn't need to be any standardization talk about changing the implementation used in one or more browsers.
They actually thought about it, and decided not to do it :-/
Audio and canvas are fundamental I/O things. You can’t shift them to WASM.
You could theoretically shift a fair bit of Audio into a WASM blob, just expose something more like Mozilla’s original Audio Data API which the Web Audio API defeated for some reason, and implement the rest atop that single primitive.
2D canvas context includes some rendering stuff that needs to match DOM rendering. So you can’t even just expose pixel data and implement the rest of the 2D context in a WASM blob atop that.
And shifting as much of 2D context to WASM as you could would destroy its performance. As for WebGL and WebGPU contexts, their whole thing is GPU integration, you can’t do that via WASM.
So overall, these things you’re saying could be done in WASM are the primitives, so they definitely can’t.
Actually, most of the time C# decompiles nicer from CLR bytecode than esoterically built JS.
But at the end of the day, you only really need one, and the type attribute was phased out of the script tag entirely, and Javascript won.
It is actively used today.
Historic reasons, and it sounds like they want it to contain zero template engines. You could transpile a subset of Jinja or Mustache to XSLT, but no one seems to do it or care.
The funny thing? No, they want to create a new one: https://github.com/WICG/webcomponents/issues/1069
Still the best framework I've ever worked with.
Because XSLT is part of the web standards.
[0] ~0.001% usage according to one post there
This is still a massive number of people who are going to be affected by this.
They arguably became a victim of their own scale.
For better or worse, http is no longer just for serving textual documents.
Would make it possible to create spec-compliant browsers with a subset of the web platform, fulfilling different use cases without ripping out essentials or hacking them in.
I think a dedicated unsupported media type -> supported media type WASM transformation interface would be good. You could use it for new image formats and the like as well. There are things like JXL.js that do this:
And no WebAudio and Canvas couldn't be implemented in client WASM without big security implication. If by module you mean inside the browser, them, what is the point of WASM here ?
Fuck javascript, fuck wasm, fuck html, fuck css.
Rebase it all on XML/XPath/XQuery that way you only need ONE parser, one simple engine.
This whole kitchen sink/full blown OS nonsense needs to end.
Edit: You’re clearly a wasm shill, wasm is an abomination that needs to die.
I wonder what the next step of removing less-popular features will be. Probably the SMIL attributes in favor of CSS for SVG animations, they've been grumbling about those for a while. Or maybe they'll ultimately decide that they don't like native MathML support after all. Really, any functionality that doesn't fit in the mold of "a CSS attribute" or "a JS method" is at risk, including most things XML-related.
Which is miles better than having to having to use calcs for CSS animation timing which requires a kludge of CSS variables/etc to keep track of when something begins/ends time-wise, if wanting to avoid requiring Javascript. And some years ago Firefox IIRC didn't even support time-based calcs.
When Chromium announced the intent to deprecate SMIL a decade back (before relenting) it was far too early to consider that given CSS at that time lacked much of what SMIL allowed for (including motion along a path and SVG attribute value animations, which saw CSS support later). It also set off a chain of articles and never-again updated notes warning about SMIL, which just added to confusion. I remember even an LLM mistakenly believing SMIL was still deprecated in Chromium.
And there's one of the issues: browser devs are perfectly happy if user JS can be used to replicate some piece of functionality, since then it's not their problem.
Is that a good thing or a bad thing?
Technical people like us have our desires. But the billions of people doing banking on their browsers probably have different priorities.
In any case, there's no limit on how far one can disregard compatibility in the name of security. Just look at the situation on Apple OSes, where developers are kept on a constant treadmill to update their programs to the latest APIs. I'd rather not have everything trend in that direction, even if it means keeping shims and polyfills that aren't totally necessary for modern users.
It's that why Chrome unilaterally releases 1000+ web APIs a year, many of them quite complex, and spanning a huge range of things to go wrong (including access to USB, serial devices etc.)? To reduce the attack surface?
When did they do that? Can I not still ftp://example.com in the url bar?
XML was unfairly demonized for the baggage that IBM and other enterprise orgs tied to it, but the standard itself was frigging amazing and powerful.
Converting a simple manually edited xml database of things to html was awesome. What I mostly wanted the ability to pass in a selected item to display differently. That would allow all sorts of interactivity with static documents.
> my main concern is for the “long tail” of the web—there's lots of vital information only available on random university/personal websites last updated before 2005
It's a strong argument for me because I run a lot of old webpages that continue to 'just work', as well as regularly getting value out of other people's old pages. HTML and JS have always been backwards compatible so far, or at least close enough that you get away with slapping a TLS certificate onto the webserver
But I also see that we can't keep support for every old thing indefinitely. See Flash. People make emulators like Ruffle that work impressively well to play a nostalgic game or use a website on the Internet Archive whose main menu (guilty as charged) was a Flash widget. Is that the way we should go with this, emulators? Or a dedicated browser that still gets security updates, but is intended to only view old documents, the way that we see slide film material today? Or some other way?
[0]: https://chromewebstore.google.com/detail/xslt-polyfill/hlahh...
Too heated? Looked pretty civil and reasonable to me. Would it be ridiculous to suggest that the tolerance for heat might depend on how commenters are aligned with respect to a particular vendor?
Google ignored everything, pushed on with the removal, and now pre-emptively closed this discussion, too
To be fair to Google, they've consistently steam-rolled the standards processes like that for as long as I can remember, so it really isn't new.
I find people on HN are often very motivated reasoners when it comes to judging civility, but there’s basically no excuse for calling people “fuckers” or whatever.
> We didn't forgot your decade of fuckeries, Google.
> You wanted some heated comment? You are served.
> the JavaScript brainworm that has destroyed the minds of the new generation
> the covert war being waged by the WHATWG
> This is nothing short of technical sabotage, and it’s a disgrace.
> breaking yet another piece of the open web you don't find convenient for serving people ads and LLM slop.
> Are Google, Apple, Mozilla going to pay for the additional hosting costs incurred by those affected by the removal of client-side XSLT support?
> Hint: if you don't want to be called out on your lies, don't lie.
> Evil big data companies who built their business around obsoleting privacy. Companies who have built their business around destroying freedom and democracy.
> Will you side with privacy and freedom or will you side with dictatorship?
Bullshit like this has no place in an issue tracker. If people didn’t act like such children in a place designed for productive conversation, then maybe the repo owners wouldn’t be so trigger happy.
Two years ago, I created a book in memory of a late friend to create a compilation of her posts on social media. Again, thanks to XSLT, it was a breeze.
XSLT has been orphaned on the browser-side for the last quarter century, but the story on the server-side isn't better either. I think that the only modern and comprehensive implementation comes with Saxon-JS which is bloated and has an unwieldy API for JavaScript.
Were XSLT dropped next year, what would be the course of action for us who rely on browser-based XSLT APIs?
XSLT, especially 3.0, is immensely powerful, and not having good solutions on JS ecosystem would make the aftermath of this decision look bleaker.
And if you’re leaning towards a declarative framework, use React.
Ex. https://source.chromium.org/chromium/chromium/src/+/main:thi...
https://source.chromium.org/chromium/chromium/src/+/main:thi...
https://github.com/WebKit/WebKit/blob/65b2fb1c3c4d0e85ca3902...
Mozilla has an in-house implementation at least:
https://github.com/mozilla-firefox/firefox/tree/5f99d536df02...
It seems like the answer to the compat issue might be the MathML approach. An outside vendor would need to contribute an implementation to every browser. Possibly taking the very inefficient route since that's easy to port.
My first job in software was as a software test development intern at a ~500 employee non-profit, in about 2008 when I was about 19 or 20 years old. Writing software to test software. One of my tasks during the 2 years I worked there was to write documentation for their XML test data format. The test data was written in XML documents, then run through a test runner for validation. I somehow found out about XSLT and it seemed like the perfect solution. So I wrote up XML schemas for the XML test data, in XSD of course. The documentation lived in the schema, alongside the type definitions. Then I wrote an XSLT document, to take in those XML schemas and output HTML pages, which is also basically XML.
So in effect what I wrote was an XML program, which took XML as input, and outputted XML, all entirely in the browser at document-view time.
And it actually worked and I felt super proud of it. I definitely remember it worked in our official browser (Internet Explorer 7, natch). I recall testing it in my preferred browser, Firefox (version 3, check out that new AwesomeBar, baby), and I think I got it working there, too, with some effort.
I always wonder what happened with that XML nightmare I created. I wonder if anyone ever actually used it or maybe even maintained it for some time. I guess it most likely just got thrown away wholesale during an inevitable rewrite. But I still think fondly back on that XSLT "program" even today.
I wrote my personal website in XML with XSLT transforming into something viewable in the browser circa 2008. I was definitely inspired by CSS Zen Garden where the same HTML gave drastically different presentation with different CSS, but I thought that was too restrictive with too much overly tricky CSS. I thought the code would be more maintainable by writing XSLT transforms for different themes of my personal website. That personal webpage was my version of the static site generator craze: I spent 80% of the time on the XSLT and 20% on the content of the website. Fond memories, even though I found XSLT to be incredibly difficult to write.
My first rewrite of my site, as I moved it away from Yahoo, into my own domain was also in XSLT/XML.
Eventually I got tired of keeping it that way, and rewrite the parsing and HTML generation into PHP, but kept the site content in XML, to this day.
Every now and then I think about rewriting it, but I rather do native development outside work, and don't suffer from either PHP nor XML allergies.
Doing declarative programming in XSLT was cool though.
At the end of the (very long) process, I just hard-coded the reference request XML given by the particularly problematic endpoints, put some regex replacements behind it, and called it a day.
Imagine people put energy into writing that thick of a book about XML. To be filed into the Theology section of a library
"Saxonica today counts some of the world's largest companies among its customer base. Several of the world's biggest banks have enterprise licenses; publishers around the world use Saxon as a core part of their XML workflow; and many of the biggest names in the software industry package Saxon-EE as a component of the applications they distribute or the services they deploy on the cloud."
So the libxml/libxslt unpaid volunteer maintainer wants to stop doing 'disclosure embargo' of reported security issues: https://gitlab.gnome.org/GNOME/libxml2/-/issues/913 Shortly after that, Google Chrome want to remove XSLT support.
Coincidence?
Source (yawaramin): https://news.ycombinator.com/item?id=44925104
PS: Seems libxslt which is used by Blink has an (unpaid) maintainer but nothing going on there really, seems pretty unmaintained https://gitlab.gnome.org/GNOME/libxslt/-/commits/master?ref_...
PS2: Reminds me all of this https://xkcd.com/2347/ A shame that libxml and libxslt could not get more support while used everywhere. Thanks for all the hard work to the unpaid volunteers!
It'd be much better that Google did support the maintainer, but given the apparent lack of use of XSLT 1.0 and the maintainer already having burned out, stopping supporting XSLT seems like the current best outcome:
> "I just stepped down as libxslt maintainer and it's unlikely that this project will ever be maintained again"
The suggestion of using a polyfill is a bit nonsensical as I suspect there is little new web being written in XSLT, so someone would have to go through all the old pages out there and add the polyfill. Anyone know if accomplishing XSLT is possible with a Chrome extension? That would make more sense.
Cool example with the recipes page :)
There are also very valid comments in there about why removal would still hurt existing sites and applications, especially for embedded devices.
https://github.com/whatwg/html/pull/11563#issuecomment-31970...
If there is a polyfill I'm not sure making it in Javascript makes sense but web assembly could work.
See the agenda here: https://github.com/whatwg/html/issues/11131#issuecomment-274...
Like 90%+ of internet traffic goes to a handful of sites owned by tech giants. Most of what's left is SEO garbage serving those same tech giants' ad networks.
I agree RSS parsing is nice to have built into browsers. (Just like FTP support, that I genuinely miss in Firefox nowadays, but allegedly usage was too low to warrant the maintenance.) I also don't really understand the complaint from the Chrome people that are proposing it: "it's too complex, high-profile bugs, here's a polyfill you can use". Okay, why not stuff that polyfill into the browser then? Then it's already inside the javascript sandbox that you need to stay secure anyway, and everything just stays working as it was. Replacing some C++ code sounds like a win for safety any day of the week
On the other hand, I don't normally view RSS feeds manually. They're something a feed parser (in my case: Blogtrottr and Antennapod) would work with. I can also read the XML if there is a reason for me to ever look at that for some reason, or the server can transform the RSS XML into XHTML with the same XSLT code right? If it's somehow a big deal to maintain, and RSS is the only thing that uses it, I'm also not sure how big a deal it is to have people install an extension if they view RSS feeds regularly on sites where the server can do no HTML render of that information. It's essentially the same solution as if Chrome would put the polyfill inside the browser: the browser transforms the XML document inside of the JS sandbox
I think the principle behind it is wonderful. https://www.example.com/latest-posts is just an XML file with the pure data. It references an XSLT file which transforms that XML into a web page. But I've tried using it in the past and it was such a pain to work with. Representing things like for loops in markup is a fundamentally inefficient thing to do, JavaScript based templating is always going to win out from the developer experience viewpoint, especially when you're more than likely going to need to use JS for other stuff anyway.
It's one of those purist things I yearn for but can never justify. Shipping XML with data and a separate template feels so much more efficient than pre-prepared HTML that's endlessly repetitive. But... gzip also exists and makes the bandwidth savings a non-issue.
It may be that I don't notice when I use it, if the page just translates itself into XHTML and I would never know until opening the developer tools (which I do often, fwiw: so many web forms are broken that I have a habit of opening F12, so I always still have my form entries in the network request log). Maybe it's much more widespread than I knew of. I have never come across it and my job is testing third-party websites for security issues, so we see a different product nearly every week (maybe those sites need less testing because they're not as commonly interactive? I may have a biased view of course)
I think I've read some governments still use it, which would make sense since they usually don't have a super high budget for tons of developers, so they have to stick to the easy way to do things.
As much of a monopoly as Chrome is, if they actually try to remove it they're likely to get a bunch of government web pages outright stating "Chrome is unsupported, please upgrade to Firefox or something".
Practically every WordPress site with one of the top two SEO plugins (I'm not familiar with others) serves XML sitemaps with XSLT. It's used to make the XML contents human readable and to add a header explaining what it is.
Especially considering the amount of complex standards they have qualms about from WebUSB to 20+ web components standards
> On the other hand, I don't normally view RSS feeds manually.
Chrome metrics famously underrepresent corporate installation. There could be quite a few corporate applications using XSLT as it was all the rage 15-20 years ago.
XSLT (and basically anything else that existed when HTML5 turned ten years old) is old code using old quality standards and old APIs that still need to be maintained. Browsers can rewrite them to be all new and modern, but it's a job very few people are interested in (and Google's internal structure heavily prioritizes developing new things over maintaining old stuff).
Nobody is making a promotion by modernizing the XSLT parser. Very few people even use XSLT in their day to day, and the biggest product of the spec is a competitor to at least three of the four major browser manufacturers.
XSLT is an example of exciting tech that failed. WebSerial is exciting tech that can still prove itself somehow.
The corporate installations still doing XSLT will get stuck running an LTS browser like they did with IE11 and the many now failed strains of technology that still supports (anyone remember ActiveX?).
You'd use XSLT to translate your data into a webpage. Or a mobile device that supported WML/WAP. Or a desktop application.
That was the dream, anyhow.
5G was another hype word. Can't say that's not useful! I don't really notice a difference with 4G (and barely with 3G) but apparently on the carrier side things got more efficient and it is very widely adopted
I guess there's a reason the Gartner hype cycle ends with widespread adoption and not with "dead and forgotten": most things are widely picked up for a reason. (Having said that, if someone can tell me what the unique selling point of an NFT was, I've not yet understood that one xD)
Which means more unreadable code.
But if they decide to remove XSLT from spec, I would be more than happy if they remove JS too. The same logic applies.
XSLT 1.0 is still useful though, and absolutely shouldn't be removed.
Them: "community feedback" Also them: <marks everything as off topic>
This came about after the maintainer of libxml2 found giving free support to all these downstream projects (from billionaire and trillionaire companies) too much.
Instead of just funding him, they have the gall to say they don't have the money.
While this may be true in a micocosm of that project, the devs should look at the broader context and who they are actually working for.
Here's what I wish could happen: allow implementers to stub out the XSLT engine and tell users who love it that they can produce a memory-safe implementation themselves if they want the functionality put back in. The passionate users and preservationists would get it done eventually.
I know that's not a good solution because a) new xslt engine code needs to be maintained and there's an ongoing cost for that for very few users, b) security reviews are costly for the new code, c) the stubs themselves would probably be nasty to implement, have security implications, etc. And, there's probably reasons d-z that I can't even fathom.
It sucks to have functionality removed/changed in the web platform. Software must be maintained though; cost of doing business. If a platform doesn't burden you with too much maintenance and chooches along day after day, then it's usually a keeper.
Google definitely throws its weight around too much w.r.t. to web standards, but this doesn't seem too bad. Web specifications are huge and complex so trying to size down a little bit while maintaining support for existing sites is okay IMO.
That breaks old unmaintained but still valuable sites.
(But of course, XML Stylesheets are most widely used with RSS feeds, and Google probably considers further harm to the RSS ecosystem as a bonus. sigh)
I completely understand the security and maintenance burdens that they're bringing up but breaking sites would be unacceptable.
I don't understand the point in having a JS polyfill and then expecting websites to include it if they want to use XSLT stuff. The beauty of the web is that shit mostly just works going back decades, and it's led to all kinds of cool and useful bits of information transfer. I would bet money that so much of the weird useful XSLT stuff isn't maintained as much today - and that doesn't mean it's not content worth keeping/preserving.
This entire issue feels like it would be a nothing-burger if browser vendors would just shove the polyfill into the browser and auto-run it on pages that previously triggered the fear-inducing C++ code paths.
What exactly is the opposition to this? Even reading the linked issue, I don't see an argument against this that makes much sense. It solves every problem the browser vendors are complaining about and nothing functionally changes for end users.
That being said, I'm not against removing features but neither this or the original post provide any substantial rationale on why it should be removed. Uses for XSLT do exist and the alternative is "just polyfill it" which is awkward especially for legacy content.
With how bloated browsers are right now, good riddance IMO
Since it's a microcontroller, modifying that server and pushing the firmware update to users is probably also a pain.
Unusual use case, but an reasonable one.
Quite fun at the time
Removal of anything is problematic though, better off freezing parts of the spec to specific compatibility versions and getting browsers to ship optional compatibility modes that let you load and view old sites.
Yegge called it:
https://steve-yegge.medium.com/dear-google-cloud-your-deprec...
"""
> Because I sometimes get similar letters from the Google Cloud Platform. They look like this:
>> Dear Google Cloud Platform User,
>> We are writing to remind you that we are sunsetting [Important Service you are using] as of August 2020, after which you will not be able to perform any updates or upgrades on your instances. We encourage you to upgrade to the latest version, which is in Beta, has no documentation, no migration path, and which we have kindly deprecated in advance for you.
>> We are committed to ensuring that all developers of Google Cloud Platform are minimally disrupted by this change.
>> Besties Forever,
>> Google Cloud Platform
> But I barely skim them, because what they are really saying is:
>> Dear RECIPIENT,
>> Fuck yooooouuuuuuuu. Fuck you, fuck you, Fuck You. Drop whatever you are doing because it’s not important. What is important is OUR time. It’s costing us time and money to support our shit, and we’re tired of it, so we’re not going to support it anymore. So drop your fucking plans and go start digging through our shitty documentation, begging for scraps on forums, and oh by the way, our new shit is COMPLETELY different from the old shit, because well, we fucked that design up pretty bad, heh, but hey, that’s YOUR problem, not our problem.
>> We remain committed as always to ensuring everything you write will be unusable within 1 year.
>> Please go fuck yourself,
>> Google Cloud Platform
"""
Almost no one ever uses it: metrics show only around 0.02% of phone calls use this feature. So we’re planning on deprecating and then removing it.
—⁂—
Just an idea that occurred to me earlier today. XSLT doesn’t get a lot of use, but there are still various systems, important systems, that depend upon it. Links to feeds definitely want it, but it’s not just those sorts of things.
Percentages only tell part of the story. Some are tiny features that are used everywhere, others are huge features that are used in fewer places. Some features can be removed or changed with little harm—frankly, quite a few CSS things that they have declined to address on the grounds of usage fall into this category, where a few things would be slightly damaged, but nothing would be broken by it. Other features completely destroy workflows if you change or remove them—and XSLT is definitely one of these.
I know this is for security reason but why not update the XSLT implementation instead. And if feature that aren't used get dropped, they might as well do it all in one good. I am sure lots of HTML spec aren't even used.
I am of the opinion that it is to remove one of the last ways to build web applications that don't have advertising and tracking injected into them.
Er, how so? What stops you from doing so in HTML/JS/CSS ?
Google is boneheaded and hostile to open web at this point, explicitly.
Go changed their telemetry to opt-in based on community feedback, so I'm not sure what point you're trying to make with that example.
Probably a browser extension on the user side can do the same job if an XSLT relying page cannot be updated.
And browsers are too big with too many features; reducing the scope of what a browser does is good (but not enough by itself to remove a feature).
Maybe one day it will come back as a black-box module running in an appropriate sandbox - like I think Firefox uses for PDF rendering.
At least that's how my cynical side feels anymore.
I remember using these things in a CSCI class, and, IIRC, we were using something akin to Tomcat to do transformations on the server, before serving HTML to the browser, circa 2005/2006.
XSLT came across as a little esoteric.
I think that's a tradeoff.
Simplest approach would be to just distribute programs, but the Web is more than that!
Another simple approach would be to have only HTML and CSS, or even only HTML, or something like Markdown, or HTML + a different simple styling language...
and yet nothing of that would offer the features that make web development so widespread as a universal document and application platform.
But like, most people just want a site to work and provide value, save them time etc and the way the site is built is entirely unimportant. I find myself moving towards that side despite being somewhat of a web purist for years.
[0]: https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/...
[1]: https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/...
The W3C's plan was for HTML4 to be replaced by XHTML. What we commonly call HTML5 is the WHATWG "HTML Living Standard."
no wonder they were sidelined
Which Chrome has transmuted into "we do whatever we want to do". Remember their attempt to remove confirm/prompt?
How do you apply this to documents? They are so different. XML gives the answer: you INVENT a notation that suits just your case and use it. This way you perfectly solve the enigma of semantic.
OK, fine, but what to do with my invented notation? Nobody understands it. Well, that is OK. You want to render it as HTML; HTML has no idea about you notation, but is (was) also a kind of XML, so you write a transformation from your notation to HTML. Now you want to render it for printed media: here is XSL-FO, go ahead. Or maybe you want to let blind people read your document too; here is (a non-existent) AUDIO-ML, just add a transformation into this format. In fact there could be lots of different notations for different purposes (search, for instance) and they are all within a single transformation step.
And for that transformation we give you a tool: XSLT.
(I remember a piece discussed here; it was about different languages and one of examples of very simple languages was XSLT. It is my impression as well; XSLT is unconventional, but otherwise very simple.)
Of course you do not have to invent a new notation each time. It's equally fine to invent small specific notations and mix them with yours.
For example, imagine a specific chess notation. It allows you to describe positions and a sequence of moves, giving you either a party or a composition. You write about chess and add snippets in this notation. First, it can be very expressive; referring to a position should take no more than:
<position party="#myparty" move="22w" />
<moves party="#myparty" from="22w" to "25b" />
And then imagine a specific search engine that crawls the web, indexes parties and compositions and then can search, for example, for other pages that discuss this party, or for similar positions, or for matching sequences of moves.
XML even had a foundation to incorporate other notations. XML itself is, indeed, verbose (although this can be lessened with a good design, which is rare), but starting from v1.0 it has a way to formally indicate that contents of an element are written in a specific notation. If that direction was followed it could lead to things like:
<math notation="latex">...</math> <math notation="asciimath">...</math>
The vision of XML was federated web. Lots of notations, big and small, evolving and mixing. It was dismissed on the premise it was too strict. I myself think it was too free.
Nothing is stopping you from using content negotiation to do it server side.