Post Awph6kSdGm4DgHaeEC by js@podcastindex.social
 (DIR) More posts by js@podcastindex.social
 (DIR) Post #Awph6kSdGm4DgHaeEC by js@podcastindex.social
       2025-08-04T15:20:56Z
       
       0 likes, 0 repeats
       
       XSLT on the chopping block?goodbye good-looking podcast RSS feeds...https://github.com/whatwg/html/issues/11523
       
 (DIR) Post #Awph6licaoS1aA4vmy by dave@podcastindex.social
       2025-08-04T17:17:51Z
       
       0 likes, 0 repeats
       
       @js Asking for engagement...https://github.com/whatwg/html/issues/11523#issuecomment-3151679326cc: @tomrossi7 @mijustin @alberto @Todd_Blubrry @c
       
 (DIR) Post #Awpn7GCvpqkNrnsEHg by alcinnz@floss.social
       2025-08-04T18:19:44Z
       
       1 likes, 0 repeats
       
       @js You know, as someone who dislikes clientside JavaScript...To be consistent I also have to dislike clientside XSLT. They're both turing complete!(yes, the argument has been made about HTML/CSS)But yes: I do wish browsers would bother making RSS feeds look good by default! Again.
       
 (DIR) Post #Awpnyrt0Tfs64a7FiK by lanodan@queer.hacktivis.me
       2025-08-04T18:34:51.234745Z
       
       0 likes, 0 repeats
       
       @alcinnz @js Yeah, although XSLT is very simple API-wise, like could sandbox libxslt with pipes/socket and render the turing-completeness of it nearly nil by having say a request timeout.That's something you can't do with JavaScript since it needs access to the DOM among other APIs in an eventful manner.
       
 (DIR) Post #Awr86qhQxwoQwzkIjo by james@bne.social
       2025-08-05T09:55:05Z
       
       0 likes, 0 repeats
       
       @dave @js @tomrossi7 @mijustin @alberto @Todd_Blubrry Vivaldi just puts its own skin over any RSS feed.Safari just tries to download it and never shows it to you anyway.Seems to me that if the deprecation meant Vivaldi's approach (i.e. just display it vaguely OK) that's probably all we need.
       
 (DIR) Post #Awr94xxx4vXkrV8cQC by dave@podcastindex.social
       2025-08-05T10:05:59Z
       
       0 likes, 0 repeats
       
       @james @js @tomrossi7 @mijustin @alberto @Todd_Blubrry Agree.  I just want it not to display raw XML.  That would be completely befuddling to end users.  Even better if they could recognize the podcast namespace, if declared, and display it as what it actually is.
       
 (DIR) Post #AwrAaLeJAu9BFGTgem by alberto@podcastindex.social
       2025-08-05T10:22:53Z
       
       0 likes, 0 repeats
       
       @dave @james @js @tomrossi7 @mijustin @Todd_Blubrry I just chimed in on the GitHub thread. For us, the main use case is adding a "skin" on top of XML: any lightweight solution that enables that would be enough.
       
 (DIR) Post #AwrGj7b3OH0JzeWRCC by alberto@podcastindex.social
       2025-08-05T10:24:18Z
       
       0 likes, 0 repeats
       
       @dave @james @js @tomrossi7 @mijustin @Todd_Blubrry That said, I have always appreciated XSL's logic. Just last week I was testing a new XSL that we're about to roll into production: we had a feed with over 5k episodes and 2.5GB of data loaded each time it was opened in a browser, because the XSL rendered all episode artwork 🤯  I added logic to limit it to the latest 25 episodes. Pretty neat! Test feed: https://podcastgenerator.net/TESTS/newxsl/feed-large.xmlBut honestly, I’d be happy with just the visual skin functionality.