5 ms·

As of the next version of Chrome, XSLT will be gated behind a flag. Google have also asked for it to be removed from the standard [0]. [0] https://github.com/

by shakna 1y ago

As of the next version of Chrome, XSLT will be gated behind a flag. Google have also asked for it to be removed from the standard [0]. [0] https://github.com/WHATWG/html/issues/11523 https://github.com/WHATWG/html/issues/11523

kome 1y ago
so it's time to use XSLT more
notpushkin 1y ago
Yeah, I think that was what prompted this submission. All this has also reignited my idea for a compile-to-XSLT templating language, too – maybe I’ll get to it finally this time; definitely if XSLT 3.0 gets into web standards: https://github.com/whatwg/html/issues/11578 https://github.com/whatwg/html/issues/11578, https://news.ycombinator.com/item?id=44987552 https://news.ycombinator.com/item?id=44987552 Also, I’ve put together a simple XSLT playgroung a while ago! https://xsltbin.ale.sh/ https://xsltbin.ale.sh/
- Evidlo 1y ago
  I was thinking it would be possible to compile a subset of Jinja2 (or your favorite equivalent) into XSL: https://chatgpt.com/share/68a95439-ad54-800a-919f-23caecce4351 https://chatgpt.com/share/68a95439-ad54-800a-919f-23caecce43... Thanks for the playground! I'll check it out.
- bokchoi 1y ago
  I haven't tried it yet, but I came across this alternate syntax for XSLT which is much more friendly: https://github.com/Juniper/libslax/wiki/Intro https://github.com/Juniper/libslax/wiki/Intro
