12 ms·

Removing XSLT for a more secure browser

• p0w3n3d 11mo ago
  what exactly is the security concern with xslt?
  • JimDabell 11mo ago
    This is answered in the article.
  • TingPing 11mo ago
    It parses untrusted input, the library is basically unmaintained, it’s not often audited but anytime someone looks they find a CVE.
  • jeffbee 11mo ago
    XSLT the idea contains few (but not zero) unavoidable security flaws. libxslt the library is a barely-maintained dumpster fire of bad practices.
    • ryoshu 11mo ago
      They should audit LLMs.
• lenkite 11mo ago
  "Removing established open standards for a more walled garden" -> Fixed
• righthand 11mo ago
  Destroying the open web instead of advocating to fix one of the better underutilized browser technologies for a more Profitable Google. I will not forget the name Mason Freed, destroyer of open collaborative technology.
  • tptacek 11mo ago
    Didn't this effort start with Mozilla and not Google? I think you will in fact forget the name Mason Freed, just like most of us forgot about XSLT.
    • simoncion 11mo ago
      > Didn't this effort start with Mozilla and not Google? Maybe round one of it like ten years ago did? From what I understand, it's a Google employee who opened the "Hey, I want to get rid of this and have no plans to provide a zero-effort-for-users replacement." Github Issue a few months back.
      • JimDabell 11mo ago
        > 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. — https://news.ycombinator.com/item?id=44953349 https://news.ycombinator.com/item?id=44953349
        • simoncion 11mo ago
          I don't see any evidence of that claim from the materials I have available to me. [0] is the Github Issue I mentioned. [1] is the WHATNOT meeting notes linked to from that GH Issue... though I have no idea who smaug is. [0] <https://github.com/whatwg/html/issues/11523 https://github.com/whatwg/html/issues/11523> [1] <https://github.com/whatwg/html/issues/11146#issuecomment-2759059949 https://github.com/whatwg/html/issues/11146#issuecomment-275...>
          • JimDabell 11mo ago
            Smaug is the Mozilla engineer they were talking about: https://github.com/smaug---- https://github.com/smaug----
            • 11mo ago
• HunOL 11mo ago
  So XPath locators won't be available in Playwright and Selenium in Chrome? This could be huge for QA and RPA.
  • rhdunn 11mo ago
    They are still keeping the XPath APIs so XPath locators will still work.
• tclancy 11mo ago
  I know it makes me an old and I am biased because one of the systems in my career I am most proud of I designed around XSLT transformations, but this is some real bullshit and a clear case why a private company should not be the de facto arbiter of web standards. Have a legacy system that depends on XSLT in the browser? Sucks to be you, one of our PMs decided the cost-benefit just wasn't there so we scrapped it. Take comfort in the fact our team's velocity bumped up for a few weeks. And yes I am sour about the fact as an American I have to hope the EU does something about this because I know full-well it's not happening here in The Land of the Free.
• socalgal2 11mo ago
  Good, XSLT was crap. I wrote an RSS feed XSLT template. Worst dev experience ever. No one is/was using XSLT. Removing unused code is a win for browsers. Every anti bloat HNer should be cheering
  • gdwatson 11mo ago
    The first few times you use it, XSLT is insane. But once something clicks, you figure out the kinds of things it’s good for. I am not really a functional programming guy. But XSLT is a really cool application of functional programming for data munging, and I wouldn’t have believed it if I hadn’t used it enough for it to click.
    • exasperaited 11mo ago
      Right. I didn't use it much on the client side so I am not feeling this particular loss so keenly. But server side, many years ago I built an entire CMS with pretty arbitrary markup regions that a designer could declare (divs/TDs/spans with custom attributes basically) in XSLT (Sablotron!) with the Perl binding and a customised build of HTML Tidy, wrapped up in an Apache RewriteRule. So designers could do their thing with dreamweaver or golive, pretty arbitrarily mark up an area that they wanted to be customisable, and my CMS would show edit markers in those locations that popped up a database-backed textarea in a popup. What started off really simple ended up using Sablotron's URL schemes to allow a main HTML file to be a master template for sub-page templates, merge in some dynamic functionality etc. And the thing would either work or it wouldn't (if the HTML couldn't be tidied, which was easy enough to catch). The Perl around the outside changed very rarely; the XSLT stylesheet was fast and evolved quite a lot.
    • garethrowlands 11mo ago
      XSLT's matching rules allow a 'push' style of transform that's really neat. But you can actually do that with any programming language such as Javascript.
  • johannes1234321 11mo ago
    > Every anti bloat HNer should be cheering Actually a transformation system can reduce bloat, as people don't have to write their own crappy JavaScript versions of it. Being XML the syntax is a bit convoluted, but behind that is a good functional (in sense of functional programming language, not functioning) system which can be used for templating etc. The XML made it a bit hard to get started and anti-XML-spirit reduced motivation to get into it, but once you know it, it beats most bloaty JavaScript stuff in that realm by a lot.
• jerf 11mo ago
  This has been chewed on ad nauseum on HN already, to the point I won't even try to make a list of the articles but just link a search result: https://hn.algolia.com/?dateRange=pastYear&page=0&prefix=false&query=XSLT&sort=byPopularity&type=story https://hn.algolia.com/?dateRange=pastYear&page=0&prefix=fal...
  • lolive 11mo ago
    KPIs of the hottest languages on the web show that XSLT has become hotter that Java and C++ in the last days. XML is back, dudes!
  • metadat 11mo ago
    Best thread IMHO, lots of thoughtful root-level comments: "Remove mentions of XSLT from the html spec" https://news.ycombinator.com/item?id=44952185 https://news.ycombinator.com/item?id=44952185
