17 ms·

"Remove mentions of XSLT from the html spec"

• troupo 1y ago
  Despite rather heated discussion just three weeks they started just two weeks prior https://github.com/whatwg/html/issues/11523 https://github.com/whatwg/html/issues/11523
  • webstrand 1y ago
    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.
    • delfinom 1y ago
      WHATWG literally forced W3C to sign a deal and obey their standards. WHATWG is basically Google + Apple + Microsoft directly writing the browser standards. Fixing Microsoft's original mistake of Internet Explorer of not creating a faux committee lol.
      • arccy 1y ago
        w3c architecture astronauts have no place dictating standards that they can't implement.
  • bayindirh 1y ago
    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.
    • agwa 1y ago
      > It’s another “we listened the community and nobody told us no” moment. Like Go’s telemetry issue. 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.
      • bayindirh 1y ago
        No. The official statement from Brian was “I received a couple of personal e-mails from some credible people who stated that their data belonged to them, so we (I) decided to make it opt-in” (paraphrased). I spent days in that thread. That uproar was “a bunch of noisy minority which doesn’t worth listening” for them.
        • arccy 1y ago
          where is this official statement, I don't think you even managed to get the name right
          • bayindirh 1y ago
            Sorry. Was at dinner. It's Russ Cox. Being hungry and in a hurry doesn't help with remembering names. The GitHub discussion is there: https://github.com/golang/go/discussions/58409 https://github.com/golang/go/discussions/58409 but the words I of Russ I cited is here: https://groups.google.com/g/golang-dev/c/73vJrjQTU1M/m/WKj7p0N7AwAJ https://groups.google.com/g/golang-dev/c/73vJrjQTU1M/m/WKj7p... Copying verbatim: It's good to know that's what it looks like. I can tell you that the shouting did not really influence the decision. Long-time Go contributors and supporters commenting quietly or emailing me privately had far greater influence. So as a person who just started programming Go and made some good technical comments didn't matter at all. Only people with clout has mattered, and the voice had to come from the team itself. Otherwise we the users' influence is "fuck all" (sorry, my blood boils every time I read this comment from Russ).
        • rafram 1y ago
          I mean yeah, I too would probably prefer to read a few well-reasoned arguments over email than to wade through hundreds of hateful, vitriolic, accusatory comments from randos in a GitHub thread. Being an open-source maintainer is hard.
  • deleted 1y ago
    [deleted]
  • ummonk 1y ago
    If it's a security issue, shouldn't the browsers just replace C++ code with the JS or WASM polyfill themselves?
    • therealmarv 1y ago
      I also wondered about that. They probably don't want to do that because of maintaining, fixing and allocating resources to it then. Probably a browser extension on the user side can do the same job if an XSLT relying page cannot be updated.
      • ummonk 1y ago
        This seems like the kind of thing that won't require any resources to maintain, other than possible bugfixes (which 3rd parties can provide). It only requires parsing and DOM manipulation, so it doesn't really require any features of JS or WASM that would be deprecated in the future, and the XSLT standard that is supported by browsers is frozen - they won't ever have to dedicate resources to adding any additional features.
        • esprehn 1y ago
          That is an interesting approach, you could suggest it? In general using JS to implement web APIs is very difficult, but using WASM might work especially for the way XSLTProcessor works today.
  • uyzstvqs 1y ago
    "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.
• seydor 1y ago
  Please do
  • bayindirh 1y ago
    Please don’t.
• varbhat 1y ago
  i thought that HTML spec is immutable.
  • tommica 1y ago
    Yep, doesn't this make certain pages not work anymore?
    • onion2k 1y ago
      It makes them not work in Chrome. For any application that supports XSLT they'll continue to work fine.
    • therealmarv 1y ago
      it will. It will make old non-updated pages break with same fate as old outdated pages which used MathML in the past and were not updated with polyfills.
      • mananaysiempre 1y ago
        FYI, MathML is currently shipping (again, after all these years) in Chrome, Firefox, and Safari[1]. [1] https://mathml.igalia.com/ https://mathml.igalia.com/
  • JimDabell 1y ago
    The WHATWG HTML spec. is famously mutable. They literally call it a “living standard” and it separates them from the versioned W3C standard.
  • maxloh 1y ago
    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/Elements/dialog https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/... [1]: https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Global_attributes/popover https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/...
