Hacker News Reader

Comment by bazoom42 | Hacker News Reader

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.

View on HN

> 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/8d3538...

[1]: https://news.ycombinator.com/item?id=45874305

[2]: https://github.com/mfreed7/xslt_polyfill

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.

> 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

On my blog that uses a static site generator?

Yes, it would be part of the static site generator.

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.

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.

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.

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:

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.

Who said "need"? He said "I want".

You're moving the goalposts.

Apply that argument to any other file format and it quickly become absurd.

Reply on news.ycombinator.com