• QuadrupleA 11mo ago
  TIL: Chrome supports XSLT. Good riddance I guess - it and most of the tech from the "XML era" was needlessly overcomplicated.
  • exasperaited 11mo ago
    XSLT is really powerful and it is declarative, like CSS, but can both push and pull. It's a loss, if you ask me, to remove it from client-side, but it's one I worked through years ago. It's still really useful on the server side for document transformation.
    • QuadrupleA 11mo ago
      Imagine a WASM XSLT interpreter wouldn't be to hard to compile?
      • afandian 11mo ago
        TFA mentions polyfills and libraries.
  • afandian 11mo ago
    Perhaps, but isn't the contemporary tech stack orders of magnitude more complicated? Doesn't feel like a strong motivating argument.
  • cxr 11mo ago
    Your response is like seeing the cops going to the wrong house to kick in your neighbors door, breaking their ornaments in their entry way, and then saying to yourself, "Good. I hate yellow, and would never have any of that tacky shit in my house." As your first sentence of your comment indicates, the fact that it's supported and there for people to use doesn't (and hasn't) result in you being forced to use it in your projects.
    • QuadrupleA 11mo ago
      Yes but software, and especially browser, complexity has balooned enormously over the years. And while XSLT probably plays a tiny part in that, it's likely embedded in every Electron app that could do in 1MB what it takes 500 MB to do, makes it incrementally harder to build and maintain a competing browser, etc., etc. It's not zero cost. I do tend to support backwards compatibility over constant updates and breakage, and needless hoops to jump through as e.g. Apple often puts its developers through. But having grown up and worked in the overexuberant XML-for-everything, semantic-web 1000-page specification, OOP AbstractFactoryTemplateManagerFactory era, I'm glad to put some of that behind us. If that makes me some kind of gestappo, so be it.
• jtvjan 11mo ago
  That's upsetting. Being able to do templating without using JavaScript was a really cool party trick. I've used it in an unfinished website where all data was stored in a single XML file and all markup was stored in a single XSLT file. A CGI one-liner then made path info available to XSLT, and routing (multiple pages) was achieved by doing string tests inside of the XSLT template.
• sangeeth96 11mo ago
  To those who saw a chrome.com link and got triggered: > The Firefox[^0] and WebKit[^1] projects have also indicated plans to remove XSLT from their browser engines. [^0]: https://github.com/mozilla/standards-positions/issues/1287#issuecomment-3227145793 https://github.com/mozilla/standards-positions/issues/1287#i... [^1]: https://github.com/whatwg/html/issues/11523#issuecomment-3149280766 https://github.com/whatwg/html/issues/11523#issuecomment-314...
  • righthand 11mo ago
    In my opinion this is not “we agree lets remove it”. This is “we agree to explore the idea”. Google and Freed using this as a go ahead because the Mozilla guy pasted a pollyfill. However it is very clearly NOT an endorsement to remove it, even though bad actors are stating so. > Our position is that it would be good for the long-term health of the web platform and good for user security to remove XSLT, and we support Chromium's effort to find out if it would be web compatible to remove support1. If it turns out that it's not possible to remove support, then we think browsers should make an effort to improve the fundamental security properties of XSLT even at the cost of performance. Freed et al also explicitly chose to ignore user feedback for their own decision and not even try to improve XSLT security issues at the cost of performance.
    • TingPing 11mo ago
      Last I heard for WebKit removing it was the only outcome they saw.
      • righthand 11mo ago
        Yeah all these billion dollar corporations that can’t be bothered see it as the only path forward not because of technological or practical issues, but because none of them can be asked to give a shit and plan it into their budgets. They’re MBAs who only know how to destroy and consolidate as trained.
        • TingPing 11mo ago
• ForHackernews 11mo ago
  Pour one out for @vgr-land https://news.ycombinator.com/item?id=45006098 https://news.ycombinator.com/item?id=45006098
• sherinjosephroy 11mo ago
  Nice find — interesting to see browsers moving to drop XSLT support. I used XSLT once for a tiny site and it felt like magic—templating without JavaScript was freeing. But maybe it’s just niche now, and browser vendors see more cost than payoff. Curious: have any of you used XSLT in production lately?
  • rhdunn 11mo ago
    Yes. It's used heavily in the publishing and standards industries that store the documents in JATS and other XML-based formats. Because browsers only support XSLT 1.0 the transform to HTML is typically done server side to take advantage of XSLT 2.0 and 3.0 features. It's also used by the US government: 1. https://www.govinfo.gov/bulkdata/BILLS https://www.govinfo.gov/bulkdata/BILLS 2. https://www.govinfo.gov/bulkdata/FR/resources https://www.govinfo.gov/bulkdata/FR/resources
  • Devasta 11mo ago
    I lead a team that manage trade settlements for hedge funds; data is exported from our systems as XML and then transformed via XSLT into whatever format the prime brokers require. All the transformed are maintained by non-developers, business analysts mainly. Because the language is so simple we don't need to give them much training, just get IntelliJ installed on their machine, show them a few samples and let them work away. We couldn't have managed with anything else.
• creatonez 11mo ago
  XSLT is complete and utter garbage. Good riddance.
• MarsIronPI 11mo ago
  To anyone who says to use JS instead of XSLT: I block JS because it is also used for ads, tracking and bloat in general. I don't block XSLT because I haven't come across malicious use of XSLT before (though to be fair, I haven't come across much use of XSLT at all). I think being able to do client-side templating without JS is an important feature and I hope that since browser vendors are removing XSLT they will add some kind of client-side templating to replace it.
  • Aurornis 11mo ago
    > I block JS The percentage of visitors who block JS is extremely small. Many of those visits are actually bots and scrapers that don’t interpret JS. Of the real users who block JS, most of them will enable JS for any website they actually want to visit if it’s necessary. What I’m trying to say is that making any product decision for the extremely small (but vocal) minority of users who block JS is not a good product choice. I’m sorry it doesn’t work for your use case, but having the entire browser ecosystem cater to JS-blocking legitimate users wouldn’t make any sense.
    • davisr 11mo ago
      I block JS, too. And so does about 1-2% of all Web users. JavaScript should NOT be REQUIRED to view a website. It makes web browsing more insecure and less private, makes page load times slower, and wastes energy.
      • dpark 11mo ago
        > And so does about 1-2% of all Web users. To put that in context, about 6 percent of US homes have no internet access at all. The “I turn off JS” crowd is at least 3x smaller than the crowd with no access at all. The JS ship sailed years ago. You can turn it off but a bunch of things simply will not work and no amount of insisting that it would not be required will change that.
        • kstrauser 11mo ago
• rf15 11mo ago
  As someone who built an XSLT renderer and remembers having an awful time with the spec: good riddance. Data and its visualisation should be strictly separate, and not require an additional engine in your environment of choice.
• afandian 11mo ago
  Previous discussion https://news.ycombinator.com/item?id=44952185 https://news.ycombinator.com/item?id=44952185
• fithisux 11mo ago
  Removing JavaScript for a more secure browser.
• phendrenad2 11mo ago
  Unquestionably the right move. From the various posts on HN about this, it's clear that (A) not many people use it (B) it increases security vulnerability surface area (C) the few people who do claim to use have nothing to back up the claim The major downside to removing this seems to be that a lot of people LIKE it. But eh, you're welcome to fork Chromium or Firefox.
  • lunar_mycroft 11mo ago
    Chrome and other browsers could virtually completely mitigate the security issues by shipping the polyfil they're suggesting all sites depending on XSLT deploy in the browser. By doing so, their XSLT implementation would become no less secure than their javascript implementation (and fat chance they'll remove that). The fact that they've rejected doing so is a pretty clear indication that security is just an excuse, IMO.
    • chrismorgan 11mo ago
      I wish more people would see this. They know exactly how to sandbox it, they’re telling you how to, they’re even providing and recommending a browser extension to securely restore the functionality they’re removing! The security argument can be valid motivation for doing something, but is utterly illegitimate as a reason for removing. They want to remove it because they abandoned it many years ago, and it’s a maintenance burden. Not a security burden, they’ve shown exactly how to fix that as part of preparing to remove it!
      • lunar_mycroft 11mo ago
        And it's a very small maintenance burden at that. Shipping the polyfil would technically still be a dependency, but about as decoupled a dependency as you can get. It's only interaction with the rest of the code would be through public APIs that browsers have to keep stable anyway.
    • thro1 11mo ago
      by definition XSLT is more secure than JavaScript.
• larusso 11mo ago
  Makes me kind of sad. I started my carrier back in days when XHTML and co were lauded as the next thing. I worked with SOAP and WDSLs. I loved that one can express nearly everything in XML. And namespaces… Then came json and apart from being easier to read for humans I wondered why we switch from this one great exchange format to this half baked one. But maybe I’m just nostalgic. But every time I deal with json parsers for type serialization and the question how to express HashMaps and sets, how to provide type information etc etc I think back to XML and the way that everything was available on board. Looked ugly as hell though :)
  • kome 11mo ago
    json is sort of a gresham's law "bad money drives out the good" but for tech: lazy and forgiving technologies drive out the better but stricter ones. bad technology seems to make life easier at the beginning, but that's why we now have sloppy websites that are an unorganized mess of different libraries, several MB in size without reason, and an absolute usability and accessibility nightmare. xhtml and xml were better, also the idea separating syntax from presentation, but they were too intelligent for our own good.
    • mpyne 11mo ago
      > lazy and forgiving technologies drive out the better but stricter ones. JSON is not "lazy and forgiving" (seriously, go try adding a comment to it). It was just laser-focused on what the actual problem was that needed to be solved by many devs in day-to-day practice. Meanwhile XML wanted to be an entire ecosystem, its own XML Cinematic Universe, where you had to adopt it all to really use it. It's not surprising to me that JSON won out, but it's not because it's worse, it's actually much better than XML for the job it ended up being used for (a generic format to transfer state between running programs supporting common data structures with no extraneous add-ons or requirements). XML is better for a few other things, but those things are far less commonly needed.
      • larusso 11mo ago
        Don’t know if I would describe it as much better. I see it similar to the whole SQL -> NOSQL -> let’s add all the feature and end up with SQL. JSON undergo a similar story with the difference that we didn’t go back to XML. What I mean is to simplify and then realize what was actually missing. But I agree for the smaller services and state transfer especially in web XML was just too damn big and verbose. But conceptually it was great.
