15 ms·

XSLT RIP

• GaryBluto 11mo ago
  While I agree with the sentiment, I loathe these "retro" websites that don't actually look like how most websites looked back then. It's like how people remember the 80s as neon blue and pink when it was more of a brownish beige.
  • Moosturm 11mo ago
    My old website from the 90s looks disturbingly similar to this one.
  • rusk 11mo ago
    > it was more of a brownish beige. Bleed through from the 70s
  • galkk 11mo ago
    Exactly. If there is no white 1x1 pixel that is stretched in an attempt to make something that resembles actual layout, or multiple weird tables, I always ask: are they even trying. In all seriousness- they got quite a good run with xslt. Time to let it rest.
    • mickeyp 11mo ago
      1x1 pixels for padding and aligning? That came later. Your memory is off. In the 90s, sites did kinda look like that.
      • coldtea 11mo ago
        1x1 pixels for padding and aligning were absolutely a thing in the late 90s (1997+). Don't know what alternative history you have in mind, but it was used at the "table layout" era. What came later was the float layout hell- sorry, "solution".
      • bazoom42 11mo ago
        The 1x1 pixel gif hack arrived shortly after Netscape 1.1 introduced tables. I belive this was before colored text and tiled backgrounds became available. So the hack is definitely part of the “golden age” of web design.
  • dist-epoch 11mo ago
    Maybe not most, but there were plenty of black/blue/dark sites.
  • antonvs 11mo ago
    Could just be the author’s personal style? I once got into a cab in NYC on Halloween and the driver said to me, hey, you really nailed that 80s hairstyle, thinking I had styled it for Halloween. I had to tell him dude, I’m from the 80s.
  • deleted 11mo ago
    [deleted]
  • coldtea 11mo ago
    >While I agree with the sentiment, I loathe these "retro" websites that don't actually look like how most websites looked back then. Countless websites on Geocities and elsewhere looked just like that. MY page looked like that (but more edgy, with rotating neon skull gifs). All those silly GIFs were popular and there were sites you could find and download some for personal use. >It's like how people remember the 80s as neon blue and pink when it was more of a brownish beige. In North Platte or Yorkshire maybe. Otherwise plenty of neon blue and pink in the 80s. Starting from video game covers, arcades, neon being popular with bars and clubs, far more colorful clothing being popular, "Memphis" style graphic design, etc.
    • NoGravitas 11mo ago
      The brown, beige, and dark orange were extremely prevalent in the 80s --- but a lot of that was a result of the fact that most things in your environment are never brand new; the first half of the 80s was mostly built in the second half of the 70s.
  • arcanemachiner 11mo ago
    Now that you mention it, something did seem a little off about the thinking-butt emoji...
  • cpach 11mo ago
    This look with animations and bright text on dark repeated backgrounds was definitely popular for a while in the late 90s. You wouldn’t see it on larger sites like Yahoo or CNN, but it was definitely not unheard of for personal sites. Gray backgrounds where also popular, with bright blue for unvisited links and purple for visited links. IIRC this was inspired by the default colors of Netscape Navigator 2.
    • johannes1234321 11mo ago
      > IIRC this was inspired by the default colors of Netscape Navigator 2. "Inspired" is an interesting word for "didn't set custom values." And I believe Mosaic used the same colors before. I'm not even sure when HTML introduced the corresponding attributes (this was all before CSS ...)
  • jameslk 11mo ago
    You’re right, there isn’t even any marquee or blinking text
    • mrspuratic 11mo ago
      A marquee, animated work-in-progress GIF and a visit counter CGI would have nailed it.
  • themafia 11mo ago
    > don't actually look like how most websites looked back then https://geocities.restorativland.org/Area51/ https://geocities.restorativland.org/Area51/ > was more of a brownish beige. Did you never watch MTV?
  • psychoslave 11mo ago
    Well, the page don't tell anything about it's style, so all these impressions are really what people interpret.
• bravetraveler 11mo ago
  Great neuron exercise seeing Flaming Text again
• koito17 11mo ago
  I was hoping the site itself would be an XML document. Thankfully, it is an XML document. % curl https://xslt.rip/ <?xml version="1.0" encoding="UTF-8"?> <?xml-stylesheet href="/index.xsl" type="text/xsl"?> <html> <head> <title>XSLT.RIP</title> </head> <body> <h1>If you're reading this, XSLT was killed by Google.</h1> <p>Thoughts and prayers.</p> <p>Rest in peace.</p> </body> </html>
  • ktpsns 11mo ago
    This is actually a clever way to distinguish if the browser supports XSLT or not. Actual content is XHTML in https://xslt.rip/index.xsl https://xslt.rip/index.xsl The author is frontend designer and has a nice website, too: https://dbushell.com/ https://dbushell.com/ I like the personal, individual style of both pages.
    • konimex 11mo ago
      > https://dbushell.com https://dbushell.com Heh, I honestly thought the domain name stood for "D-Bus Hell" and not their own name.
      • andrelaszlo 11mo ago
        I guess we've both been traumatized by modern linux distros?
      • leberknecht 11mo ago
        for those wondering: No, its not "d-bus hell" ^^
        • cachius 11mo ago
          It's David Bushell
      • egorfine 11mo ago
        Same here. This is f..n hilarious.
• SvenL 11mo ago
  Boy is this an awesome web page. Suddenly I have the urge to create an html page with ifames, blink, marquee and table tags (for layout of course)
  • ctm92 11mo ago
    Recently had to grab content from a page that was layouted with tables. Just nested tables over tables, not even ids for the elements.
    • VerifiedReports 11mo ago
      laid out
    • sethaurus 11mo ago
      I invite you to view the source of the very page we're on right now.
      • znort_ 11mo ago
        thanks for this, you made my day! i never bothered to look. i still remember when tables were forced out of fashion by hordes of angry div believers! they became anathema and instantly made you a pariah. the arguments were very passionate but never made any sense to me: the preaching was separating structure from presentation, mostly to enable semantics, and then semantics became all swamped with presentation so you could get those damned divs aligned in a sensible way :-) just don't use (or abuse) them for layout but tables still seem to me the most straightforward way to render, well, tabular content.
  • altfredd 11mo ago
    You can always render blink and marquee with Canvas. Just kidding, Canvas is obsolete technology, this should obviously be done with WebGPU
    • paavohtl 11mo ago
      I know you're being sarcastic, but to be pedantic WebGPU (usually) uses canvas. Canvas is the element, WebGPU is one of the ways of rendering to a canvas, in addition to WebGL and CanvasRenderingContext2D.
• lmm 11mo ago
  Meh. RSS was great. XSLT was always awful. Javascript does everything XSLT did, so much better. Let it die.
  • silon42 11mo ago
    JS should die too. XSLT was better for some things.
    • selectnull 11mo ago
      The difference being that JS is used a lot and XSLT not so much.
    • jeltz 11mo ago
      XSLT was always a bad idea. JS is a mixed bag of good and bad ideas.
  • tedk-42 11mo ago
    Wow you got negged so hard, likely by people that have never really written XSLT code. I have and I've always hated it. I still to this day will never touch an IBM DataPower appliance, though I'm more than capable because of XSLT. They (IBM) even tried to make it more appealing by allowing Javascript to run on DataPower instead of XSLT to process XML documents. It's a crap language designed for XML (which is too verbose) and there are way better alternatives. Javascript and JSON won because of their simplicity. The Javascript ecosystem however (nodejs, npm, yarn etc) are what take away from an otherwise excellent programming language.