• tomComb 1y ago
  Chrome is a browser – it can’t remove something from the spec. Perhaps this should say Google proposes to remove it from the spec.
  • spystath 1y ago
    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.
    • tomComb 1y ago
      But a browser doesn’t have agency – it’s Google that is doing this.
  • Vosporos 1y ago
    By metonymy it's referring to the browser's owner.
  • NoGravitas 1y ago
    Not sure if you missed it, but a few days before this PR, Google did propose removing it from the spec.
    • tomComb 1y ago
      But that's my point - Google is proposing removing it from the spec. It's kinda weird to reformulate it for the headline as 'Chrome' is doing it.
• exabrial 1y ago
  I love how one company can do whatever they want. This is perfect.
  • icedchai 1y ago
    How do you think we got into this mess in the first place? First it was Netscape, then Microsoft, now Google.
    • raincole 1y ago
      Yet, the web has been prospering for two decades in spite of the quasi-monopoly state of browsers. It's the living evidence that the dominant browser vendor doesn't has as much power as people imagine.
      • meindnoch 1y ago
        The web has been prospering?
        • raincole 1y ago
          "One of the most adopted technologies, the one that is permeating into even native desktop and mobile apps, is not prospering." - HN users, probably.
          • NanoCoaster 1y ago
            There's a difference between web technologies and "the web" as an amorphous philosophical construct. Web technologies, as you stated, are obviously doing just fine. I'd argue the latter isn't. To be more specific, the latter as it was envisioned (in a way that I, and I speculate, GP also still subscribe to) 20+ years ago.
          • account42 1y ago
            "The web" implies an interconnected ecosystem of websites. That the same tech has found adoption with walled gardens is irrelevant.
• dark-star 1y ago
  having browsers transform XML data into HTML via XSLT is a cool feature, and it works completely statically, without any server-side or client-side code. Would be a shame if that was removed. I have a couple dozen XML databases that I made accessible in a browser using xslt...
• JimDabell 1y ago
  Previously: Should we remove XSLT from the web platform? – 4 days ago (89 comments): https://news.ycombinator.com/item?id=44909599 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=44393817 https://news.ycombinator.com/item?id=44393817
  • fuzzy2 1y ago
    Also related, now flagged: https://news.ycombinator.com/item?id=44949857 https://news.ycombinator.com/item?id=44949857 Google is killing the open web, today, 127 comments
    • nicce 1y ago
      Why flagged? The post was reasonable.
      • samrus 1y ago
        [flagged]
      • maratc 1y ago
        Probably labeling a removal of a format (which is somewhat niche anyway) as "killing the open web" was a bit hyperbolic and not entirely warranted in this case. 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.
        • deleted 1y ago
          [deleted]
        • fuzzy2 1y ago
          I agree. I think the article isn't really about the what but about the how. Which does appear to be rather questionable.
• samschooler 1y ago
  The idea of building something like PDF.js makes a lot of sense. I think the core crux of it though is the polyfill should be in the browser, not something that a site maintainer has to manually implement.
  • stuaxo 1y ago
    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.
• Y_Y 1y ago
  > @whatwg whatwg locked as too heated and limited conversation to collaborators 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?
  • troupo 1y ago
    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 https://github.com/whatwg/html/issues/11523 Google ignored everything, pushed on with the removal, and now pre-emptively closed this discussion, too
    • diggan 1y ago
      > 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.
      • recursive 1y ago
        I don't understand how this is any more fair to Google than the quoted statement.
  • sunaookami 1y ago
    "too heated" is a codeword for "we don't want to deal with dissenting opinions". Same on other forums, e.g. Reddit.
    • deleted 1y ago
      [deleted]
  • netsharc 1y ago
    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?