• gdulli 11mo ago
  I don't use XSLT and don't object to this, but seeing "security" cited made me realize how reflexively distrustful I've become of them using that justification for a given decision. Is this one actually about security? Who knows!
  • Devasta 11mo ago
    Its "Security" when they want to do a thing, its "WebCompat" when they don't.
  • JimDabell 11mo ago
    > Finding and exploiting 20-year-old bugs in web browsers > Although XSLT in web browsers has been a known attack surface for some time, there are still plenty of bugs to be found in it, when viewing it through the lens of modern vulnerability discovery techniques. In this presentation, we will talk about how we found multiple vulnerabilities in XSLT implementations across all major web browsers. We will showcase vulnerabilities that remained undiscovered for 20+ years, difficult to fix bug classes with many variants as well as instances of less well-known bug classes that break memory safety in unexpected ways. We will show a working exploit against at least one web browser using these bugs. — https://www.offensivecon.org/speakers/2025/ivan-fratric.html https://www.offensivecon.org/speakers/2025/ivan-fratric.html — https://www.youtube.com/watch?v=U1kc7fcF5Ao https://www.youtube.com/watch?v=U1kc7fcF5Ao > libxslt -- unmaintained, with multiple unfixed vulnerabilities — https://vuxml.freebsd.org/freebsd/b0a3466f-5efc-11f0-ae84-99047d0a6bcc.html https://vuxml.freebsd.org/freebsd/b0a3466f-5efc-11f0-ae84-99...
  • bawolff 11mo ago
    Didn't this come pretty directly after someone found some security vulns? I think the logic was, this is a huge chunk of code that is really complex which almost nobody uses outside of toy examples (and rss feeds). Sure, we fixed the issue just reported, but who knows what else is lurking here, it doesn't seem worth it. As a general rule, simplifying and removing code is one of the best things you can do for security. Sure you have to balance that with doing useful things. The most secure computer is an unplugged computer but it wouldn't be a very useful one; security is about tradeoffs. There is a reason though that security is almost always cited - to some degree or another, deleting code is always good for security.