SnuffBox 1y ago
I find it bizarre that Google can just ask for a feature to be removed from standard and nobody bats an eye.
- notpushkin 1y ago
  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?
  - ekianjo 1y ago
    The spec is at XLST 3 right now.
    - abraham 1y ago
      Browsers only implement XSLT 1 https://meyerweb.com/eric/thoughts/2025/08/22/no-google-did-not-unilaterally-decide-to-kill-xslt/ https://meyerweb.com/eric/thoughts/2025/08/22/no-google-did-...
      - ekianjo 1y ago
        We were talking about the spec, not the implementation.
    - JW_00000 1y ago
      When notpushkin said "the spec is still at XSLT 1.0", I think "the spec" is referring to the WHATWG HTML Living Standard spec, which only refers to XSLT 1.0. (It wouldn't make sense to say "the XSLT spec is at XSLT 1.0".)
      - notpushkin 1y ago
        Exactly. Thanks!
  - johncolanduoni 1y ago
    I believe the spec is at XSLT 3.0 but no browser actually implemented past XSLT 1.0 (not 100% sure - almost nobody cared about this feature last month so hard to find good docs on support). HTML5 and C++ are cut from the same cloth - massive and no reference implementation so full of features that have been “standard” for 10 years but never implemented by anyone.
simpaticoder 1y ago
It's kind of too bad XSLT didn't take off. It is quite complex, until you compare it to the complexity of what now solves this problem (e.g. a build step with React and webpack and javascript absolutely required on the client-side). As the OP ably demonstrates, XSLT provides a declarative, non-javascript, non-build way to solve the basic HTML component problem. Perhaps a devastating 0-day in V8 will make us really, really want an alternative to the current best practice.
- shakna 1y ago
  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 https://news.ycombinator.com/item?id=44381093
- AgentME 1y ago
  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.
  - degamad 1y ago
    > React supports rendering to HTML ahead of time (SSR)... So does XSLT?
    - throwaway290 1y ago
      Literally not one person said XSLT can't do it. But in case you missed it somebody did said React can't do it and so XSLT is better. > build step with React and webpack and javascript absolutely required on the client-side This was a false statement. both XSLT and React can be used for this except React can additionally do a bunch of other stuff that does use JS and that XSLT can't do.
chrismorgan 1y ago
> As of the next version of Chrome, XSLT will be gated behind a flag. Citation? That would greatly surprise me in its abruptness and severity (they only just started talking about it this month, and acknowledge it’s particularly risky for enterprise) and https://chromestatus.com/feature/4709671889534976 https://chromestatus.com/feature/4709671889534976 gives no such indication.
- shakna 1y ago
  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-2759059949 https://github.com/whatwg/html/issues/11146#issuecomment-275...
  - magicalist 1y ago
    > But they did anyway. Did what? The GP asked for a citation for XSLT support going behind a flag in the next version of Chrome, but you forgot to add that. As best as I can tell, the GP is right and you're confused.

by shakna 1y ago

kome 1y ago

so it's time to use XSLT more

notpushkin 1y ago

Yeah, I think that was what prompted this submission. All this has also reignited my idea for a compile-to-XSLT templating language, too – maybe I’ll get to it finally this time; definitely if XSLT 3.0 gets into web standards: https://github.com/whatwg/html/issues/11578 https://github.com/whatwg/html/issues/11578, https://news.ycombinator.com/item?id=44987552 https://news.ycombinator.com/item?id=44987552 Also, I’ve put together a simple XSLT playgroung a while ago! https://xsltbin.ale.sh/ https://xsltbin.ale.sh/

Evidlo 1y ago
I was thinking it would be possible to compile a subset of Jinja2 (or your favorite equivalent) into XSL: https://chatgpt.com/share/68a95439-ad54-800a-919f-23caecce4351 https://chatgpt.com/share/68a95439-ad54-800a-919f-23caecce43... Thanks for the playground! I'll check it out.
bokchoi 1y ago
I haven't tried it yet, but I came across this alternate syntax for XSLT which is much more friendly: https://github.com/Juniper/libslax/wiki/Intro https://github.com/Juniper/libslax/wiki/Intro

SnuffBox 1y ago

I find it bizarre that Google can just ask for a feature to be removed from standard and nobody bats an eye.

notpushkin 1y ago
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?
- ekianjo 1y ago
  The spec is at XLST 3 right now.
  - abraham 1y ago
    Browsers only implement XSLT 1 https://meyerweb.com/eric/thoughts/2025/08/22/no-google-did-not-unilaterally-decide-to-kill-xslt/ https://meyerweb.com/eric/thoughts/2025/08/22/no-google-did-...
    - ekianjo 1y ago
      We were talking about the spec, not the implementation.
  - JW_00000 1y ago
    When notpushkin said "the spec is still at XSLT 1.0", I think "the spec" is referring to the WHATWG HTML Living Standard spec, which only refers to XSLT 1.0. (It wouldn't make sense to say "the XSLT spec is at XSLT 1.0".)
    - notpushkin 1y ago
      Exactly. Thanks!
- johncolanduoni 1y ago
  I believe the spec is at XSLT 3.0 but no browser actually implemented past XSLT 1.0 (not 100% sure - almost nobody cared about this feature last month so hard to find good docs on support). HTML5 and C++ are cut from the same cloth - massive and no reference implementation so full of features that have been “standard” for 10 years but never implemented by anyone.

simpaticoder 1y ago

It's kind of too bad XSLT didn't take off. It is quite complex, until you compare it to the complexity of what now solves this problem (e.g. a build step with React and webpack and javascript absolutely required on the client-side). As the OP ably demonstrates, XSLT provides a declarative, non-javascript, non-build way to solve the basic HTML component problem. Perhaps a devastating 0-day in V8 will make us really, really want an alternative to the current best practice.

shakna 1y ago
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 https://news.ycombinator.com/item?id=44381093
AgentME 1y ago
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.
- degamad 1y ago
  > React supports rendering to HTML ahead of time (SSR)... So does XSLT?
  - throwaway290 1y ago
    Literally not one person said XSLT can't do it. But in case you missed it somebody did said React can't do it and so XSLT is better. > build step with React and webpack and javascript absolutely required on the client-side This was a false statement. both XSLT and React can be used for this except React can additionally do a bunch of other stuff that does use JS and that XSLT can't do.

chrismorgan 1y ago

> As of the next version of Chrome, XSLT will be gated behind a flag. Citation? That would greatly surprise me in its abruptness and severity (they only just started talking about it this month, and acknowledge it’s particularly risky for enterprise) and https://chromestatus.com/feature/4709671889534976 https://chromestatus.com/feature/4709671889534976 gives no such indication.

shakna 1y ago
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-2759059949 https://github.com/whatwg/html/issues/11146#issuecomment-275...
- magicalist 1y ago
  > But they did anyway. Did what? The GP asked for a citation for XSLT support going behind a flag in the next version of Chrome, but you forgot to add that. As best as I can tell, the GP is right and you're confused.