October 30, 2026 at 8:54:27 PM UTC

	Since	posts	replies	likes	reposts and quotes	views
Bluesky	May 2023	1,039	8,236	23,127	2,380
Mastodon	Nov 2022	2,399	29,156	55,396	16,820
GitHub	Jul 2010	179	5,777 3,520	33,866	3,317
npm	Jul 2014	139	1,546			75,991,720
YouTube	Dec 2015	30		1,203		32,713
Letterboxd	Mar 2026	55
Blog	Nov 2025	20
Hacker News	Jan 2011	59	575	802
All	Jul 2010	4,807	37,967	114,394	22,517	76,024,433

uh… I guess I knew y’all were going to remove XSLT but is a user-level error for it really the tact you want to take here? 🥵

Also posted to Mastodon.

40 replies

Philipp Tootloff Mastodon 4 min later

@zachleat How many ports could one man need
Private reply Mastodon 4 min later
Private reply Bluesky 19 min later
1. Zach Leatherman Bluesky 59 min later
  
  …oh no
Stuart Langridge Mastodon 32 min later

@zachleat I have a certain amount of sympathy with the browser team here because… there’s nobody else you can show the error to. A way to have a failing web page email its creator would be fabulous for this but it doesn’t exist. I think what chrome are doing here is bad, I agree. I’m not sure what else they can do. Maybe they should do nothing: that’s about it.
https://www.kryogenix.org/days/2023/01/02/what-to-do-about-hotlinking/ is this same problem from a different angle and I didn’t know what to do about it there either.
1. Zach Leatherman Mastodon 1 hr later
  
  @sil hmm… I guess I had expected that they would just inject the XSLT JS polyfill clientside. Not ideal but better than this.
  1. Stuart Langridge Mastodon 8 hr later
    
    @zachleat but that’s not “drop support for xslt”, which is clearly their goal here. That’s “keep supporting it when you don’t wanna” :)
    1. Zach Leatherman Mastodon 16 hr later
      
      @sil oh, they maintained the polyfill? Let me maintain the polyfill, then! 🫣
      1. Stuart Langridge Mastodon 17 hr later
        
        @zachleat no no, if they inject a polyfill then... that's them supporting xsl, right? and they want to not support it. (I don't think there's a meaningful difference between "we support XSL in browser" and "we automatically inject JS which supports XSL". In particular, if you file a bug about it, getting told "we won't fix that because we don't actually support it, technically it's JS that's auto-injected by us but it's not actually us, so no fixes for you" is for the birds as an answer)
        
        Zach Leatherman Mastodon 17 hr later
        
        @sil i’m confused what the goal is here 😅
        
        Stuart Langridge Mastodon 20 hr later
        
        @zachleat maybe I'm being dim today? I think:
        1. chrome want to stop supporting xsl entirely, so XML pages will just display as XML and won't be transformed
        2. they don't have a way to tell people who publish such pages to prep for this, so they put a notice up for the users of those pages instead
        3. we are all sad about how a web user, the one person guaranteed to not be able to help with it, gets given an error message they can't resolve
        but we're unsure whether "no error message" is worse?
2. Robin Whittleton Mastodon 20 hr later
  
  @sil @zachleat oh hang on, this is a _browser_ error? Why’s it injected into the viewport and which designer signed off on it? That’s awful!
  1. Stuart Langridge Mastodon 21 hr later
    
    @robinwhittleton @zachleat oh! maybe this is totally my misunderstanding and it's been added by that webpage itself? if it's not being put there by the browser then I have completely misunderstood and you should ignore everything I've said while I go and sit on the step for stupid boys.
    If the website themselves are putting a big red user-facing error on a page they own rather than *fixing* it then yeah totally I entirely understand why Zach's questioning it! why would you do that? that's crap!
    1. Zach Leatherman Mastodon 23 hr later
      
      @sil @robinwhittleton I have full control of that code so I didn’t add the error! I suppose I may have missed something there but my read was that it is a browser level error message
Peter Wilson Mastodon 1 hr later

@zachleat I haven’t checked recently but at some point Chrome was showing both that error and a warning for missing style sheets.
1. Zach Leatherman Mastodon 1 hr later
  
  @peterwilsoncc ugh.
Zach Leatherman Mastodon 1 hr later