• TazeTSchnitzel 11mo ago
  It wasn't clear to me from reading this whether <?xml-stylesheet with CSS will also stop being supported. There's no need to deprecate that, surely?
• delf 11mo ago
  [dead]
• aorth 11mo ago
  Ah, so this is removing libxslt. For a minute I thought XSLT processing was provided by libxml2, and I remembered seeing that the Ladybird browser project just added a dependency on libxml2 in their latest progress update https://ladybird.org/newsletter/2025-10-31/ https://ladybird.org/newsletter/2025-10-31/. I'm curious to see what happens going forward with these aging and under-resourced—yet critical—libraries.
• Devasta 11mo ago
  "The reality is that for all of the work that we've put into HTML, and CSS, and the DOM, it has fundamentally utterly failed to deliver on its promise. It's even worse than that, actually, because all of the things we've built aren't just not doing what we want, they're holding developers back. People build their applications on frameworks that _abstract out_ all the APIs we build for browsers, and _even with those frameworks_ developers are hamstrung by weird limitations of the web." - https://news.ycombinator.com/item?id=34612696#34622514 https://news.ycombinator.com/item?id=34612696#34622514 I find it so weird that browser devs can point to the existence of stuff like React and not feel embarrassed.
  • shadowgovt 11mo ago
    > I find it so weird that browser devs can point to the existence of stuff like React and not feel embarrassed. Sorry, I don't follow. What's embarrassing about React?
    • JimDabell 11mo ago
      I think in the context of that link, they see React as a failing of the web. If the W3C/WHATWG/browser vendors had done a reasonable job of moving web technology forward, things like React would be far less necessary. But they spent all their time and energy working on things like <aside> and web components instead of listening to web developers and building things that are actually useful in a web developer’s day-to-day life. Front-end frameworks like React, on the other hand, did a far better job of listening to developers and building what they needed.
      • imtringued 11mo ago
        One of the biggest flaws of the current web technology stack is the unholy mix of concerns with respect to layout. Layout is handled by CSS and HTML in a way that drives people crazy. I recently wanted to have a scroll bar for super long text inside a table cell. Easy, right? Turns out you need to change the HTML to include a <div> inside the table cell, since there is no way to style the table cell itself and have it do what you expect it to do. XLST doesn't solve this at all, since you're just generating more of the problem, i.e. more HTML and CSS. It feels like there should have been some sort of language exclusively for layout definition that doesn't necessarily know about the existence of HTML and CSS beyond selector syntax.
• simonw 11mo ago
  If you are using XSLT to make your RSS or atom feeds readable in a browser should somebody click the link you may find this post by Jake Archibald useful: https://jakearchibald.com/2025/making-xml-human-readable-without-xslt/ https://jakearchibald.com/2025/making-xml-human-readable-wit... - it provides a JavaScript-based alternative that I believe should work even after Chrome remove this feature.
• nwellnhof 11mo ago
  The "severe security issue" in libxml2 they mention is actually a non-issue and the code in question isn't even used by Chrome. I'm all for switching to memory-safe languages but badmouthing OSS projects is poor style.
  • cxr 11mo ago
    Where's the best collection or entry point to what you've written about Chrome's use of Gnome's XML libraries, the maintenance burden, and the dearth of offers by browser makers foot the bill?
  • chuckadams 11mo ago
    The issue in question is just one of the several long-unfixed vulnerabilities we know about, from a library that doesn't have that many hands or eyes on it to begin with.
    • sroussey 11mo ago
      And why doesn’t Google contribute to fixing and maintaining code they use?
      • deleted 11mo ago
        [deleted]
      • SoftTalker 11mo ago
        Because in this case it doesn't contribute to their ability to deliver ads.
      • kccqzy 11mo ago
        Because they don't want to use the code. They begrudgingly use it to support XSLT and now they don't use it.
        • lunar_mycroft 11mo ago
          Maintaining web standards without breaking backwards compatibility is literally what they signed up for when they decided to make a browser. If they didn't want to do that job, they shouldn't have made one.
• immibis 11mo ago
  Although it's sad to see an interesting feature go, they're not wrong about security. It's more important to have a small attack surface if this was maintained by one guy in Nebraska and he doesn't maintain it any more. No, XSLT isn't required for the open web. Everything you can do with XSLT, you can also do without XSLT. It's interesting technology, but not essential. Yes, this breaks compatibility with all the 5 websites that use it.
