"Remove mentions of XSLT from the html spec"

Also, https://github.com/whatwg/html/issues/11523 (Should we remove XSLT from the web platform?) is not a request for community feedback.

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

Former Mozilla and Google (Chrome team specifically) dev here. The way I see what you're saying is: Representatives from Chrome/Blink, Safari/Webkit, and Firefox/Gecko are all supportive of removing XSLT from the web platform, regardless of whether it's still being used. It's okay because someone from Mozilla brought it up.

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.

> Even so, give the cross-vendor support for this is seems likely to proceed at some point.

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.

Also, according to Chrome's telemetry, very, very few websites are using it in practice. It's not like the proposal is threatening to make some significant portion of the web inaccessible. At least we can see the data underlying the proposal here.

Ok thanks, we've dechromed the title above. (Submitted title was "Chrome intends to remove XSLT from the HTML spec".)

The implementations are owned by the implementers. Who owns the actual standard, the implementers or the users?

The responses of some folks on this thread reminds me of this:

https://xkcd.com/1172/

>essentially all the feedback said "no, please don't". And they said "thanks for the feedback, we're gonna do it any way!"?

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.

It would be incredible if we could pull it into the javascript/wasm sandbox and get xslt 3.0 support. The best of both worlds, at the cost of a performance hit on those pages, but not a terrible cost.

It comes with the XML territory that things have versioned schemas and things like namespaces, and can be programmed in XSLT. This typically means that integrations are trivial due to public, reliable contracts.

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.

Google tells you what they're going to do to the web with a question mark on the end.

[flagged]

Web is for all practical purposes ChromeOS, but then people complain about Apple not playing ball.

WHATWG broke this quasi-officially when they declared HTML a "Living Standard". The HTML spec is not a standard to be implemented anymore, it's just a method of coordinating/announcing what the browser vendors are currently working on.

(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...

Nothing lasts forever, and eventually you have to port, emulate, archive or otherwise deal with very old applications / media. You see this all over the place: physical media, file formats, protocols, retro gaming, etc.

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.

To be completely fair, looking over the lines removed by the PR, there don't appear to be any normative statements requiring HTML handling XSLT unless I missed one.

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.

There's a perverse irony that Google is as responsible as anybody for cramming a crazy amount of new stuff into the HTML/CSS/browser spec that everybody else has to support forever.

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.

> They are removing XSLT just for being a long-tail technology. The same argument would apply to other long-tail web technologies.

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)

Also related, now flagged:

https://news.ycombinator.com/item?id=44949857

Google is killing the open web, today, 127 comments

> This is actually not a bad idea. Why should the browser contain a specific template engine, like XSLT

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.

> Why should the browser contain a specific template engine, like XSLT,

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.

The old, bug-ridden native XSLT code could also be shipped as WASM along with the browser rather than being deprecated. The sandbox would nullify the exploits, and avoid breaking old sites.

They actually thought about it, and decided not to do it :-/

> Many things, like WebAudio or Canvas, could be immplemented using WASM modules, which as a side effect, would prevent their use for fingerprinting.

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.

Why should the browser contain a specific scripting language, like JavaScript, and not ActiveScript for example?

> Why should the browser contain a specific template engine, like XSLT, and not Jinja for example?

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.

So instead of a complete browser engine we get a basic engine and we need to write the complete on top of it?

>Why should the browser contain a specific template engine, like XSLT

Because XSLT is part of the web standards.

I kind of agree that little used,[0] non-web-like features is fair to be considered for removal. However I wish they didn't hide behind security vulnerabilities as the reason as that clearly wasn't it. The author didn't even bother to look if a memory safe package existed. "We're removing this for your own good" is the worst way to go about it but he still doubles down on this idea later in the thread.

[0] ~0.001% usage according to one post there

Compare webkit to UDK (The unreal development kit for game dev) to consider why there is so much bloat in the browser. People have wanted to render more and more advanced things, and the webkit engine should cater to all of them as best it can.

For better or worse, http is no longer just for serving textual documents.

While this sounds crazy at first, I could warm for several incremental layers of features, where browsers could choose to implement support for only a set of layers. The lowest layer would be something like HTTP with plain text, the next one HTML, then CSS with basic selectors, then CSS with the full selector set, then ECMA and WASM, then device APIs, and so forth.

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.

