If I understand correctly, Mozilla and Apple don’t really want to support it either. And the reason for that is, the spec is still at XSLT 1.0, which is super old, and current implementations are effectively abandonware. Catch-22?

It doesn't seem weird at all to me: standard is essentially the consensus of the major browser vendors; a spec which all of Chrome, Safari and Edge don't implement is really just a hypothetical.

The origin story of whatwg is that Apple, Mozilla and Opera decided that W3C wasn't making specs that they wanted to implement, so they created a new working group to make them.

> nobody bats an eye

I’ve seen a lot of eye-batting about this. Although Google, Mozilla and Apple are all in favour of removing it, there’s been a lot of backlash from developers.

Even "champion of the web" Mozilla is on board. Tells you exactly what you need to know.

To be fair, some things should be legitimately considered to be removed from the standard. O.G. XHTML basically mandated that you accept XML logic bombs and we got over that.

Also, while this is certainly Google throwing their weight around, I don’t think they are doing it for monetary advantage. I’m not sure how removing XSLT burnishes their ad empire the way things like nerfing ManifestV3 have. I think their stated reasons - that libxslt is a security disaster zone for an obscure 90s-era feature - is earnest even if its not actually in the broader web’s best interests. Now that Safari is publicly on board to go second, I suspect it’s an inevitability.

Whilst I can't be certain, I've been hearing that part of Google's want to move away from XSLT is two-fold - and relates to the idea of the security problem.

Partly, there's increasing attacks against XML.

And also, libxml2 has said "no" to security embargoes altogether. [0]

They might well consider there to be 0-days waiting in XSLT.

[0] https://news.ycombinator.com/item?id=44381093

React supports rendering to HTML ahead of time (SSR) which doesn't need any client-side javascript, and this is a prominent feature of most frameworks using React. This feature of React was one of its major innovations over many other front-end frameworks of the time.

I think the big difference there is that browsers are only responsible for Javascript, which is a big general purpose solution that solves a lot of problems and not just templating/styling XML. Everything else either happens server-side (build steps and webpack) or is userland code that lives inside the sandbox. So there's one task for browsers to do (make a fast and secure Javascript sandbox), and if that works that developers can do whatever they want. Whereas XSLT is not a general purpose tool in the same way, and so needs to be maintained in addition to Javascript and anything else that exists.

If course XSLT can also be used server-side (which is probably a good idea if you want access to the latest features and not some ancient, frozen version of the spec), but browsers aren't the reason that that didn't take off. My guess there is that it's just not an intuitive way of manipulating and templating data in comparison to more traditional HTML templating libraries.

I don't think react is comparable.

React's main thinh is client side reactivity, something that xslt doesn't offer.

A closer comparison would be a templating engine.

The meeting referenced there, from March not last month, also gives no indication that they'd go ahead and make any moves - "stick a pin in it". But they did anyway. [0]

panos: next item, removing XSLT. There are usage numbers.

stephen: I have concerns. I kept this up to date historically for Chromium, and I don't trust the use counters based on my experience. Total usage might be higher.

dan: even if the data were accurate, not enough zeros for the usage to be low enough.

mason: is XSLT supported officially?

simon: supported

mason: maybe we could just mark it deprecated in the spec, to make the statement that we're not actively working on it.

brian: we could do that on MDN too. This would be the first time we have something baseline widely available that we've marked as removed.

dan: maybe we could offer helpful pointers to alternatives that are better, and why they're better.

panos: maybe a question for olli. But I like brian's suggestion to mark it in all the places.

dan: it won't go far unless developers know what to use instead.

brian: talk about it in those terms also. Would anyone want to come on the podcast and talk about it? I'm guessing people will have objections.

emilio: we have a history of security bugs, etc.

stephen: yeah that was a big deal

mason: yeah we get bugs about it and have to basically ignore them, which sucks

brian: people do use it and some like it

panos: put a pin in it, and talk with olli next time?

panos: next thing is file upload control rendering

[0] https://github.com/whatwg/html/issues/11146#issuecomment-275...

> Looking at the xslt stylesheet , it doesn't look like there are nested includes, its just one stylesheet which doesn't include anything else

At least the browser has to load template.xsl before it can know it has to load the css file though, right? And this is just a simple demo page.

For a long time web components generally built on four standards:

  - Custom HTML elements
  - Shadow DOM
  - HTML imports
  - HTML templates

https://korban.net/posts/elm/2018-09-17-introduction-custom-...

Eventually it became clear some browsers were not going to implement and the design of HTML imports was better handled be ES modules.

https://webmasters.stackexchange.com/questions/127482/on-wha...

Found this, it should answer your complaints:

> HTML Imports were redundant, since you need JavaScript to bring them alive anyways