• arandr0x 11mo ago
  It's encouraging to see browsers actually deprecate APIs, when I think a lot of problems with the Web and Web security in particular is people start using new technologies too fast but don't stop using old ones fast enough. That said, it's also pretty sad. I remember back in the 2000s writing purely XML websites with stylesheets for display, and XML+XSLT is more powerful, more rigorous, and arguably more performant now in the average case than JSON + React + vast amounts of random collated libraries which has become the Web "standard". But I guess LLMs aren't great at generating XSLT, so it's unlikely to gain back that market in the near future. It was a good standard (though not without flaws), I hope the people who designed it are still proud of the influence it did have.
  • danielvaughn 11mo ago
    Agreed on API deprecation, the surface is so broad at this point that it's nearly impossible to build a browser from scratch. I've been doing webdev since 2009 and I'm still finding new APIs that I've never heard of before.
  • update 11mo ago
    > I remember back in the 2000s writing purely XML websites with stylesheets for display Awesome! I made a blog using XML+XSLT, back in high school. It was worth it just to see the flabbergasted look on my friends faces when I told them to view the source code of the page, and it was just XML with no visible HTML or CSS[0]. [0] https://www.w3schools.com/xml/simplexsl.xml https://www.w3schools.com/xml/simplexsl.xml - example XML+XSLT page from w3schools
  • logifail 11mo ago
    > I remember back in the 2000s writing purely XML websites with stylesheets for display Yup, "been there, done that" - at the time I think we were creating reports in SQL Server 2000, hooked up behind IIS. It feels this is being deprecated and removed because it's gone out of fashion, rather than because it's actually measurably worse than whatever's-in-fashion-today... (eg React/Node/<whatever>)
    • SoftTalker 11mo ago
• Fileformat 11mo ago
  One extremely important XSLT use-case is for RSS/Atom feeds. Right now, clicking on a link to feed brings up a wall of XML (or worse, a download link). If the feed has an XSLT stylesheet, it can be presented in a way that a newcomer can understand and use. I realize that not that many feeds are actually doing this, but that's because feed authors are tech-savvy and know what to do with an RSS/Atom link. But someone who hasn't seen/used an RSS reader will see a wall of plain-text gibberish (or a prompt to download the wall of gibberish). XSLT is currently the only way to make feeds into something that can still be viewed. I think RSS/Atom are key technologies for the open web, and discovery is extremely important. Cancelling XSLT is going in the wrong direction (IMHO). I've done a bunch of things to try to get people to use XSLT in their feeds: https://www.rss.style/ https://www.rss.style/ You can see it in action on an RSS feed here (served as real XML, not HTML: do view/source): https://www.fileformat.info/news/rss.xml https://www.fileformat.info/news/rss.xml
  • yegle 11mo ago
    FWIW the original post explicitly mentioned this use case and offered two ways to workaround.
    • Fileformat 11mo ago
      Gotta love the reference to the <link> header element. There used to be an icon in the browser URL bar when a site had a feed, but they nuked that too.
      • jeffbee 11mo ago
        Man, reaching way back in history here, but this reminds me of why I stopped contributing to Mozilla decades ago. My contribution was the link toolbar, that was supposed to give a UI representation of the canonical link elements like next and prev and whatnot. At the last minute before a major release some jerkhole of a product manager at AOL cut my feature from the release. It's incredible the way such pretty bureaucrats have shaped web browsers over the years.
• cxr 11mo ago
  > When that solution isn't wanted, the polyfill offers another path. A solution is only a solution if it solves the problem. This sort of thing, basically a "reverse X/Y problem", is an intellectually dishonest maneuver, where a thing is dubbed a "solution" after just, like, redefining the problem to not include the parts that make it a problem. The problem is that there is content that works today that will break after the Chrome team follows through on their announced plans of shirking on their responsibility to not break the Web. That's what the problem is. Any "solution" that involves people having to go around un-breaking things that the web browser broke is not a solution to the problem that the Chrome team's actions call for people to go around un-breaking things that the web browser broke. > As mentioned previously, the RSS/Atom XML feed can be augmented with one line, <script src="xslt-polyfill.min.js" xmlns="http://www.w3.org/1999/xhtml"></script>, which will maintain the existing behavior of XSLT-based transformation to HTML. Oh, yeah? It's that easy? So the Chrome team is going to ship a solution where when it encounters un-un-fucked content that depends on XSLT, Chrome will transparently fix it up as if someone had injected this polyfill import into the page, right? Or is this another instance where well-paid engineers on the Chrome team who elected to accept the responsibility of maintaining the stability of the Web have decided that they like the getting-paid part but don't like the maintaining-the-stability-of-the-Web part and are talking out of both sides of their mouths?
  • shadowgovt 11mo ago
    > So the Chrome team is going to ship a solution where when it encounters un-un-fucked content that depends on XSLT, Chrome will transparently fix it up as if someone had injected this polyfill import into the page, right? As with most things on the web, the answer is "They will if it breaks a website that a critical mass of users care about." And that's the issue with XSLT: it won't.
    • cxr 11mo ago
      > As with most things on the web, the answer is "They will if it breaks a website that a critical mass of users care about." This is a (poor) attempt at gaslighting/retconning. The phrase "Don't break the Web" is not original to this thread. (I can't say I look forward to your follow-up reply employing sleights of hand like claims about how stuff like Flash that was never standardized, or the withdrawal of experimental APIs that weren't both stable/finalized and implemented by all the major browsers, or the long tail of stuff on developer.mozilla.org that is marked "deprecated" (but nonetheless still manages to work) are evidence of your claim and that browser makers really do have a history of doing this sort of thing. This is in fact the first time something like this has actually happened—all because there are engineers working on browsers at Google (and Mozilla and Apple) that are either confused about how the Web differs from, say, Android and iOS, or resentful of their colleagues who get to work on vendor SDKs where the API surface area is routinely rev'd to remove whatever they've decided no longer aligns with their vision for their platform. That's not what the Web is, and those engineers can and should go work on Android and iOS instead of sabotaging the far more important project of attending to the only successful attempt at a vendor-neutral, ubiquitous, highly accessible, substrate for information access that no one owns and that doesn't fuck over the people who rely on it being stable.)