> Why should the browser contain a specific template engine, like XSLT, and not Jinja for example? Also it can be reimplemented using JS or WASM.

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:

https://github.com/niutech/jxl.js

I get the point a minimal browser and WASM, but Java bytecode ?! Why not Python bytecode ? Seems unreasonable to me to add any specific bytecode support. By layout rules you mean get rid of CSS ? Sounds also unreasonable IMHO.

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 ?

Wasm is ANYTHING but basic.

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.

CSS animations still lack a semantic way to sequence animations based on the beginning/end of some other animation, which SMIL offers. With SMIL you can say 'when this animation ID begins/ends only then trigger this other animation', including time offsets from that point.

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.

> their desire to minimize attack surface trumps any tendency to leave well enough alone.

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.

> their desire to minimize attack surface trumps any tendency to leave well enough alone.

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?

> The writing was on the wall for XSL as soon as the browsers tore out FTP support

When did they do that? Can I not still ftp://example.com in the url bar?

I have to agree. I liked XSLT and would have done much more with just a few additions to it.

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.

It seems like they've already created a browser extension that'll act as as polyfill [0]. Chrome just don't want to ship it & maintain it. Which is very similar to Ruffle.

[0]: https://chromewebstore.google.com/detail/xslt-polyfill/hlahh...

"too heated" is a codeword for "we don't want to deal with dissenting opinions". Same on other forums, e.g. Reddit.

It's a little jarring that the 1 comment visible underneath that is a "Nice, thanks for working on this!", and if you click on the user that wrote it, it's someone working for Google on Chrome... sheesh, kiss-ass much?

There was a discussion they opened to "gather community feedback" just three weeks ago. That one did get heated: https://github.com/whatwg/html/issues/11523

Google ignored everything, pushed on with the removal, and now pre-emptively closed this discussion, too

FYI, I heard that it was Apple employees who administer that repo that marked those comments as off topic and locked the thread, but people are attributing that to the Google employee that opened the issue.

I disagree - I saw a number of comments I would consider rude and unprofessional and once a PR gets posted on HN, frankly it typically gets much worse.

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.

> Why do people create such joke PRs?

> 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.

I’d just use the browsers XML parser and javascript for the transformation. Which is what I assume a putative XSLT javascript library would do.

And if you’re leaning towards a declarative framework, use React.

My XSLT story:

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.

I implemented the full XPath and XSLT language with debugging capabilities for a company I used to work for some 25ish years ago. It was fun (until XPath and XSLT 2. Well that was fun too but because of nice work colleague not the language) but I always did wonder how this took off and Lisp didn’t.

After the XML madness whenever I see some tech being hyped and used all over the place I remember the days of XML and ignore it.

I once attempted to use XSLT to transform SOAP requests generated by our system so the providers' implementation would accept them. This included having to sufficiently grok XSD, WSDL el at to figure out what part of the chain is broken.

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.

“Yo dawg, I heard you liked XML …”

We can laugh at NFTs but honestly there are a lot of technical solutions that fit the "kinda works/kinda seems like a good idea" but in the end it's a house of cards with a vested interest

Imagine people put energy into writing that thick of a book about XML. To be filed into the Theology section of a library

Saxonica is an Employee Ownership Trust and the team as a whole is relatively young (far off from retirement).

"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."

https://www.saxonica.com/about/about.xml

So what do you think about: https://github.com/Paligo/xee ?

This seems totally fine though? XSLT 1.0 supporter says the support time is costing heavily, then Chrome says removing support is fine, which seems to align to both of them.

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"

Mozilla doesn't use libxslt

It would sure be possible to combine a polyfill with a webextension, not sure if XSLT contains any footguns for this approach that would make it hard to do, but if it's solely a single client-side transformation of the initial XML response, this should work fine.

Cool example with the recipes page :)

We absolulely shouldn't be just ripping out support.

If there is a polyfill I'm not sure making it in Javascript makes sense but web assembly could work.

Like how every other browser vendor is supportive and the issue was actually raised by Mozilla?