• hypeatei 1y ago
  This proposal seems to be aimed at removing native support in favor of a WASM-based polyfill (like PDF.js, I guess) which seems reasonable? 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.
  • Devasta 1y ago
    The polyfills suggested are for the servers to do the transforms, not the browser.
  • deleted 1y ago
    [deleted]
  • Klonoar 1y ago
    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.
    • hypeatei 1y ago
      Ah, okay. I guess that's another one I'll add to the list of hostile actions towards the web then. I completely understand the security and maintenance burdens that they're bringing up but breaking sites would be unacceptable.
    • pdw 1y ago
      As a user you can only use the polyfill to replace the XSLTProcessor() JavaScript API. You can't use the polyfill if you're using XSLT for XML Stylesheets (<?xml-stylesheet … ?> tags). (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)
      • snackbroken 1y ago
        Moz also has no love for RSS, having removed support for live bookmarks in Firefox 64 (2018) and no longer displaying the RSS icon anywhere in the UI when a website has any <link rel="alternate" type="application/rss+xml"> tags. If you want to subscribe to feeds you have to jump through a bunch of hoops instead of it being a single click. Fortunately, Thunderbird still has support for feeds and doesn't seem to have been afflicted by the same malaise as the rest of the org chart. Who knows how long that will last.
• stuaxo 1y ago
  So annoying, XSLT is very powerful but browsers let it languish at 1.0 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.
• coldpie 1y ago
  I have no opinion on this, just sharing my one-and-only XSLT story. 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.
  • kccqzy 1y ago
    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.
    • eszed 1y ago
      Ha! Shout out to CSS Zen Garden. I didn't go as far down the rabbit hole as you did (noped out before XSLT made its way into my mix), but around that time I made sure all of my html was valid XML (er, XHTML), complete with the little validation badge at the bottom of the page. 80:20 form to content ratio sounds about right.
• lucb1e 1y ago
  I had no idea what XSLT even was until today. Reading the submission, the thread linked by u/troupo below, and Wikipedia, I find that it's apparently used in RSS parsing by browsers, because RSS is XML and then XSLT is "originally designed for transforming XML documents into other XML documents" so it can turn the XML feed into an HTML page 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
  • ndriscoll 1y ago
    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).
    • lucb1e 1y ago
      I understand that there are more possible uses for the tool, but RSS is the only one I saw someone mention. Are there more examples? 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)
• mmastrac 1y ago
  This would be sad, but I think it's sadder that we didn't spend more effort integrating more modern XSLT. It was painful to use _but_ if it had a few revisions in the browser I think it would have been a massive contender to things like React. 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.
  • phkahler 1y ago
    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.
• deleted 1y ago
  [deleted]
• ksec 1y ago
  Do we know Webkit, KHTML and Gecko's stand on this? 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.
  • devmor 1y ago
    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.
    • xcrjm 1y ago
      I get the impression they are ripping it out because they don't want to sponsor the FOSS volunteer working on it or deal w/ maintaining it themselves. The tracking/advertising take doesn't hold much water for me as adding those things to the page is something developers and companies choose to do. You could just as easily inject a tracking script tag or pixel or whatever via XSLT during transformation if you wanted.
    • School-Cotton 1y ago
      > 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 ?
  • ameliaquining 1y ago
    WebKit's in favor: https://github.com/whatwg/html/issues/11523#issuecomment-3149280766 https://github.com/whatwg/html/issues/11523#issuecomment-314...
    • geocar 1y ago
      "Cautiously" in favour.
  • 1y ago
• deleted 1y ago
  [deleted]
• therealmarv 1y ago
  Best comment from another related thread (not from me): 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 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 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_type=HEADS https://gitlab.gnome.org/GNOME/libxslt/-/commits/master?ref_... PS2: Reminds me all of this https://xkcd.com/2347/ 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!
  • franciscop 1y ago
    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"
  • geocar 1y ago
    Mozilla doesn't use libxslt