• yoz-y 11mo ago
  With browser being as complicated as they are, I kind of support this decision. That said, I never used XSLT for anything, and I don’t see how is its support in browsers tied to RSS. (Sure you could render your page from your rss feed but that seems like a marginal use case to me)
  • Maxious 11mo ago
    If you view an RSS or Atom feed in chrome today you just get a screen of xml eg. https://developer.wordpress.org/news/feed/ https://developer.wordpress.org/news/feed/ In the golden old days of 2018, browsers at least applied some styling https://evertpot.com/firefox-rss/ https://evertpot.com/firefox-rss/ You can still manually apply styling using xslt https://www.cedricbonhomme.org/blog/index.xml https://www.cedricbonhomme.org/blog/index.xml
    • yoz-y 11mo ago
      In Safari at least clicking a rss link prompts you to open it in a rss reader, which I think is a superior experience. Reading a rss feed in browser is not without use, but I’d argue that that’s mostly the job of the site itself.
      • zerkten 11mo ago
        The sites sometimes want to provide some special formatting on top of the RSS without modifying it. For example, you might point people to available RSS readers which may not be installed or provide other directions to end users. RSS feeds are used in places other than reading apps. I've seen people suggest that this transformation could be done server-side, but that would modify the RSS feed which needs to be consumed.
    • internetter 11mo ago
      > You can still manually apply styling using xslt Unless I'm using XSLT without knowing, you can do this with the xml-stylesheet processing instruction https://boehs.org/in/blog.xml https://boehs.org/in/blog.xml
    • 11mo ago
• gregjw 11mo ago
  they are playing us for fools!
• littlecranky67 11mo ago
  Website is overly dramatic. Google doesn't hate XSLT, it is simply no one wants to maintain libxslt and it is full of security issues. Given how rarely it is used, it is just not worth the time + money. If the author wants to raise money to pay a developer willing to maintain libxslt, Google might revise the decision.
  • testdelacc1 11mo ago
    I think they’re being dramatic for laughs.
  • troupo 11mo ago
    > it is simply no one wants to maintain libxslt and it is full of security issues. Given how rarely it is used, it is just not worth the time + money. As for money: Remind me what was Google's profit last year? As for usage: XSLT is used on about 10x more sites [1] than Chrome-only non-standards like USB, WebTransport and others that Google has no trouble shoving into the browser [1] Compare XSLT https://chromestatus.com/metrics/feature/timeline/popularity/79 https://chromestatus.com/metrics/feature/timeline/popularity... with USB https://chromestatus.com/metrics/feature/timeline/popularity/1521 https://chromestatus.com/metrics/feature/timeline/popularity... or WebTransport: https://chromestatus.com/metrics/feature/timeline/popularity/3472 https://chromestatus.com/metrics/feature/timeline/popularity... or even MIDI (also supported by Firerox) https://chromestatus.com/metrics/feature/timeline/popularity/2029 https://chromestatus.com/metrics/feature/timeline/popularity...
    • bawolff 11mo ago
      > Remind me what was Google's profit last year? Last i checked, google isn't a charity.
      • mschuster91 11mo ago
        Their products are built on open source. Android and Chrome come to my mind, but also their core infrastructure, it's all Linux and other FOSS under the hood. Besides, xkcd #2347 [1] is talking about precisely that situation - there is a shitload of very small FOSS libraries that underpin everything and yet, funding from the big dogs for whom even ten fulltime developer salaries would be a sneeze has historically lacked hard. [1] https://xkcd.com/2347/ https://xkcd.com/2347/
• adzm 11mo ago
  I can't even tell if this is satire or just hyperbole.
• sdovan1 11mo ago
  I've worked with a hospital, their electric medical records are written in XML, and use XSLT to render HTML.
  • atemerev 11mo ago
    Which is one excellent use of XSLT. It is not that useful for general web.
    • CaliforniaKarl 11mo ago
      From https://chromeenterprise.google https://chromeenterprise.google: > For over a decade, Chrome has supported millions of organizations with more secure browsing – while pioneering a safer, more productive open web for all. … and … > Our commitment to Chromium and open philosophy to integration means Chrome works well with other parts of your tech stack, so you can continue building the enterprise ecosystem that works for you. Per the current version of https://developer.chrome.com/docs/web-platform/deprecating-xslt#timeline_for_chrome https://developer.chrome.com/docs/web-platform/deprecating-x..., by August 17, 2027, XSLT support is removed from Chrome Enterprise. That means even Chrome's enterprise-targeted, non-general-web browser is going to lose support for XSLT.
      • bawolff 11mo ago
        Most people who use xslt like the grandparent described were never using it on the client side but on the server side. Nothing google chrone does will effect the server side.
    • atemerev 11mo ago
      To clarify: initially, the first web browser evolved from a SGML-based documentation browser at CERN. This was the first vision of the web: well-structured content pages, connected via hyperlinks (the "hyper" part meaning that links could point beyond the current set of pages). So, something like a global library. Many people are still nostalgic to this past. Surprisingly, the "hyperlinked documents" structure was universal enough to allow rudimentary interactive web applications like shops or reservation forms. The web became useful to commerce. At first, interactive functionality was achieved by what amounted to hacks: nav blocks repeated at every page, frames and iframes, synchronous form submissions. Of course, web participants pushed for more direct support for application building blocks, which included Javascript, client-side templates, and ultimately Shadow DOM and React. XSLT is ultimately a client-side template language too (can be used at the server side just as well, of course). However, this is a template language for a previous era: non-interactive web of documents (and it excels at that). It has little use for the current era: web of interactive applications.
• pseudosavant 11mo ago
  This site is a bit of a Rorschach test as it plays both sides of this argument: bad Google for killing XSLT, and the silliness of pushing for XSLT adoption in 2025. "Tell your friends and family about XSLT. Keep XSLT alive! Add XSLT to your website and weblog today before it is too late!"
  • karel-3d 11mo ago
    It's clearly making fun of the hyperbole.
  • James_K 11mo ago
    I already have XSLT in my website because I have an Atom feed and XSLT is the only way to serve formatted Atom/RSS feeds in a static site. Perhaps you have never considered the idea that someone might want to purchase some cheap static hosting to serve their personal website, but it is a fine way to do things. This change pries the web ever further out of the hands of common people and into the big websites that just want the browser to serve their apps.
    • javcasas 11mo ago
      There are plenty of cheap hosting out there, most cases with PHP support for the odd dynamic thing.
      • James_K 11mo ago
        How do you intend to put PHP in an RSS document? If it serves an HTML one instead, then the RSS will no longer be available. You could try checking the HTTP headers to determine if the page is being fetched by an RSS reader or a browser, but such an approach is much more brittle than XSLT, which solves the problem exactly and easily. Not to mention it allows users to download browser extensions that override the provided formatting of XSLT documents with a custom standard one if they desire.
        • javcasas 11mo ago
• skrebbel 11mo ago
  I love everything about this site. The design, the vibe, the rhetoric.. It’s a work of art!