filed a few followups to this, for interested folks:
https://github.com/11ty/eleventy-base-blog/issues/264
https://github.com/11ty/plugin-rss/issues/106
1. Bob Monsour Mastodon 2 hr later
  
  @zachleat Damn! Just looked at my XSLT-styled RSS feed and got that whack-job warning.
  1. Zach Leatherman Mastodon 3 hr later
    
    @bobmonsour I did push a workaround at that issue (but it’s client JS 🥹)
    1. Bob Monsour Mastodon 1 day later
      
      @zachleat Works like a charm!
      https://bobmonsour.com/feed.xml
    2. Bob Monsour Mastodon 1 day later
      
      @zachleat And, of course, this…
      https://11tybundle.dev/feed.xml
    3. Bob Monsour Mastodon 1 day later
      
      @zachleat Confession…I used Claude to extract my former XSL styles and changed the pretty-atom-feed.js to refer to a css file that reflects that earlier look. I’m seeing a FOUC, but the result looks like it used to without the Chrome shenanigans.
      1. Bob Monsour Mastodon 1 day later
        
        Minimized the FOUC by inlining the CSS with the pretty-atom-feed.js file rather than loading it separately.
Zach Leatherman Bluesky 1 hr later

filed a few followups to this, for interested folks:

github.com/11ty/elevent...
github.com/11ty/plugin-...
Conor 💻 Mastodon 1 hr later

@zachleat There’s a poly-fill for it.
1. Zach Leatherman Mastodon 2 hr later
  
  @conr I want the browser to do it 🫣
Marcin Wichary Mastodon 3 hr later

@zachleat That looks so awful, too.
1. Zach Leatherman Mastodon 6 hr later
  
  @mwichary Yeah. Scary and verbose, fine—but make it well designed!
Amelia Bellamy-Royds Mastodon 7 hr later

@zachleat And if the site owner creates a polyfill that only loads if the XSLT instructions aren't processed by the browser... how the heck do they tell the browser not to show that warning?
I guess your JS also has to remove the xml-stylesheet processing instruction?
1. Zach Leatherman Mastodon 2 days later
  
  @AmeliaBR oh.
  oh no. I’d be surprised if that worked
  1. Amelia Bellamy-Royds Mastodon 3 days later
    
    @zachleat Either way, it's not much help for the use case of styling an RSS xml feed to be user-friendly if viewed in a browser. I don't know how you'd load a JS polyfill for that!
    1. David O'Brien Mastodon 3 days later
      
      xslt was *entirely* ridiculous, except in this one use case: making RSS [other XML formats exist] human readable.
      It should have been retained for that.
      @AmeliaBR @zachleat
      1. David O'Brien Mastodon 3 days later
        
        I mean:
        <xslt:otherwise>
        
        </xslt:otherwise>
        @AmeliaBR @zachleat
        
        Zach Leatherman Mastodon 3 days later
        
        @iamdavidobrien @AmeliaBR I *loved* XSLT in the IE days, it was so much faster than DOM — lots of fun perf hacks
    2. Zach Leatherman Mastodon 3 days later
      
      @AmeliaBR oh: just in case our conversation wires are crossed here https://demo-base-blog.11ty.dev/feed/feed.xml has a working example of that! (not a polyfill though)
      and https://github.com/benmillett/11tyTweaks/tree/main/feed has a script for it too!
      1. Amelia Bellamy-Royds Mastodon 3 days later
        
        @zachleat Oh, good to know that works! (HTML script element in an RSS feed)
        But yeah, then it's definitely a problem if Chrome's sticking user-facing errors on something that was designed for graceful degradation.
Florens Verschelde Mastodon 8 hr later

@zachleat <del>don't</del> <ins>loudly</ins> break the Web
Patrick H. Lauke Mastodon 10 hr later

@zachleat from the folks who tried to convince the world that AMP was the future, and who are hell-bent on putting "agentic" webMCP bullshit everywhere
1. Adam DJ Brett Mastodon 1 day later
  
  @patrick_h_lauke @zachleat This part right here
Adam DJ Brett Mastodon 1 day later

@zachleat why are they deprecating something that has been around since 1999 instead of supporting an open source project and @zachleat, why are they deprecating something that has been around since 1999 instead of supporting an open-source project and spec with so many wonderful uses? I mean, they have the money. I know the answer, but it still makes me sad to see the corporate web killing features that are open source, useful, and important, and that break backward compatibility. spec that has so many wonderful uses? I mean, they have the money. I know the answer, but it still makes me sad to see the corporate web killing features that are open source, useful, important, and break backward compatibility.