• aidenn0 1y ago
  I used XSLT once to publish recipes on the web. The cookbook software my mom used (maybe MasterCook?) could "export as xml" and I wrote an xslt to transform it into readable html. It was fine. It's, of course, also possible to run the XSLT from the command line to generate static html. 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.
  • moritzwarhier 1y ago
    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 :)
    • aidenn0 1y ago
      I guess it's time for me to write that webextension; if it gets popular enough I can sell it to someone wearing a black hat for maybe tens of dollars!
      • moritzwarhier 1y ago
        haha good point :( 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-3197060094 https://github.com/whatwg/html/pull/11563#issuecomment-31970...
• magnio 1y ago
  I don't get the people complaining that they need it on their low-power microcontrollers yet instead of using an XSLT library they'd rather pull in Chromium. With how bloated browsers are right now, good riddance IMO
  • kemayo 1y ago
    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.
  • tetromino_ 1y ago
    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.
    • bucklybuck 1y ago
      Yeah, I don't think XML + XLST is any better than or allows anything that sending say JSON and transforming it with JS wouldn't. However that would require changing the firmware, which as you mention may be difficult or impossible.
  • deleted 1y ago
    [deleted]
• codedokode 1y ago
  This is actually not a bad idea. 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. 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.
  • croes 1y ago
    So instead of a complete browser engine we get a basic engine and we need to write the complete on top of it?
    • OsrsNeedsf2P 1y ago
      Sounds like Wayland
  • _ache_ 1y ago
    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 ?
    • codedokode 1y ago
      What WebAudio needs to provide is only means to get or push buffers from/to audio devices and run code in high priority thread. There is no need for browser to provide implementation of low-pass filters, audio proccessing graphs and similar primitives.
    • bigstrat2003 1y ago
      Honestly, even WASM makes it not very minimal in my book. A minimal browser should be HTML and perhaps a subset of CSS, that's it.
• showdeaduser 1y ago
  [dead]
• fithisux 1y ago
  Actually, I think removing XSLT is bad because it means we are more tied to javascript or other languages for XML transformation instead of a language designed for this specific purpose, a DSL. 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.
• spankalee 1y ago
  A few things to note: - This isn't Chrome doing this unilaterally. https://github.com/whatwg/html/issues/11523 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-2759059949 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.
  • spankalee 1y ago
    Also, https://github.com/whatwg/html/issues/11523 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 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 https://gitlab.gnome.org/GNOME/libxml2/-/issues/913
    • xg15 1y ago
      I think this discussion is quite reasonable, but it also highlights the power imbalance: If this stuff is decided in closed meetings and the bug trackers are not supposed to be places for community feedback, where can the community influence such decisions?
      • spankalee 1y ago
        Community feedback is usually very ad hoc. Platform PMs will work with major sites, framework maintainers, and sometimes do discussions and polls on social sites. IOW, they try to go where the community that uses the features are, rather than stay on GitHub in the spec issues.
• nikeee 1y ago
  If security and memory-safety is a concern and there is already a polyfill, why remove the API form the standard instead of just using the WASM-based polyfill internally?
  • kg 1y ago
    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.
• LegionMammal978 1y ago
  Oh hey, that thing happened that one could easily see was going to happen [0]. The writing was on the wall for XSL as soon as the browsers tore out FTP support: their desire to minimize attack surface trumps any tendency to leave well enough alone. 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. [0] https://news.ycombinator.com/item?id=43880391 https://news.ycombinator.com/item?id=43880391
  • timmg 1y ago
    > 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.
    • LegionMammal978 1y ago
      There's ways to reduce attack surface short of tearing out support. Such as, for instance, taking one of those alleged JS polyfills and plugging it into the browser, in place of all the C++. But if attack surface is your sole concern, then one of those options sounds much easier than the other, and also ever-so-slightly superior. 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.
      • intrasight 1y ago
        It is a balance (compatibility vs attach surfaces). The issue with XSLT (which I am still a strong advocate for) is that nobody is maintaining that code. So vulnerabilities sit there undetected. Like the relatively recent discovery of the xsl:document vulnerability.
• BoiledCabbage 1y ago
  So if in reading the two threads correctly essentially Google asked for feedback, essentially all the feedback said "no, please don't". And they said "thanks for the feedback, we're gonna do it any 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. https://github.com/whatwg/html/issues/11523 https://github.com/whatwg/html/issues/11523
  • pjmlp 1y ago
    Web is for all practical purposes ChromeOS, but then people complain about Apple not playing ball.
    • nativeit 1y ago
      > ChromeOS is for all practical purposes, the web. Fixed that typo for you.
      • danans 1y ago
        > > ChromeOS is for all practical purposes, the web 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.
• brian_herman 1y ago
  As long as xpath is still there I approve
• bokchoi 1y ago
  This is tragic. I believe we should have gone the other way and included xslt 3.0 in the baseline browser requirements.
• vcryan 1y ago
  Good
• butlike 1y ago
  I had to look up what XSLT was (began working professionally as a programmer in 2013). Honestly, if it simplifies the spec, at this point it seems like a good idea to remove it. XSLT came across as a little esoteric.
• lucb1e 1y ago
  How do we feel about this concern in general? Not just specific to XSLTs > 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?
  • pityJuke 1y ago
    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/hlahhpnhgficldhfioiafojgdhcppklm?authuser=0&hl=en&pli=1 https://chromewebstore.google.com/detail/xslt-polyfill/hlahh...
• paulvnickerson 1y ago
  I support the html and browser spec being greatly simplified in general. Makes it easier to develop competing browsers.
  • moritzwarhier 1y ago
    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.
    • b_e_n_t_o_n 1y ago
      I think most people just don't care, although the a11y benefits are truely important. HTML isn't going anywhere and often you need JS to make things more accessible. 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.
• panzi 1y ago
  I saw XSLT used to transform RSS feeds into something nicely human readable. That is, the RSS feed was referencing the XSLT. Other than that I haven't noticed the use of XSLT on the web.
• jmull 1y ago
  Breaking the fundamental promise of the HTML spec is a big deal. 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.)
  • magicalist 1y ago
    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.
    • jmull 1y ago
      Their explicit intent is to generally remove XSLT from browsers. 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.
  • foobazgt 1y ago
    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.