• charcircuit 11mo ago
  > XSLT will soon enter the Google graveyard. The google graveyard is for products Google has made. It's not for features that were unshipped. XSLT will not enter the Google graveyard for that reason. >We must conclude Google hates XML & RSS! Google reader was shutdown due to usage declining and lack of willingness for Google to continue investing resources into the product. It's not that Google hate XML and RSS. It's that end users and developers don't use XSLT and RSS enough to warrant investing into it. >by killing [RSS] Google can control the media The vast majority of people in the world do not get their news by RSS. It's never would have taken over the media complex. There are other surfaces for news like X which Google is not able to control. Google is not the only surface where news can surface. > Google are now trying to control LEGISLATION. With these technologies removed what is stopping Google? It is quite a reach to say that Google removing XSLT will give them control over government legislation. They are completely unrelated. >How much did Google pay for this support? Google is not paying for support. These browsers have essentially a revenue sharing agreements with the traffic they provide Google with. The payments are for the traffic to Google.
• beardyw 11mo ago
  XSLT has a life outside the browser and remains valuable where XML is the way data is exchanged. And RSS does not demand XSLT in the browser so far as I know. I think RIP is a bit excessive.
• gucci-on-fleek 11mo ago
  I'm strongly against the removal of XSLT support from browsers—I use both the JavaScript "XSLTProcessor" functions [0] and "<?xml-stylesheet …?>" [1] on my personal website, I commented on the original GitHub thread [2], and I use XSLT for non-web purposes [3]. But I think that this website is being hyperbolic: I believe that Google's stated security/maintenance justifications are genuine (but wildly misguided), and I certainly don't believe that Google is paying Mozilla/Apple to drop XSLT support. I'm all in favour of trying to preserve XSLT support, but a page like this is more likely to annoy the decision-makers than to convince them to not remove XSLT support. [0]: https://www.maxchernoff.ca/tools/Stardew-Valley-Item-Finder/ https://www.maxchernoff.ca/tools/Stardew-Valley-Item-Finder/ [1]: https://www.maxchernoff.ca/atom.xml https://www.maxchernoff.ca/atom.xml [2]: https://github.com/whatwg/html/pull/11563#issuecomment-3190981127 https://github.com/whatwg/html/pull/11563#issuecomment-31909... [3]: https://github.com/gucci-on-fleek/lua-widow-control/blob/852ecb86/tests/transform.xslt https://github.com/gucci-on-fleek/lua-widow-control/blob/852...
  • coldtea 11mo ago
    >I use both the JavaScript "XSLTProcessor" functions [0] and "<?xml-stylesheet …?>" [1] on my personal website You are on some very very small elite team of web standards users then
    • einpoklum 11mo ago
      FYI: Many Firefox and Thunderbird extensions use <?xml-stylesheet?> . Perhaps not XSLTProcessor though.
      • mimasama 11mo ago
        WebExtensions still have them? I thought the move to HTML (for better or worse) would've killed that. Even install.rdf got replaced IIRC so there shouldn't be much traces of XML in the new extensions system...
    • ndriscoll 11mo ago
      Small, sure, but not elite. xml-stylesheet is by far the easiest way to make a simple templated website full of static pages. You almost could not make it any simpler.
• deleted 11mo ago
  [deleted]
• criticalfault 11mo ago
  > Google pays Mozilla up to $420 million per year... What the hell is Mozilla doing with that money? How useless are all those people?
  • littlestymaar 11mo ago
    Mitchell Baker has “a family to feed”. (IIRC her salary increased something like 10 folds over the past 15 years or so) Edit: It has jumped from $490k[1] to $6.25M[2] from 2009 to 2024. Edit 2: by looking the figures up, I learned that she's gone at last, good riddance (though I highly doubt her successor is going to take a 12-fold pay cut) [1]: https://static.mozilla.com/foundation/documents/mf-2009-irs-form-990.pdf https://static.mozilla.com/foundation/documents/mf-2009-irs-... page 8 [2]: https://assets.mozilla.net/annualreport/2024/b200-mozilla-foundation-form-990-public-disclosure-ty23.pdf https://assets.mozilla.net/annualreport/2024/b200-mozilla-fo... page 8 as well.
  • poly2it 11mo ago
    It bothers me they can't even seem to design a user interface that looks like it came out of the last decade. Thunderbird is an even bigger mess.
    • sunaookami 11mo ago
      At least Thunderbird makes big changes now without any big funding. Firefox on the other hand is getting.... a new mascot https://www.firefox.com/kit/ https://www.firefox.com/kit/
    • TingPing 11mo ago
      What needs changed, it’s nearly identical to Chrome
      • wpm 11mo ago
        That’s part of the problem
• troupo 11mo ago
  The web site should also use terms like "arrogant priests rule the web" from browsers' attempt to kill alert/prompt: https://www.quirksmode.org/blog/archives/2021/08/breaking_the_we.html https://www.quirksmode.org/blog/archives/2021/08/breaking_th... Also: "the needs of users and authors (i.e. developers) should be treated as higher priority than those of implementors (i.e. browser vendors), yet the higher priority constituencies are at the mercy of the lower priority ones": https://dev.to/richharris/stay-alert-d https://dev.to/richharris/stay-alert-d
• aaronrobinson 11mo ago
  Google isn’t killing XSLT. They just don’t want to support it in their browser any more. The site is misleading.
  • itsgrimetime 11mo ago
    When you have 70+% browser market share, stopping support for something _is_ killing it.
    • eXpl0it3r 11mo ago
      It is misleading in so far that XSLT is an independent standard [1] and isn't owned by Google, so they cannot "kill it", or rather they'd have to ask W3C to mark it as deprecated. What they can do is remove support for XSLT in Chrome and thus basically kill XSLT for websites. Which until now I didn't even know was supported and used. XSLT can be used in many other areas as well, e.g. for XSL-FO [2] [1] https://www.w3.org/TR/xslt-30/ https://www.w3.org/TR/xslt-30/ [2] https://en.wikipedia.org/wiki/XSL_Formatting_Objects https://en.wikipedia.org/wiki/XSL_Formatting_Objects
      • James_K 11mo ago
        You say they cannot kill it, and yet they are about to. We'll see who wins, reality or your word games.
        • aaronrobinson 11mo ago
          What are you talking about? They can’t kill it. Most use is outside the browser. It’s not about mixing words.
    • mortarion 11mo ago
      I don't think XSLT was invented for the purpose of rendering XML into HTML in the first place. Perhaps it never should have been introduced in browsers to begin with?
• imiric 11mo ago
  It's truly troubling to see a trillion dollar corporation claim that the reason for removing a web browser feature that has existed since the 90s is because the library powering it was unmaintained for 6 months, and has security issues. The same library that has been maintained by a single developer for years, without any corporate support, while corporations reaped the benefits of their work. Say what you will about how this is technically allowed in open source, it is nothing short of morally despicable. A real https://xkcd.com/2347/ https://xkcd.com/2347/ situation. It would cost Google practically nothing to step up and fix all security issues, and continue maintenance if they wanted to. To say nothing of simply supporting the original maintainer financially. But IMO the more important topic within this whole saga is that libxml2 maintenance will also end this year. Will we also see support for XML removed?
  • bawolff 11mo ago
    > Say what you will about how this is technically allowed in open source, it is nothing short of morally despicable. A real https://xkcd.com/2347/ https://xkcd.com/2347/ situation. I think https://xkcd.com/1172/ https://xkcd.com/1172/ is more fitting. > But IMO the more important topic within this whole saga is that libxml2 maintenance will also end this year. Will we also see support for XML removed? No, because xml has meaningful usage on the web. The situations are very different.
    • imiric 11mo ago
      > No, because xml has meaningful usage on the web. The situations are very different. They're really not. If "meaningful usage" was a factor, Google should stop maintaining AMP, USB, WebTransport, etc.[1] If security and maintenance are a concern, then they should definitely also remove XML, since libxml2 has the same issues as libxslt. [1]: https://news.ycombinator.com/item?id=45873787 https://news.ycombinator.com/item?id=45873787
      • TingPing 11mo ago
        There are more xml parsers than just that and it’s a smaller scope to rewrite or maintain.