• slightwinder 11mo ago
  Would it be possible to move it to an add-on for those who still want it? Are WebExtensions supporting third-party-libs?
• RogBogTog 11mo ago
  I think that's sad. XSLT is in my point a view a very misunderstood technology. It gets hated on a lot. I wonder if this hate is by people who actually used and understood it, though. In any case, more often than not this is by people who in the same sentence endorse JavaScript (which, by any objective way of measuring is just a language far more poorly designed).
  • lolive 11mo ago
    Iterating upon a JSON in raw JS is much sexier than learning XSLT. (at least, JS allows breakpoints in the Chrome debugger)
  • eddd-ddde 11mo ago
    What does XSLT provide that you cannot achieve with plain JS?
    • basscomm 11mo ago
      I'm not much of a programmer, but XSLT being declarative means that I can knock out a decent-looking template without having to do a whole lot of programming work.
    • bmacho 11mo ago
      It can style RSS without enabling javascript and all that spy and malware.
  • DonHopkins 11mo ago
    Au contraire: the more you understand and use XSLT, the more you hate it. People who don't understand it and haven't used it don't have enough information and perspective to truly hate it properly. I and many other people don't hate XSLT out of misunderstanding at all: just the opposite. XSLT is like programming with both hands tied behind your back, or pedaling a bicycle with only one leg. For any non-trivial task, you quickly hit a wall of complexity or impossibility, then the only way XSLT is useful is if you use Microsoft's non-standard XSLT extensions that let you call out to JavaScript, then you realize it's so easy and more powerful to simply do what you want directly in JavaScript there's absolutely no need for XSLT. I understand XSLT just fine, but it is not the only templating language I understand, so I have something to compare it with. I hate XSLT and vastly prefer JavaScript because I've known and used both of them and other worse and better alternatives (like Zope Page Templates / TAL / METAL / TALES, TurboGears Kid and Genshi, OpenLaszlo, etc). https://news.ycombinator.com/item?id=44396067 https://news.ycombinator.com/item?id=44396067 https://news.ycombinator.com/item?id=22264623 https://news.ycombinator.com/item?id=22264623 https://news.ycombinator.com/item?id=28878913 https://news.ycombinator.com/item?id=28878913 https://news.ycombinator.com/item?id=16227249 https://news.ycombinator.com/item?id=16227249 >My (completely imaginary) impression of the XSLT committee is that there must have been representatives of several different programming languages (Lisp, Prolog, C++, RPG, Brainfuck, etc) sitting around the conference table facing off with each other, and each managed to get a caricature of their language's cliche cool programming technique hammered into XSLT, but without the other context and support it needed to actually be useful. So nobody was happy! >Then Microsoft came out with MSXML, with an XSL processor that let you include <script> tags in your XSLT documents to do all kinds of magic stuff by dynamically accessing the DOM and performing arbitrary computation (in VBScript, JavaScript, C#, or any IScriptingEngine compatible language). Once you hit a wall with XSLT you could drop down to JavaScript and actually get some work done. But after you got used to manipulating the DOM in JavaScript with XPath, you being to wonder what you ever needed XSLT for in the first place, and why you don't just write a nice flexible XML transformation library in JavaScript, and forget about XSLT.
• froh 11mo ago
  I to this day think the move from dsssl to xslt was the biggest mistake in the SGML to XML evolution. they went from a clean scheme based standard to a human-unreadable "use a GUI tool" syntax. st text serna was a wysiwyg XML FO rendering editor: throw in call stylesheets and some input XML, wysiwyg edit away but xslt didn't take off nor did derived products.