• chrismorgan 1y ago
  Intent to remove: emergency services dialling (911, 112, 000, &c.) 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.
• chocmake 1y ago
  This is disappointing. I was using XSLT for transforming SVGs, having discovered it early last year via a chat. Even despite browsers only shipping with v1.0 it still allowed a quite compact way to manipulate them without adding some extra parser dependency.
• Klonoar 1y ago
  Setting aside the discussion of the linked issue itself (tone, comments, etc), I feel like I need to throw this out there: 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.
• j0057 1y ago
  It's not like the browsers can just switch to some better maintained XSLT library. There aren't any. There are about 1.5 closed-source XSLT 3 implementations, Altova and Saxonica. I don't want to sound ageist, but the latter is developed by the XSLT spec's main author, who is nearing retirement age. This library is developed behind closed doors, and from time to time zip files with code get uploaded to GitHub. Make of that what you will in terms of the XSLT community. For all of its elegance, XSLT doesn't seem very relevant if nobody is implementing it. I'm all for the open web, but XSLT should just be left in peace to slide into the good night.
  • timeon 1y ago
    So what do you think about: https://github.com/Paligo/xee https://github.com/Paligo/xee ?
  • dev0001 1y ago
    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 https://www.saxonica.com/about/about.xml
• bambuhoki88 1y ago
  [dead]
• tannhaeuser 1y ago
  If this is in response to Nick Wellnhofers announcement from three months ago to stop embargoing/priorizing libxlst/libxml2 CVEs due to lack of manpower (which I suspect is a consequence of flooding projects with bogus LLM-generated findings from students wanting to butter their profile), wouldn‘t it be possible to ship an emscripten-compiled libxslt implementation instead of libxslt proper?
  • timeon 1y ago
    Or just Xee.
