aboutfeeds
aboutfeeds copied to clipboard
genmon
Feature: Page to help site owners to promote their feed
Problem: Web feeds are hard to discover for users (whether the site has a feed and, if it does, where that feed is).
This page should include a list of ideas would help when attracting users who don't yet have a newsreader installed.
Candidate ideas...
- Link (should it use
feed:or not?) - Link text copy
- Standard icons: see http://www.feedicons.com
- Help copy (linking to AboutFeeds.com)
- Implementing RSS/Atom/JSON Feed -- which to choose and validators
- Feed auto discovery
- Using XSLT to make an attractive, semi-formatted RSS feed which includes a "What is this? How to subscribe" link at the top
On formatting RSS feeds:
- Here's a guide to using XSLT to make a prettier RSS feed https://lepture.com/en/2019/rss-style-with-xsl
- About Feeds should create an XSL file for any site owner to download and use
- The feed must still look "technical" -- but maybe there should be a standard header which explains what a feed is, and talks about how to subscribe? Well, links to aboutfeeds.com really...
- I imagine this means giving up on the
feed:protocol, so that the feed appears in the browser. (Is that protocol still recommended anywhere?)
Maybe instead of having an XSLT file site owners could link to AboutFeeds and provide the URL for the feed as a query param so it could be rendered nicely here?
As as experiment, I've styled the RSS feed on my own blog. Here's how it looks:
Some quirks, in no particular order:
- the XSLT file has to be served on the same domain as the XML (RSS/Atom feed). That means it's hard to update, so the first version that we encourage people to use should be the one that's intended to stick around for a few years. In the meantime, it's in beta
- the pretty feed only shows up if the browser's usual "auto-open the installed newsreader" functionality is deactivated. I think this is fine since
- sophisticated newsreader users don't expect a feed to always auto-open the installed reader, and
- this provides a better experience for newer users
- Design: I've opted for a generic "Web Feed Preview" header rather than the feed title as this page mustn't be confused with the usual homepage. So it has to look a bit "technical."
To deactivate the browser's auto-open functionality, these HTTP Response headers must be set:
Content-Type: application/xml; charset=utf-8 # not application/rss+xml
x-content-type-options: nosniff
(Based on this blog post: How to style RSS feed (Just Lepture).]
I really like the simple layout and presentation 👍
Did you test to see if the XSLT file will be applied if its served from a remote domain using appropriate CORS headers? I think that might work? However you then have the downside of having to host and serve that file so you're trading off easy updates with centralisation, although maybe a good CDN could help.
Did you test to see if the XSLT file will be applied if its served from a remote domain using appropriate CORS headers?
From what I've read, there's no way of working around this. It requires a tweak to the security settings, or it's unreliable. A shame!
This is a great idea! I've added your XSLT file to my feeds, which you can get to from here:
The only change I've made—and I'd suggest this in general—is removing the hardcoded img hosted on aboutfeeds.com; that would make that domain a potential single point of failure.
If you think the image is really needed, maybe a data-URL is the way to go?
If you think the image is really needed, maybe a data-URL is the way to go?
I think the logo is important: it builds familiarity with a common symbol, and it distinguishes the feed page from the main website (which might look quite similar).
What do you think of inline SVG?
The original SVG file is linked here.
Here's a little wrinkle that I discovered after trying to get this working on my own site...
The officially correct Content Type for RSS feeds is application/rss+xml. This is the default that Django's syndication feed framework uses, which is what I was struggling with. However, using this Content Type seems to prevent the linked XSLT file from even being loaded, so no styling takes place.
When I changed it to application/xml then the XSLT file was loaded and the feed was styled nicely. Both @genmon's and @adactio's feeds use application/xml, which is why it's working.
This is using Chrome on macOS. Firefox only ever wants to download ~~XML~~ rss+xml files and Safari only ever wants to open them in News.app; no idea if this is standard or something annoying about my instances of these apps.
@philgyford yes, this is tricky. Have a look at the required HTTP headers further up this thread. It looks like x-content-type-options: nosniff is needed. I don't know whether it's possible to embed this directive in the RSS feed itself. It's a hurdle either way.
Feels like it'll be good to get this XSLT to a point where the copy etc all makes sense, and then offer a hosted solution, as described in #22.
@adactio ok, check out my blog feed now! It uses inline SVG. XSLT is here: http://interconnected.org/home/static/styles/pretty-feed-v2.xsl
I've also changed "Recent Posts" -> "Recent Items" because I would like this XSLT to be generic to wherever there is a feed, and so it's better to err on the side of terminology expressed in the underlying protocol.
The inline SVG is working a treat! I've rolled it out on my site now too.
The mime-type issue is a real head-scratcher though. :-(
The mime-type issue is a real head-scratcher though. :-(
Indeed. I was happy to learn from the above discussion that browsers actually support XSLT, so an XML file can be made human-readable in browsers by adding a single line to it, and I’d be eager to use this myself. But if obtaining this behaviour requires setting the Content-Type header to application/xml instead of application/rss+xml, might this result in other software (e.g. browser extensions, web crawlers) failing to detect it as being a feed? Or are there already so many feeds published with the ‘wrong’ mimetype that every such software already performs detection by sniffing the content?
Either way, it seems like a bad practice to misrepresent the content type. I suppose the real solution would be for browsers to interpret rss+xml (or anything+xml) as XML. I found an open issue about this on bugzilla, and one on the Chromium bug tracker. Both are classified as bugs, but with low priority.
Neat idea! I tried to implement my own version here: https://larlet.fr/david/log/ (with my own CSS, trying to keep consistency with the probable entry page).
A screenshot for the posterity:
One thing I was frustrated with though: Firefox does not support disable-output-escaping="yes" which means that the content of the encoded entries displays the HTML without rendering it. You can notice the difference when you open the details/summary of an entry, in case of Firefox you will see the HTML vs. Chrome·ium/Webkit displaying the rendered content.
I guess it would be possible to render the feed itself using another unescaped format (like CDATA) but I need to think about it. If you already bumped into that issue and solve it, do not hesitate to share your fix :)