• DonHopkins 11mo ago
  I recently had an interesting chat with Liam Quin (who was on W3C's XML team) about XML and CDATA on Facebook, where he revealed some surprising history! Liam Quinn in his award winning weirdest hat, also Microsoft's Matthew Fuchs' talk on achieving extensibility and reuse for XSLT 2.0 stylesheets, and Stephan Kesper̀̀'s simple proof that XSLT and XQuery are Turing complete using μ-recursive functions, and presentations about other cool stuff like Relax/NG: https://www.cafeconleche.org/oldnews/news2004August5.html https://www.cafeconleche.org/oldnews/news2004August5.html Liam Quin's post: https://www.facebook.com/liam.quin/posts/pfbid0X6jE58zjcEK5U2o5rqjPP44yCRRQUwa6QKYc2y6b5aPxcQ3VYkzuj38fchquB7rSl?comment_id=1160195002137761 https://www.facebook.com/liam.quin/posts/pfbid0X6jE58zjcEK5U... #XML people! How do we communicate the idea that declarative markup is a good idea? Declarative markup is where you identify what is there, not what it does. This is a title, not, make this big and bold. This is a a part number, not, make this blink when you click it - sure, you can do that to part numbers, but don't encode your aircraft manual that way. But this idea is hard to grasp, for the same reason that WYSIAYG word processors (the A stands for All, What you see is all you get) took over from descriptive formatting in a lot of cases. For an internal memo, for an insurance letter to a client, how much matters? Well, the insurance company has to be able to search the letters for specific information for 10, 20, 40, 100 years. What word processor did you use 40 years ago? Wordstar? Magic Wand? Ventura? #markupMonday #declarativeMarkup Don Hopkins: I Wanna Be <![CDATA[ https://donhopkins.medium.com/i-wanna-be-cdata-3406e14d4f21 https://donhopkins.medium.com/i-wanna-be-cdata-3406e14d4f21 Liam Quin: hahaha i actually opposed the inclusion of CDATA sections when we were designing XML (by taking bits we wanted from SGML), but they were already in use by the people writing the XML spec! But now you’ve given me a reason to want to keep them. The weird syntax is because SGML supported more keywords, not only CDATA, but they were a security fail. Don Hopkins: There was a REASON for the <![SYNTAX[ ]]> ?!?!? I though it was just some kind of tribal artistic expressionism, like lexical performance art! At TomTom we were using xulrunner for the cross platform content management tool TomTom Home, and XUL abused external entities for internationalizing user interface text. That was icky! For all those years programming OpenLaszlo in XML with <![CDATA[ JavaScript code sections ]>, my fingers learned how to type that really fast, yet I never once wondered what the fuck ADATA or BDATA might be, and why not even DDATA or ZDATA? What other kinds of data are there anyway? It sounds kind of like quantum mechanics, where you just have to shrug and not question what the words mean, because it's just all arbitrarily weird. Liam Quin: haha it’s been 30 years, but, there’s CDATA (character data), replaceable character data (RCDATA) in which `&eacute;` entity definitions are recognised but not `<`, IGNORE and INCLUDE, and the bizarre TEMP which wraps part of a document that might need to be removed later. After `<!` you could also have comments, <!-- .... --> for example (all the delimiters in SGML could be changed). Don Hopkins: What is James Clark up to these days? I loved his work on Relax/NG, and that Dr. Dobb's interview "The Triumph of Simplicity". https://web.archive.org/web/20020224025029/http://www.ddj.com/documents/s=862/ddj0107e/ https://web.archive.org/web/20020224025029/http://www.ddj.co... Note: James Clark is arguably the single most important engineer in XML history: - Lead developer of SGMLtools, expat, and Jade/DSSSL - Co-editor of the XML 1.0 specification - Designer of XSLT 1.0 and XPath 1.0 - Creator of Relax NG, one of the most elegant schema languages ever devised He also wrote the reference XSLT implementation XT, used in early browsers and toolchains before libxslt dominated. James Clark’s epic 2001 Doctor Dobb's Journal "A Triumph of Simplicity: James Clark on Markup Languages and XML" interview captures his minimalist design philosophy and his critique of standards and committee-driven complexity (which later infected XSLT 2.0). It touches on separation of concerns, simplicity as survival, a standard isn't one implementation, balance of pragmatism and purity, human-scale simplicity, uniform data modeling, pluralism over universality, type systems and safety, committe pathology, and W3C -vs- ISO culture. He explains why XML is designed the way it is, and reframes the XSLT argument: his own philosophy shows that when a transformation language stops being simple, it loses the very quality that made XML succeed.
• symbogra 11mo ago
  I wrote a bunch of stuff with XSLT back in the day that I thought was pretty cool but I can't for the life of me remember what it was...
• zzo38computer 11mo ago
  XSLT seem like it could be something implemented with WebAssembly (and/or JavaScript), in an extension (if the extension mechanism is made suitable; I think some changes might be helpful to support this and other things), possibly one that is included by default (and can be overridden by the user, like any other extension should be); if it is implemented in that way then it might avoid some of the security issues. (PDF could also be implemented in a similar way.) (There are also reasons why it might be useful to allow the user to manually install native code extensions, but native code seems to be not helpful for this use, so to improve security it should not be used for this and most other extensions.)
  • willseth 11mo ago
    The lead dev driving the Chrome deprecation built a wasm polyfill https://github.com/mfreed7/xslt_polyfill https://github.com/mfreed7/xslt_polyfill. Multiple people proposed in the Github discussions leading up to this that Google simply make the polyfill ship with Chrome as an on-by-default extension that could be disabled in settings, but he wouldn't consider it.
• qwertox 11mo ago
  - Chrome 155 (Nov 17, 2026): XSLT stops functioning on Stable releases, for all users other than Origin Trial and Enterprise Policy participants.** - Chrome 164 (Aug 17, 2027): Origin Trial and Enterprise Policy stop functioning. XSLT is disabled for all users.** Not the first time I've seen on Google's pages that the use of asterisks then lacks the corresponding footnotes.
• sedatk 11mo ago
  I like XSLT, and I’ve been using the browser-based APIs in my projects, but I must say that XSLT ecosystem has been in a sad state: - Browsers have only supported XSLT 1.0, for decades, which is the stone age of templating. XSLT 3.0 is much nicer, but there’s no browser support for it. - There are only two cross-platform libraries built for it: libxslt and Saxon. Saxon seriously lacks ergonomics to say the least. One option for Google as a trillion dollar company would be to drive an initiative for “better XSLT” and write a Rust-based replacement for libxslt with maybe XSLT 3.0 support, but killing it is more on-brand I guess. I also dislike the message “just use this [huge framework everyone uses]”. Browser-based template rendering without loading a framework into the page has been an invaluable boon. It will be missed.
• dana321 11mo ago
  This is the problem with any C/C++ codebase, using rust instead would have been a better solution than just removing web standards from what is supposed to be a web browser.
• bigbuppo 11mo ago
  It's a shame the browser developers are making an open, interoperable, semantic web more difficult. It's not surprising, though. Browsers started going downhill after they removed the status bar and the throbber and made scrollbars useless.
• userbinator 11mo ago
  If they really cared about "security" they would remove JS or try to encourage minimising its use. That is a huge attack surface in comparison, but they obviously want to keep it so they can shove in more invasive and hostile user-tracking and controlling functionality.
  • metadope 11mo ago
    I do all of my browsing with Javascript disabled. I've done this for decades now, as a security precaution mainly, but I've also enjoyed some welcome side-effects where paywalls disappeared and ads became static and unobtrusive. I wasn't looking for those benefits but I'll take 'em. In stride. I've also witnessed a welcome (but slow) change in site implementations over the years: there are few sites completely broken by the absence of JS. Still some give blank screens and even braindead :hidden attributes thrown into the <noscript> main page to needlessly forbid access... but not as many as back in the day when JS first became the rage. I don't know much about XSLT other than the fact that my Hiawatha web server uses it to make my directory listings prettier, and I don't have to add CSS or JS to get some style. I hate to see a useful standard abandoned by the big boys, but what can I do about it? I bristle when I encounter pages with a few hundred words of content surrounded by literally megabytes of framework and flotsam, but that's the gig, right, wading through the crap to find the ponies.
• NooneAtAll3 11mo ago
  lol, talking about "secure browser" on chrome dot com
• al_be_back 11mo ago
  Removing html and css would also make the browser more secure - but I would argue also very counter productive for users. Most of read-only content and lite editing can be achieved with raw data + xslt. The web has become a sledgehammer for clacking a nut. For example, with xslt you could easily render a read only content without complex and expensive office apps. That is enough for Academia, Gov, and small businesses.
• beej71 11mo ago
  I'd never written any XSL before last week when I got the crazy idea of putting my resume in XML format and using stylesheets to produce both resume and CV forms, redacted and not, with references or not. And when I had it working in HTML, I started on the Typst stylesheet. xsltproc, being so old, basically renders the results instantly. And Typst, being so new, does as well.
• usr1106 11mo ago
  When do we see the headline: Removing Javascript for a more secure browser? So the honest title should have been: Removing XSLT because it cannot serve adds (Yes, the underlying implementation might be insecure. But how secure would Javascript be with the same amount of maintenance in the last 20 years?)
• khana 11mo ago
  [dead]
• oblviousanon 11mo ago
  More like google forgot how to write secure code and wings it, or just doesn't give a fuck.
• rurban 11mo ago
  Good. Finally getting rid of this security and usage nightmare. There's a polyfill and an extensions so even the diehards will be pleased
• thro1 11mo ago
  That's our freedom of not being forced to use JavaScript for everything being taken away !
• deleted 11mo ago
  [deleted]
• deleted 11mo ago
  [deleted]
• thro1 11mo ago
  https://github.com/whatwg/html/issues/11146#issuecomment-2759059949 https://github.com/whatwg/html/issues/11146#issuecomment-275... 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? .. just like that, but: https://github.com/whatwg/html/issues/11582#issuecomment-3215835106 https://github.com/whatwg/html/issues/11582#issuecomment-321... As for the rest of your [working for Google] comment. To put it simply, you come off as someone inexperienced, maybe I'm wrong and you have a big list of features you've successfully removed and public discussions you had in the process, if so, there's probably something to learn from those that's different here.
• thro1 11mo ago
  https://www.igalia.com/chats/xslt-liam https://www.igalia.com/chats/xslt-liam So basically browsers had this [..] the question now is there is no investment in this. None. And there hasn't been for a really long time from the browser's perspectives. XSLT shows up then to be very robust technology that survived the test of time already - if for decades (!) regardless of lack of support, investment, with key browser bugs not fixed by purpose stuck at version 1.0 - it's still being used in that working part - and if used it holds up well and last, in meantime, elsewhere: XPath And XSLT continue to evolve. They've really continued to evolve. And people are currently working on an XSLT-4. or Xee: A Modern XPath and XSLT Engine in Rust 381 points 8 months ago https://news.ycombinator.com/item?id=43502291 https://news.ycombinator.com/item?id=43502291 . And because it's a declarative way of transforming trees and collections of trees. And declarative means you don't say how to do it. You say, 'This is what I want'.. .. it's timeless: _abstracted definition_ to which imperative solutions could be reduced in the best case - with unaware of that authors repetitively trying (and soon having to) to reimplement that "not needed" ( - if abstracted already out ! - ) part ( ex. https://news.ycombinator.com/item?id=45183624 https://news.ycombinator.com/item?id=45183624 ) - in more or less common or compatible ways - so, better keep it - as not everybody can afford expensive solutions and there are nonprofits too that don't depend on % of money wasted repeating same work and like to KISS !
• thro1 11mo ago
  Just.. and for so long: XSLT is WWW standard, JavaScript is not (it's ECMA standard) - and there is no JavaScript specification on W3C pages . ( https://www.w3.org/wiki/JavaScript https://www.w3.org/wiki/JavaScript ) Shall JavaScript to become a web standard first - then to be used to "replace" already standard solution ?
  • deleted 11mo ago
    [deleted]
• idkfasayer 11mo ago
  Question, how hard is it going to be to add XSLT back with WASM? I have built a few stylesheets for clients to view their raw XML in browser. I even add charts for data tables with XSLT.
• thro1 11mo ago
  There is no way to make JavaScript so limited in scope as XSLT is. But what I want only is XSLT on live DOM nodes, when editing. Simple templating good engine, and to stay. Not a fancy stuff (reredoxes adinfinis). That are capabilities that progressing-processing-oriented people will never get even close to that which document(ing)-oriented people (users) transparently had and is about to get lost. The World Wide Web, invented at CERN in 1989 by Tim Berners-Lee, is a system of interlinked hypertext _documents_ - not interlinked programs (opaque and superior to take control over any data).