• cm-t 11mo ago
  Killing RSS = killing decentralized internets (blogs, podcasts, etc) = empowering centralized plateform such as youtube, spotify (etc)
  • jeroenhd 11mo ago
    Youtube has pretty much always supported RSS and still does. Google killed their RSS reader, but if they wanted to kill RSS they wouldn't put it in their video platform. When it comes to killing web technology, Google is mostly killing their own weird APIs that nobody ended up using or pruning away code that almost nobody uses according to their statistics.
    • themafia 11mo ago
      > Youtube has pretty much always supported RSS and still does. It has RSS feeds for individual channels. It does not _support_ RSS in any meaningful way.
      • pvdebbe 11mo ago
        Can you please clarify? For me, maintaining my own watch lists, that is, per channel RSS feeds, all neatly organized in my RSS aggregator's folders, is the only way to fly.
• zkmon 11mo ago
  Looks like more of a retro-fun site, than a protest. Most serious websites of 90's had more like light brownish background with black text with occasional small image on the side, double borders for table cells, Times font, horizontal rules, links with bold font in blue color, side-bar with navigation links, bread-crumbs at the top telling where you are now, may be also next-prev links at the bottom, and a title banner at the top. Game sites and other "desperate-for-attention" sites have the animated gifs all over, scrolling or blinking text, dark background with bright multi-colored text with different font sizes and types and sound as well, looking pretty chaotic.
  • jeroenhd 11mo ago
    Professional and serious websites, yes, but there were plenty of websites on Geocities that looked very much like this. These websites may not have been the majority of the internet, but they weren't rare either. Just browsing around on a geocities website you can find pages like https://geocities.restorativland.org/CollegePark/Lounge/3449/ https://geocities.restorativland.org/CollegePark/Lounge/3449... and https://geocities.restorativland.org/Eureka/1415/ https://geocities.restorativland.org/Eureka/1415/ (audio warning on both) If anything, this retro site is a bit too modern for having translucent panels, the background not being badly tiled, and text effects being too stylish.
• eterevsky 11mo ago
  In all seriousness, XSLT looked stillborn even 25 years ago when it was introduced.
  • alexdowad 11mo ago
    Agree. It always seemed like a strange and poorly conceived technology to me.
    • DonHopkins 11mo ago
      It was just castrated DSSSL.
• deleted 11mo ago
  [deleted]
• ivolimmen 11mo ago
  Humm I agree with the statement but why does the website need to look like it is from early the 90's?
  • sunaookami 11mo ago
    Because it's fun
• hollowturtle 11mo ago
  Please kill it, and then let's sit on a table with all adults people and decide what else should be killed. Maybe specify a minimum subset of modern feature a browser must support, please let's do it, it could light on again browser competition, projects like lady browser should not implement obscure backwrads compatible layout spec... What about the not modern web sites? The browser will ask to download an extra wasm module for opening something like https://www.spacejam.com/1996/ https://www.spacejam.com/1996/
  • hollowturtle 11mo ago
    Instead of just downvoting why don't you reply with your argument?
