4 ms·

Can’t you just do the xslt transformation server-side? Then you can use the newest and best xslt tools, and the output will work in any browser, even browsers t

by bazoom42 11mo ago

Can’t you just do the xslt transformation server-side? Then you can use the newest and best xslt tools, and the output will work in any browser, even browsers that never had any built-in xslt support.

gucci-on-fleek 11mo ago
> Cant you just do the xslt transformation server-side? For my Atom feed, sure. I'm already special-casing browsers for my Atom feed [0], so it wouldn't really be too difficult to modify that to just return HTML instead. And as others mentioned, you can style RSS/Atom directly with CSS [1]. For my Stardew Valley Item Finder web app, no. I specifically designed that web app to work offline (as an installable PWA), so anything server-side won't work. I'll probably end up adding the JS/wasm polyfill [2] to that when Chrome finally removes support, but the web app previously had zero dependencies, so I'm a little bit annoyed that I'll have to add a 2MB dependency. [0]: https://github.com/gucci-on-fleek/maxchernoff.ca/blob/8d3538b4/web/caddy/etc/base.caddyfile#L229-L236 https://github.com/gucci-on-fleek/maxchernoff.ca/blob/8d3538... [1]: https://news.ycombinator.com/item?id=45874305 https://news.ycombinator.com/item?id=45874305 [2]: https://github.com/mfreed7/xslt_polyfill https://github.com/mfreed7/xslt_polyfill
mmis1000 11mo ago
That is actually mozilla's stand in the linked issue except it's on client though. They would rather replace it with some non native replacement (So there is no surprising security issue anymore) if remove directly is impractical. There is actually a example of such situation. Mozilla removed adobe pdf plugin support a long time ago and replaced it with pdf.js. It's still a slight performance regression for very giant pdf. But it is enough for most use case. But the bottom line is "it's actually worth to do it because people are using it". They won't actively support a feature that little people use because they don't have the people to support it.
- wombatpm 11mo ago
  > They won't actively support a feature that little people use because they don't have the people to support it. Companies always cut too deep. If only they were making enough money to properly support Chrome. /sarcasm
Fileformat 11mo ago
On my blog that uses a static site generator?
- crazygringo 11mo ago
  Yes, it would be part of the static site generator.
  - Fileformat 11mo ago
    Huh? How would a static site generator serve both RSS and the HTML view of the RSS from the same file? To be extra clear: I want to have <a href="feed.xml">My RSS Feed</a> link on my blog so everyone can find my feed. I also want users who don't know about RSS to see something other than a wall of plain-text XML.
    - crazygringo 11mo ago
      You don't serve them from the same file. You serve them from separate files. As I mention in my other comment to you, I don't know why you want an RSS file to be viewable. That's not an expected behavior. RSS is for aggregators to consume, not for viewing.
      - cxr 11mo ago
        You are being obnoxiously and unreasonably dismissive. Just because you declared they're wrong or that something is a certain way doesn't make it so. > I don't know why you want an RSS file to be viewable. Well, spend two seconds thinking about it. Or just, like, read what they wrote.
    - FateOfNations 11mo ago
      Technically, the web server can do content negotiation based on Accept headers with static files. But… In theory, you shouldn't need a direct link to the RSS feed on your web page. Most feed readers support a link-alternate in the HTML header: <link rel="alternate" type="application/rss+xml" title="Blog Posts" href="/feed.xml"> Someone who wants to subscribe can just drop example.com/blog in to the feed reader and it will do the right thing. The "RSS Feed" interactive link then could go to a HTML web page with instructions for subscribing and/or a preview.

gucci-on-fleek 11mo ago

> Cant you just do the xslt transformation server-side? For my Atom feed, sure. I'm already special-casing browsers for my Atom feed [0], so it wouldn't really be too difficult to modify that to just return HTML instead. And as others mentioned, you can style RSS/Atom directly with CSS [1]. For my Stardew Valley Item Finder web app, no. I specifically designed that web app to work offline (as an installable PWA), so anything server-side won't work. I'll probably end up adding the JS/wasm polyfill [2] to that when Chrome finally removes support, but the web app previously had zero dependencies, so I'm a little bit annoyed that I'll have to add a 2MB dependency. [0]: https://github.com/gucci-on-fleek/maxchernoff.ca/blob/8d3538b4/web/caddy/etc/base.caddyfile#L229-L236 https://github.com/gucci-on-fleek/maxchernoff.ca/blob/8d3538... [1]: https://news.ycombinator.com/item?id=45874305 https://news.ycombinator.com/item?id=45874305 [2]: https://github.com/mfreed7/xslt_polyfill https://github.com/mfreed7/xslt_polyfill

mmis1000 11mo ago

That is actually mozilla's stand in the linked issue except it's on client though. They would rather replace it with some non native replacement (So there is no surprising security issue anymore) if remove directly is impractical. There is actually a example of such situation. Mozilla removed adobe pdf plugin support a long time ago and replaced it with pdf.js. It's still a slight performance regression for very giant pdf. But it is enough for most use case. But the bottom line is "it's actually worth to do it because people are using it". They won't actively support a feature that little people use because they don't have the people to support it.

wombatpm 11mo ago
> They won't actively support a feature that little people use because they don't have the people to support it. Companies always cut too deep. If only they were making enough money to properly support Chrome. /sarcasm

Fileformat 11mo ago

On my blog that uses a static site generator?

crazygringo 11mo ago
Yes, it would be part of the static site generator.
- Fileformat 11mo ago
  Huh? How would a static site generator serve both RSS and the HTML view of the RSS from the same file? To be extra clear: I want to have <a href="feed.xml">My RSS Feed</a> link on my blog so everyone can find my feed. I also want users who don't know about RSS to see something other than a wall of plain-text XML.
  - crazygringo 11mo ago
    You don't serve them from the same file. You serve them from separate files. As I mention in my other comment to you, I don't know why you want an RSS file to be viewable. That's not an expected behavior. RSS is for aggregators to consume, not for viewing.
    - cxr 11mo ago
      You are being obnoxiously and unreasonably dismissive. Just because you declared they're wrong or that something is a certain way doesn't make it so. > I don't know why you want an RSS file to be viewable. Well, spend two seconds thinking about it. Or just, like, read what they wrote.
  - FateOfNations 11mo ago
    Technically, the web server can do content negotiation based on Accept headers with static files. But… In theory, you shouldn't need a direct link to the RSS feed on your web page. Most feed readers support a link-alternate in the HTML header: <link rel="alternate" type="application/rss+xml" title="Blog Posts" href="/feed.xml"> Someone who wants to subscribe can just drop example.com/blog in to the feed reader and it will do the right thing. The "RSS Feed" interactive link then could go to a HTML web page with instructions for subscribing and/or a preview.