See the agenda here: https://github.com/whatwg/html/issues/11131#issuecomment-274...

How do you think we got into this mess in the first place? First it was Netscape, then Microsoft, now Google.

But hey it’s totally not a monopoly!

“Free markets and capitalism”. They give us superior, user centered, transparent products.

It's much more general purpose than that. RSS is just XML after all. XSLT basically lets you transform XML into some other kind of markup, usually HTML.

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.

RSS likely isn't the only thing that uses it. XSLT is basically the client side declarative template language for XML/HTML that people always complain doesn't exist (e.g. letting you create your own tags or do includes with no server or build steps).

> 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".

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 was the blockchain, nft, metaverse of the mid?-2000s. Was totally going to solve all of our problems.

No, that would indeed be reasonable, but the proposal is to remove XSLT from the standard and remove Chrome support for XSLT entirely, forcing websites to adopt the polyfill themselves.

Last I checked, it’s a polyfill that Chrome won’t default include - they’re just saying that they’d have a polyfill in JS and it’s on site authors to use.

That breaks old unmaintained but still valuable sites.

The polyfills are something devs have to include and use. It means all the pages that cannot be updated will be broken.

The polyfills suggested are for the servers to do the transforms, not the browser.

Chrome is the dominant browser. Sad as this may be removing it from Blink means de facto removing it from the spec.

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.

By metonymy it's referring to the browser's owner.

Not sure if you missed it, but a few days before this PR, Google did propose removing it from the spec.

They are not talking about pulling in Chromium on a microcontroller. Their web server is on a microcontroller, so they want to minimize server side CPU usage and force the browser to do their XSLT transformation.

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.

I think they're talking about outputting XML+XSLT on those microcontrollers, i.e. just putting out text. Chromium would come in for the viewer who's loading whatever tiny status-webpage those microcontrollers are hosting on a separate device.

They want to punt a half-baked polyfill over the wall and remove support from the browser so they don't have to do any maintenance work, making it someone else's problem.

Or just Xee.

But if you live in a capitalist country with a free market, several competitors should pop out and suggest migrating your system into their cloud for free, shouldn't they? No way capitalist overlooks an unoccupied market niche.

WebKit's in favor: https://github.com/whatwg/html/issues/11523#issuecomment-314...

If it was just for security reasons, they could sponsor FOSS development on the implementation.

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.

KHTML has been discontinued and was barely maintained for several years before. It has not been a relevant party for about a decade if not more.

It’s another “we listened the community and nobody told us no” moment. Like Go’s telemetry issue.

Google is boneheaded and hostile to open web at this point, explicitly.

Looks like they're going to ram it through anyway, no matter the existing users. There's got to be a better way to deal with spam than just locking the thread to anyone with relevant information.

"Heated discussion" sounds like any comment voicing legitimate concern being hidden as "off-topic", and the entire discussion eventually being locked. Gives me Reddit vibes, I hope this is not how open web standards are managed.

If it's a security issue, shouldn't the browsers just replace C++ code with the JS or WASM polyfill themselves?

But at the same time, people don't want web pages and web apps to become all fully opaque like Flutter web or complex, minified JS-heavy sites. Even the latter have many a11y benefits of markup.

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.

The HTML spec is actually constantly evolving. New features like the dialog element [0] and popover [1] were added every year. But removing something from the spec is very rare, if it ever happened before.

[0]: https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/...

[1]: https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/...

The W3C spec was. But WHATWG and HTML5 represent a coup by the dominant browser corporations (read: Google). The biggest browser dictates the "living standard" and the W3C is forced into a descriptivist role.

The W3C's plan was for HTML4 to be replaced by XHTML. What we commonly call HTML5 is the WHATWG "HTML Living Standard."

The WHATWG HTML spec. is famously mutable. They literally call it a “living standard” and it separates them from the versioned W3C standard.

Yep, doesn't this make certain pages not work anymore?

It's immutable in the sense of "only remove stuff after incredibly careful consideration".

Which Chrome has transmuted into "we do whatever we want to do". Remember their attempt to remove confirm/prompt?

Here's the HTML spec: https://chromium.googlesource.com/chromium/

Please don’t.