• esprehn 1y ago
  Fwiw the XSLT implementation in Blink and WebKit is extremely inefficient. For example converting the entire document into a string, to parse it to a format that's compatible with libxslt, to then produce a string and parse it back into a node structure again. I suspect a user space library could be similarly as effective. Ex. https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/core/xml/xslt_processor_libxslt.cc;l=312;drc=b8271edbc28fc426d4af05f5878c00c11bc6020f https://source.chromium.org/chromium/chromium/src/+/main:thi... https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/core/xml/xslt_processor.cc;l=131;drc=936810fb4d0e0b979b156d5325a52e5b6c40b088 https://source.chromium.org/chromium/chromium/src/+/main:thi... https://github.com/WebKit/WebKit/blob/65b2fb1c3c4d0e85ca39026e6d25a24638340f3c/Source/WebCore/xml/XSLTProcessorLibxslt.cpp#L266 https://github.com/WebKit/WebKit/blob/65b2fb1c3c4d0e85ca3902... Mozilla has an in-house implementation at least: https://github.com/mozilla-firefox/firefox/tree/5f99d536df020fc1e909179d06a9bac1e6900ae1/dom/xslt/xslt 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.
• Animats 1y ago
  Ouch. Two of my old web sites use XSLT, as a way to display info from a database on administrative pages. I guess it's time to kill off those sites.
• dec0dedab0de 1y ago
  The web is so far gone at this point, they should probably remove everything but wasm. At least that's how my cynical side feels anymore.
• jmorenoamor 1y ago
  I remember having built a static site that was 100% xml data and xslt transformers in the early 2000s Quite fun at the time
• stop_nazi 1y ago
  Finally! Remove this shit!
• sedatk 1y ago
  I love XSLT. I released a client-side XSLT-based PWA last year (https://github.com/ssg/eksi-yedek https://github.com/ssg/eksi-yedek - in Turkish). The reason I had picked XSLT was that the input was in XML, and browser-based XSLT was the most suitable candidate for a PWA. 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.
  • mr_toad 1y ago
    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.
    • timeon 1y ago
      There are many declarative frameworks. React is one of the slowest.
• cnst 1y ago
  Wait, all the web browsers had XSLT support all along? 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.
• Pxtl 1y ago
  So Google is bringing the deprecation treadmill to the web, yay! Yegge called it: https://steve-yegge.medium.com/dear-google-cloud-your-deprecation-policy-is-killing-you-ee7525dc05dc 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 """
  • codedokode 1y ago
    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.
    • fancyfredbot 1y ago
      Oh look over there, is that Azure?
• dwoldrich 1y ago
  The XSLT juice is worth the squeeze, but only to a tiny minority of users, and there's costly rewrites to do to keep XSLT in there (for Chrome, at least.) 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.
• bawolff 1y ago
  As a reminder for people who love xslt. Nothing is stopping you from using content negotiation to do it server side.
• stmw 1y ago
  IBM owns a very high-performance XSLT engine they could probably open source or license to the browser makers. IF anyone from IBM is here (?), may want to consider it..
• dukoid 1y ago
  Ah, now I am glad I stuck with DSSSL :)
• fancyfredbot 1y ago
  I'm sorry but I don't understand this. If a polyfill can add xslt support then why don't browser vendors ship the polyfill and apply it automatically when necessary?
• notnullorvoid 1y ago
  There are better candidates to remove from the spec than XSLT, like HTML. The parsing rules for HTML are terrible and it hinders further advancement of the spec more than anything. The biggest mistake of HTML was back peddling on the switch to XHTML. 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.
• immibis 1y ago
  As much as I think XSLT is cool, if it's used by practically nobody and contains real security vulnerabilities... oh well. You can't deny that combination is a good objective reason to remove it. 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.
• Mikhail_Edoshin 1y ago
  The vision of XML was a semantic web. Nowadays everybody knows that semantic is 'em' and non-semantic is 'b' or 'i'. This is simple, but wrong. In fact a notation is semantic when you can make all the distinctions you care about and (this is important) do not have to make distinctions you do not care about. In this case every distinction means something and thus is semantic. 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" /> Given the party is described this can render the whole board. Or you can refer to a sequence of moves: <moves party="#myparty" from="22w" to "25b" /> and this can be rendered in any chess move notation. 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> all in the same document. 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.
• marxo 1y ago
  Ah, the corporate enshittification ensues.