• redbell 11mo ago
  IMHO, Google had become the most powerful tech company out there! It has a strong monopoly in almost every aspect of our lives and it is becoming extremely difficult to completely decouple from it. My problem with this is that it now dictates and influences what can be done, what is allowed and what not, and, with its latest Android saga (https://news.ycombinator.com/item?id=45017028 https://news.ycombinator.com/item?id=45017028), it's become worrying. I strongly encourage building a website entitled, something like keepXSLTAlive.tld to advocate for XSLT as the other guys did https://keepandroidopen.org/ https://keepandroidopen.org/ for Android (https://news.ycombinator.com/item?id=45742488 https://news.ycombinator.com/item?id=45742488), or keep this current site (https://xslt.rip/ https://xslt.rip/) but update the UI a little bit to better reflect the protest vibe.
  • rahkiin 11mo ago
    What you say about google might be true. And its changes to android might be bad… But that does not mean xslt should be kept alive just because of that. It should be judged on its own merits
    • _heimdall 11mo ago
      And thats part of the problem, they didn't judge it on its merits. Google judged a 25 year old spec that is now 2 major versions out of date.
      • jeltz 11mo ago
        So why is almost nobody here actually defending it on its own merits? In my opinion XSLT was a bad idea ~20 years ago when I started in web development. It was convoluted, not nice to work with and the implementations buggy. Most people seem to think it is bad because it is Google who want to remove it. Personally I just see Google finally doing something good.
        • righthand 11mo ago
          There is so much defense of XSLT it’s crazy you assume no one is here defending it. This thread isn’t the single defense point against Google. Not only that Google engineers Mason Freed has shown pretty forcefully that he will not listen to defense, reason or logic. This further evidenced by Google repeatedly trying to kill it for 25 years. Personally I just see you licking Google’s boot.
• codeulike 11mo ago
  Add XSLT to your website and weblog today before it is too late! I cannot tell if this is satire or not, very well done
• supermatt 11mo ago
  > XSLT will soon enter the Google graveyard. AFAIK the "google graveyard" is just for google products they have killed off.
  • altfredd 11mo ago
    Given that Google owns Web, it can be argued that any web tech killed by Google is a part of Google Graveyard
• lloydatkinson 11mo ago
  Who on earth approved .rip as a TLD? Stupid
  • cluckindan 11mo ago
    The seamstress
  • efilife 11mo ago
    why?
• lloydatkinson 11mo ago
  Given that XSLT transforms XML into HTML, why has no one simply built a server side XSLT system? So these existing sites that use XSLT can just adopt that, and not need to rely on browser support.
  • pferde 11mo ago
    I remember Gentoo Linux had all its official documentation in a system just like that, maybe 15-20 years ago. It was written and stored as XML, XSLT-processed and rendered into HTML on the webservers. They moved everything into a wiki later. EDIT: Oh, their developers' manual is still done like that: https://github.com/gentoo/devmanual https://github.com/gentoo/devmanual into https://devmanual.gentoo.org/ https://devmanual.gentoo.org/
  • JimDabell 11mo ago
    Server-side XSLT tools have existed for 25 years or so. The people complaining about this want existing websites using XSLT on the client to continue to work without changes.
    • mmis1000 11mo ago
      It's actually possible to support it by re-implement it by js or compile to wasm and running on client side. There are extensions to support pdf(pdf.js), flash(Ruffle), mht(UnMHT). So it should be possible to do the same thing for XSLT. The real question is "Who want to"? Does xslt have a large user base like pdf, flash, mht?
  • Fileformat 11mo ago
    I want to use it on an RSS feed: to make it sensible when a new users clicks on an RSS link. I specifically want it to be served as XML so it can still be an RSS feed: I don't even need the HTML to look that great: I have the actually website for that. Example: https://www.fileformat.info/news/rss.xml https://www.fileformat.info/news/rss.xml
• jll29 11mo ago
  Google cannot kill anything on its own. If people continue to use XML-supporting technology, these open standards will continue to thrive. I'm sure this site will be supported eventually by the Ladybird Web browser - can't wait to switch to it next August.
  • 0x073 11mo ago
    Google = Chrome = they can for most users
• tolerance 11mo ago
  This is propaganda.
• tomaytotomato 11mo ago
  My first graduate job at a large British telco involved a lot of XML... - WSDL files that were used to describe Enterprise services on a bus. These were then stored and shared in the most convoluted way in a Sharepoint page <shudders> - XSD definitions of our custom XML responses to be validated <grimace> - XSLTs to allow us to manipulate and display XML from other services, just so it would display properly on Oracle Siebel CRM <heavy sweats>
• xg15 11mo ago
  Now that XSLT has the power of Comic Sans on its side, I don't know what could possibly go wrong anymore.
• James_K 11mo ago
  To make the web safer, they will replace simple static web pages with remote code execution on the user's machine. Yet another “fuck you” to people who don't want to shove JavaScript in everything. God forbid I serve a simple static site to people. Nonono. XSLT is fantastic for people who actually want to write XML documents like the good old days, or add styling to Atom feeds. Edit: and for a slightly calmer response: Google has like, a bajillion dollars. They could address any security issues with XSLT by putting a few guys on making a Rust port and have it out by next week. Then they could update it to support the modern version in two weeks if it being out of date is a concern. RSS feeds need XSLT to display properly, they are a cornerstone of the independent web, yet Google simply does not care.
• deleted 11mo ago
  [deleted]
• rpigab 11mo ago
  If they have security in mind, they should intend to deprecate and remove HTML. The benefits of keeping it are slowly disappearing as AI content on the web is taking over, and HTML contains far more quirks than XSLT, and let's not talk about aging C codebases about HTML...
  • jeltz 11mo ago
    What security vulnerabilities do you think of? Modern html5 parsers are really good and secure. The html5 standard largely solved the issues.
• eftpotrm 11mo ago
  I'm aware I'm in a minority, but I find it sad that XSLT stalled and is mostly dead in the market. The amount of effort put into replicating most the XML+XPath+XSLT ecosystem we had as open standards 25 years ago using ever-changing libraries with their own host of incompatible limitations, rather than improving what we already had, has been a colossal waste of talent. Was SOAP a bad system that misunderstood HTTP while being vastly overarchitected for most of its use cases? Yes. Could overuse of XML schemas render your documents unreadable and overcomplex to work with? Of course. Were early XML libraries well designed around the reality of existing programming languages? No. But also was JSON's early implementation of 'you can just eval() it into memory' ever good engineering? No, and by the time you've written a JSON parser that beats that you could've equally produced an equally improved XML system while retaining the much greater functionality it already had. RIP a good tech killed by committees overembellishing it and engineers failing to recognise what they already had over the high of building something else.
  • immibis 11mo ago
    Not the minority. People can be sad that XSLT failed and also recognize that removing it from browsers is quite sensible, given the current situation.
  • VMG 11mo ago
    > by the time you've written a JSON parser that beats that you could've equally produced an equally improved XML system while retaining the much greater functionality it already had. Here is where you lose me The JSON spec fits on two screen pages https://www.json.org/json-en.html https://www.json.org/json-en.html The XML spec is a book https://www.w3.org/TR/xml/ https://www.w3.org/TR/xml/
    • geocar 11mo ago
      > The JSON spec fits on two screen pages https://www.json.org/json-en.html https://www.json.org/json-en.html It absolutely does not. From the very first paragraph: It is based on a subset of the JavaScript Programming Language Standard ECMA-262 3rd Edition - December 1999. which is absolutely a book you can download and read here: https://ecma-international.org/publications-and-standards/standards/ecma-262/ https://ecma-international.org/publications-and-standards/st... Furthermore, JSON has so many dangerously-incompatible implementations the errata for JSON implementations fills in multiple books, such as advice to "always" treat numbers as strings, popular datetime "extensions" that know nothing of timezones and so on. > The XML spec is a book https://www.w3.org/TR/xml/ https://www.w3.org/TR/xml/ Yes, but that's also everything you need to know in order to understand XML, and my experience implementing API is that every XML implementation is obviously-correct, because anyone making a serious XML implementation has demonstrated the attention-span to read a book, while every JSON implementation is going to have some fucking weird-thing I'm going to have to experiment with, because the author thought they could "get the gist" from reading two pages on a blog.
• NoboruWataya 11mo ago
  > Tell your friends and family about XSLT. I had a good chuckle at the idea of sitting around the dinner table at Christmas telling my parents and in-laws all about XSLT.
  • alfiedotwtf 11mo ago
    Don’t… you’re forgetting the Christmas of ’02 when cousin Marvin brought up the issue of Tabs vs Spaces!! Uncle Frank still holders a grudge and he’s still not on speaking terms with Adam
• insin 11mo ago
  Show people what looping over a range looks like in XSLT, you cowards! I used to generate a blog and tumblelog entirely from XML files using an XSLT processor, it will not be missed.
• postepowanieadm 11mo ago
  Love the aesthetics.
• JoTurk 11mo ago
  This is unfortunate and sad but understandable. Slightly off-topic: a friend dared me to look for a sandbox CSP bypass and I discovered one using XSLT. I reported it to Mozilla few months ago, CVE-2025-8032. https://www.mozilla.org/en-US/security/advisories/mfsa2025-56/#CVE-2025-8032 https://www.mozilla.org/en-US/security/advisories/mfsa2025-5...
• zgk7iqea 11mo ago
  Why not just write an XSLT implementation in JS/WASM, or compile the existing one to WASM? This is the same approach that Firefox uses for PDFs and Ruffle for Flash. That way it is still supported by the browser and sandboxed.
  • gucci-on-fleek 11mo ago
    This already exists, and I agree that it's the best solution here, but for some reason this was rejected by the Chrome developers. I discussed this solution a little more elsewhere in the thread [0]. [0]: https://news.ycombinator.com/item?id=45874461 https://news.ycombinator.com/item?id=45874461
    • zgk7iqea 11mo ago
      Very interesting, thanks. One point from one of the linked threads I find particularly puzzling: > I think the issue with XSLT isn't necessarily the size of the attack surface, it's the lack of attention and usage. > I.e. nearly 100% of sites use JS, while 1/10000 of those use XSLT. So all of the engineering energy (rightfully) goes to JS, not XSLT. XSLT is a finished standard. Not everything needs to evolve. If the implementation works and is safe, what speaks against keeping it?
• 01-_- 11mo ago
  What a beautiful look. I really like websites with this design :)
• juliangmp 11mo ago
  Hearing about this again and again and I still need to ask: who actually uses that, and for what? And how does it break RSS? (Which I at least heard of people using it before)
  • jeltz 11mo ago
    Some people used XSLT to style their RSS feeds when displaying them in the browser. An alternative is to use CSS to style the feeds. Personally I don't see why I would want styled feeds.
• szundi 11mo ago
  [dead]
• paulirish 11mo ago
  A counterpoint to the idea that this is entirely Google's doing: https://meyerweb.com/eric/thoughts/2025/08/22/no-google-did-not-unilaterally-decide-to-kill-xslt/ https://meyerweb.com/eric/thoughts/2025/08/22/no-google-did-...
  • jannes 11mo ago
    I think you should disclose that you work on the Google Chrome team in a post like this.
    • paulirish 11mo ago
      Yeah my bad; I was on the go. I'm on the Chrome team, I work on DevTools.
  • righthand 11mo ago
    This is no way a counter point. You don’t get to be a billion dollar company that can fix XSLT and ignore other libraries without security issues and tell us it’s broken. Fuck Google you tyrants, all the dissenting opinions in this thread about XSLT are clearly Google employees.
• guerrilla 11mo ago
  So sad. I love XSLT. I wish XML had been the thing instead of JSON.
• ChrisMarshallNY 11mo ago
  That’s a “classic”-looking site! Lots of Comic Sans and animated GIFs (which means that I still have XSLT, I guess).
• SuperHeavy256 11mo ago
  But what is XSLT? Why is it important? These points should be addressed first on the website.
• egorfine 11mo ago
  I truly loved XSLT back in the day and I strongly believe it to be an ingenious technology. And I truly believe it's time to retire this monstrosity.
• boesboes 11mo ago
  Got to love the github issue, show exactly the sad state of things. Google owns the internet now and we are all chumps for even thinking there is anything open left. Disenting opinions will be marked as abuse!
• conartist6 11mo ago
  I haven't been too chatty about it but the furor over this being removed has, I suspect, everything to do with there being no real plan to replace what it does. No I don't just mean styling RSS feeds. I mean writing websites as semantic documents!! The whole thing the web is (was) about!
• rob 11mo ago
  I tried to use a PHP CMS called Symfony that used XSLT back in the early to mid 2000s. Was definitely interesting and a learning curve.
• rurban 11mo ago
  It's not dead yet, a new maintainer showed up. But, Google Chrome decided to ditch it, which is fine by me. It was a cluster fuck, similar to libxml2, but even worse. Good old DSSSL days, sigh.
• lambdaone 11mo ago
  There is absolutely nothing to prevent anyone from generating arbirary DOM content from XML using JS; indeed, there's nothing stopping them from creating a complete XSLT implementation. There's just no need to have it in the core of the browser.
  • phantasmish 11mo ago
    You don’t need to generate anything with JavaScript, aside from one call to build an entire DOM object from your XML document. Boom, whole thing’s a DOM. I guess the fact that it’s obscure knowledge that browsers have great, fast tools for working directly with XML is why we’re losing nice things and will soon be stuck in a nothing-but-JavaScript land of shit. Lots of protocols are based on XML and browsers are (though, increasingly, “were”) very capable of handling them, with little more than a bridge on the server to overcome their inability to do TCP sockets. Super cool capability, with really good performance because all the important stuff’s in fast and efficient languages rather than JS.
• susam 11mo ago
  End of an era! I remember going through XSLT tutorials many decades ago and learning everything there was to learn about this curious technology that could make boring XML documents come 'alive'. I still use it to style my RSS feeds, for example, <https://susam.net/feed.xml https://susam.net/feed.xml>. It always felt satisfying that an XML file with a stylesheet could serve as both data and presentation. Keeping links to the original announcements for future reference: 1) <https://groups.google.com/a/chromium.org/g/blink-dev/c/CxL4gYZeSJA/m/yNs4EsD5AQAJ https://groups.google.com/a/chromium.org/g/blink-dev/c/CxL4g...> 2) <https://developer.chrome.com/docs/web-platform/deprecating-xslt https://developer.chrome.com/docs/web-platform/deprecating-x...> I know that every such feature adds significant complexity and maintenance burden, and most people probably don't even know that many browsers can render XSLT. Nevertheless, it feels like yet another interesting and niche part of the web, still used by us old-timers, is going away.
• Tepix 11mo ago
  Since the XSLTProcessor feature can be realized with a Polyfill (https://github.com/mfreed7/xslt_polyfill https://github.com/mfreed7/xslt_polyfill), I find myself agreeing with Google. Btw, I love this page! Highly entertaining, yet at the same time use of XSLT.
  • NoGravitas 11mo ago
    If they were going to ship the xslt polyfill by default with Chrome, I wouldn't disagree.
  • axus 11mo ago
    Does it uh work with RSS?
• Devasta 11mo ago
  I know that XSLT can be implemented in JS (and I have used Saxon-JS, its good!) but the loss of functionality for the XML processing instruction will be a shame. There is nothing like in the modern web stack, such a pity.
• 8organicbits 11mo ago
  It's interesting that we don't have a replacement for this use case. For me, XSLT hits a sweet spot where I can send a machine-parsable XML document and a small XSLT sheet from dirt cheap static web hosting (where I cannot perform server-side transforms, or control HTTP headers). This is fairly minimal and avoids needing to keep multiple files in sync. I could add a polyfill, but that adds multiple MB, making this approach heavyweight.
  • crazygringo 11mo ago
    Multiple MB? I'm looking at: https://github.com/mfreed7/xslt_polyfill https://github.com/mfreed7/xslt_polyfill Which uses: https://github.com/DesignLiquido/xslt-processor/tree/main https://github.com/DesignLiquido/xslt-processor/tree/main But they don't look that heavy. Am I missing something? Megabytes of JS would be enormous.
    • svieira 11mo ago
      > The implementation is all agnostic about namespaces. It just expects XSLT elements to have tags that carry the xsl: prefix, but we disregard all namespace declaration for them. Just for a start. It's a tiny polyfill for a tiny subset of the thing that is XSLT 1.0.
    • 8organicbits 11mo ago
      xslt-polyfill.min.js is 1.3 MB on its own https://github.com/mfreed7/xslt_polyfill/blob/main/xslt-polyfill.min.js https://github.com/mfreed7/xslt_polyfill/blob/main/xslt-poly...
      • crazygringo 11mo ago
        I see, thank you -- so it's not the JavaScript part, it's basically 99% a huge WASM blob. I can understand not wanting to include something like that, yikes.
• eversor1 11mo ago
  XSLT was once described to me as "Pain wrapped in Hate", and I fully agree. I'm truly shocked that there is ANY opposition to it's removal and retirement.
  • nashashmi 11mo ago
    Stockholm Syndrome: we went thru the torture of learning it. And now we love it
    • wpm 11mo ago
      Or more charitably: this hard to master tool is hard to master but incredibly useful once you learn it
• righthand 11mo ago
  This is about forcing everyone into Json. Incredibly sad the amount of “just take Google’s word for it” in this thread. We have truly lost our way as a tech embraced society and eschew reason. There is a reason the lead Google engineers initials are “MF”.
• tannhaeuser 11mo ago
  Worth noting XSLT is actually based on DSSSL, the Scheme-based document transformation and styling language of SGML. Core SGML already has "link processes" as a means to associate simple transforms/renames reusing other markup machinery concepts such as attributes, but is also introducing a rather low-level automaton construct to describe context-dependent and stateful transformations (the kind of which would've be used for recto/verso rendering on even/odd print pages). I think it's interesting because XSLT, based on DSSSL, is already Turing-complete and thus the XML world lacked a "simple" sub-Turing transformation, templating, and mapping macro language that could be put in the hands of power users without going all the way to introduce a programming language requiring proper development cycles, unit testing, test harnesses, etc. to not inevitably explode in the hands of users. The idea of SGML is very much that you define your own little markup vocabulary for the kind of document you want to create at hand, including powerful features for ad-hoc custom Wiki markup such as markdown, and then create a canonical mapping to a rendering language such as HTML; a perspective completely lost in web development with nonsensical "semantic HTML" postulates and delivery of absurd amounts of CSS microsyntax.
  • user3939382 11mo ago
    Completely correct and the operative phrase here is “absurd amounts” which actually captures our entire contemporary computing stack in almost every dimension that matters.
    • tannhaeuser 11mo ago
      The entire point of markup attributes is to contain rendering hints that themselves aren't rendered to the user as such. Hell, angle-bracket markup itself was introduced to unify and put a limit to syntactic proliferation. But somehow "we" arrived at creating the monstrosity that is CSS and then even to put CSS and JS into inline element content with bogus special escaping and comment parsing rules rather than into attributes and external resources. The enormous proliferation of syntax and super-complicated layout models doesn't stop markup haters to cry wolf because entities (text macros) represent a security risk in markup however; go figure.
  • 11mo ago
• shevy-java 11mo ago
  I don't really need or use XSLT (I think), so I am not really affected either way. But I am also growing mightily tired of Google thinking "I am the web" now. This is really annoying to no ends. I really don't want Google to didctate onto mankind what the web is or should be. Them killing off ublock origin also shows this corporate mindset at work. This is also why I dislike AI browsers in general. They generate a view to the user that may not be real. They act like a proxy-gate, intercepting things willy-nilly. I may be oldschool, but I don't want governments or corporations to jump in as middle-man and deny me information and opportunities of my own choosing. (Also Google Suck, I mean Google Search, sucks since at the least 5 years now. That was not accidental - that was deliberate by Google.)
  • drob518 11mo ago
    I’m old-school right there with you. The fact that there are really only three browser codebases now is concerning.
    • fithisux 11mo ago
      Extremely concering. On the other hand ... with the danger of sounding funny... there are way more browsers for gemini or gopher!
      • drob518 11mo ago
        At this point, however, there are probably more browsers for gopher than there are servers for gopher. /sarc
        • fithisux 11mo ago
          :-)
  • alt187 11mo ago
    That sums up pretty much how I think about that. I don't have any opinion about XSLT either way... I'm just so tired. If Google decided to kill HTML tomorrow- who could stop them?
• dinkelberg 11mo ago
  If you want to keep XSLT in browsers alive, you should develop an XSLT processor in Rust and either integrate it into Blink, Webkit, Gecko directly, or provide a compatible API to what they use now (libxslt for Blink/Webkit, apparently; Firefox seems to have its own processor).
  • sedatk 11mo ago
    > you should or a multi-trillion dollar company should.
    • dinkelberg 11mo ago
      Fair point. But probably not going to happen...
  • krackers 11mo ago
    There's no need; they already have a polyfill for XSLT I believe, they could ship that as part of the browser. Or compile libxslt to webassembly
• saltysalt 11mo ago
  That website is delightfully old-school. Love it.
• NooneAtAll3 11mo ago
  I wish websites like these would actually explain what the thing being talked about it wtf is XSLT?
• zerkten 11mo ago
  Did a JS polyfill ever go anywhere? There is a comment on https://groups.google.com/a/chromium.org/g/blink-dev/c/zIg2KC7PyH0/m/S1swVlhZc9UJ https://groups.google.com/a/chromium.org/g/blink-dev/c/zIg2K... which suggests that it might be possible, but a lot has changed. I suspect any effort died with continued availability after the first attempt to kill XSLT.
• shadowgovt 11mo ago
  Poe's Law fully in effect here. Given the 90s-era eye-gouge layout, I can't tell if the author endorses continued support of XSLT or is doing a "Modest Proposal"-style satire by conflating those who support continued native implementation of XSLT with those who pine for the days when most of the web looked like this.
  • deleted 11mo ago
    [deleted]
• exploderate 11mo ago
  I wish there was a native XSLT library for Golang. Every model wants to shell out or requires CGO.
• tuveson 11mo ago
  If Google cured cancer tomorrow, there's someone that would be complaining about it and adding "cancer" to the "killed by Google" list. I would be very surprised if smaller browser vendors were happy about having to maintain ancient XSLT code, and I doubt new vendors were planning on ever adding support. Good riddance.
  • mouse_ 11mo ago
    > smaller browser vendors Such as???
    • RGBCube 11mo ago
      Mozilla.
  • hrimfaxi 11mo ago
    Smaller browser vendors already pick and choose the features they support. Which companies do you have in mind that are cheering for this initiative?
    • tuveson 11mo ago
      The post specifically calls out Apple and Mozilla as wanting to get rid of XSLT support, but just insinuates that this is because Google is paying them off. Obviously I think Google's monopoly position and backroom dealings are bad, but I also think that's completely unrelated, and that the more likely explanation for the other mainstream vendors wanting to get rid of XSLT is that it's a feature virtually no one uses and is likely a maintenance burden for the other non-Chromium browsers. > Smaller browser vendors already pick and choose the features they support. If there weren't a gazillion features to support, maybe there would be more browsers. I think criticizing Google and other vendors for _adding_ tons of bloat would be a better use of time.
• vbezhenar 11mo ago
  XSLT was the only convenient way to create a static website without JS. Other ways either require build step or server-side applications. With XSLT, you could write data into XML files, templating into XSL files and it'll just work. Of course you can achieve similar effects with JS, by downloading data files and rendering them into whatever HTML you want. But that cuts users without enabled JS. Not a huge loss, I guess, given the lack of popularity of these technologies. But loss nonetheless. One more step to bloated overengineered web.
  • DonHopkins 11mo ago
    > But that cuts users without enabled JS. Users who disable JS are insane and hypocritical if they don't also disable XSLT, which is even worse. So I wouldn't bend over too far backwards to support insane hypocrites. There aren't enough of them to matter, they enjoy having something to complain about, and they're much louder and more performative than the overwhelming majority of users. Not a huge loss cutting them out at all.
    • vbezhenar 11mo ago
      I don't think you can disable XSLT without patching browser. For disabling JavaScript, there are dedicated checkboxes in every browser.
    • deleted 11mo ago
      [deleted]
• johndubchak 11mo ago
  I knew XSLT was just a passing fad...it only took 30 years of my career for it to pass...lol.
• raminf 11mo ago
  Many years ago, I was leading a team that implemented a hyperfast XML, XSLT, XPath parser/processor from the ground up in C/C++. This was for a customer project. It also pulled some pretty neat optimizations, like binary XSLT compilation, both in-mem and FS caching, and threading. On the server-side, you could often skip the template file loading and parsing stages, parallelize processing, and do live, streaming generation. There was also a dynamic plugin extension system and a push/pull event model. The benchmarks were so much better than what was out there. Plus, it was embeddable in both server and client app code. Would have been great if it had been open-sourced, but they paid for all the development and owned the codebase. They wanted to use it to dynamically generate content for every page for every unique device and client that hit their server. They had the infrastructure to do that for millions of users. The processing could be done on the server for plain web browsers or embedded inside a client binary app, so live rendering to native could be done on-device. Back then, it was trivial to generate XML on-the-fly from a SQL-based database, then send that back, or render it to XHTML or any other custom presentation format via XSLT. Through XSD schema, the format was self-documenting and could be validated. XSLT also helped push the standardizing on XHTML and harness the chaos of mis-matched HTML versions in each browser. It was also a great way to inject semantic web tags into the output. But I always thought it got dragged down with the overloaded weight of SOAP. Once REST and Node showed up, everyone headed for new pastures. Then JS in browsers begat SPAs, so rendering could be done in the front-end. Schema validation moved to ad-hoc tools like Swagger/OpenAPI. Sadly, we don't really have a semantic web alternative now and have to rely on best guesses via LLMs. For a brief moment, it looked like the dream of a hyper-linked, interconnected, end-to-end structured, realtime semantic web might be realizable. Aaand, then it all went poof. TL;DR: The XML/XSLT stack nailed a lot of the requirements. It just got too heavy and lost out to lighter-weight options.
• nflekkhnnn 11mo ago
  Is it possible to disable xslt rendering today already, perhaps with a browser flag? For security.
• layer8 11mo ago
  Oh man, it even has a custom mouse cursor!
• mvdtnz 11mo ago
  It has been absolutely bizarre to watch people here pretend they like or even care about XSLT just because the big bad google is killing it.
• 6thbit 11mo ago
  OP, how dare you make the guestbook button fake :(
• richard_todd 11mo ago
  I think the problem with XSLT is that it's only a clear win to represent the transform in XML to the extent that it is declarative. But, as transformations get more complex, you are going to need functions/variables/types/loops, etc. These got better support in XSLT 2 and 3, but it's telling that many xslt processors stuck with 1.0 (including libxslt and the Microsoft processors). I think most people realized that once they need a complex, procedural transformation, they'd prefer using a traditional language and a good XML library to do it. I don't like seeing any backward compatibility loss on the web though, so I do wish browsers would reconsider and use a js-based compatibility shim (as other comments have mentioned).
• neilv 11mo ago
  I have a little bit of skepticism about the move by Google (and you should usually be very skeptical, any time Web standards or Web "security" are talked about, lately), but... The gaudy retro amateur '95 design of this page might suggest the idea "anyone only cares about this for strange nostalgia reasons". Content-wise, I think this argument is missing a key piece: > Why does Google hate XML? > RSS is used to syndicate NEWS and by killing it Google can control the media. XSLT is used worldwide by [multiple government sites](https://github.com/whatwg/html/issues/11582 https://github.com/whatwg/html/issues/11582). Google are now trying to control LEGISLATION. With these technologies removed what is stopping Google? Google wanting RSS/Atom dead, presumably for control/profit reasons, is very old news. And it's old news that Big Tech eventually started playing ball with US-style lobbying (to influence legislation) after resisting for a long time. But what does the writer think is Google's motivation for temporarily breaking access to US Congress legislative texts and misc. other gov't sites in this way (as alleged by that `whatwg` issues link)? What do they want, and how does this move advance that? We can imagine conspiracy theories, including some that would be right at home on a retro site with animated GIFs and a request to sign their guestbook, but the author should really spell out what they are asserting.
• notepad0x90 11mo ago
  OP, I love the site. teach me this dead art of HTML! :) Also, doesn't Excel use XSLT or am I thinking of something else?
• j45 11mo ago
  It's hard enough to get all browsers to agree on standards in the same way, let alone staying on top of removing things that are there and might get discovered as being useful.
• pipeline_peak 11mo ago
  >RSS is used to syndicate NEWS and by killing it Google can control the media They can also avoid wasting resources on a format only used by “Raspberry Pi guys”. “I just made an app that tracks local tandem bikes in the San Francisco Bay area”
• nashashmi 11mo ago
  Does anyone know of any XML viewing apps that support XSLT 3.0?
• LtdJorge 11mo ago
  Cool usage of XSLT: https://tomi.vanek.sk/ https://tomi.vanek.sk/ a WSDL viewer implemented as a set of XSLT transformations that translate the original XML definitions into HTML.
• thro1 11mo ago
  For me, it happened in that moment when XMLHttpRequest was the only working common denominator for few "new" techniques browsers - as iframe was over everything you couldn't just load some content into target like in Netscape - but you had to use JS anyway after that to move it out of first plane. Because I wasted my time to reach some working ways to get the results by scripting, it leave me no time actually to think about it in any other way (like to prove for it the next few things I saw coming to the client side soon after, which I used to know from earlier thanks eXist-db). I took me some time, much later, to learn about such few incredible things - that if working, would make my job so.. basic - just, if, again few things described as bugs, were fixed at that time. Without that, just that happen: you wanted the results you have code it yourself - regarding or regardless of few bugs making simple things being hard corner cases with interoperability problems that can't be solved. Since then, I understand that with JavaScript it's just easier to keep fixing things ad hoc not worrying to much about standards, implementations . - than, actually to keep asking for few things or key bugs to be fixed, for more than 20 years - and to not see that ever. . The legacy is that, we can no longer get there where simple things can just interoperate (is it old school now ?) - but some generation later actually not aware why, has such imperative mindset of micromanagement that they can not even imagine self not implementing repetitively something just because in some other world after long way it was already abstracted once - but just not ever implemented once to work in same consistent way and as intended between browsers. From that point of view it's quite easy to not worry about or to abolish standards - you can't do much about implementations elsewere or bugs - but you can do whatever you want with your code (so long no one will remind you - will it last when other things change ?). That's sad actually, as I se it, that Javascript Document Programmers keep repeating and will be repeating same works, unaware of reasons for that - few bugs here and there, for 20 years not fixed once or in same common way. But how "random" were all that things leading to that point: with JavaScript all is possible and everything else is redundant ? ( only a hammer can work ?) - then look at example: https://news.ycombinator.com/item?id=45183624 https://news.ycombinator.com/item?id=45183624 - what's there look like simplest abstract form and what's like redundant ? P.S. RIP WWW (?) (JS is not a W3 standard)
• lopsotronic 11mo ago
  As a man locked inside of a closet made mostly of XSL, my only regret is that I can't drown it in a bathtub myself. The XML Priesthood will immediately jump down your throat about "XSL 3 Fixes All Things" or "But You're Not Doing It Correctly", and then point towards a twenty year old project that has five different proprietary dependencies, only two of which even still have a public cost. "Email Jack for Pricing". And all this time, the original publishing requirement for these stone age pipelines is completely subsumed by the lightweight markup ecosystem of the last decade, or, barring that, that of TeX. So much complexity for no reason whatsoever, I am watching man-centuries go up in frickin' smoke, to satisfy a clique of semantic academics who think all human thought is in the form of a tree. The horror, the horror.
• AlienRobot 11mo ago
  I have never seen a more trustworthy website in my life.
• creatonez 11mo ago
  The RSS argument makes no sense to me. Viewing styled RSS feeds in your browser is not a conventional way to use RSS, and is not what hardcore RSS users actually want (which is, a unified UI for all their news, without any fancy style, and without any place to even put ads). The styled version of an RSS feed, in the rare circumstances it even exists, is specifically for the non-technical users, who will be perfectly happy with a polyfilled or backend implementation.
• jedimastert 11mo ago
  Wow, what an absolute blast from the past. The page styling is harkening back to the style of some EARLY early personal amateur niche sites. It reminds me of like Time Cube <https://web.archive.org/web/20150506055228/http://www.timecube.com/index.html https://web.archive.org/web/20150506055228/http://www.timecu...> or like Neocity pages, even TempleOS in the earlier days. T It's really taking me back, I'm actually getting a little emotional...
• 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. Not a fancy stuff.