1. 9

If I want to add an RSS feed to my blog, I need to create a separate page with XML listing of the posts for feed aggregators. At the same time, I already have a page which lists posts for humans, in HTML

It dawned on me that there seems to be some genuine duplication here? Is there some alternative standard which would allow me to use some sort of semantic html for my list-of-posts, to provide the RSS feature of notifying subscribers about new content?

  1. 26

    You could do it the other way around and style your Atom feed with an XSLT stylesheet to make it look better to humans.

    1. 7

      https://feed.tedium.co/ does that, for example.

      1. 1

        At some point after I left, they stylized the feed at The Atlantic: https://www.theatlantic.com/feed/all/

        1. 1

          tedium is so wholesome. Just subscribed!

          1. 1

            https://len.falken.directory has been doing this for awhile

          2. 2

            A post about doing just that: https://andrewstiefel.com/style-atom-xsl/. There are also some links to other similar posts at the bottom.

            1. 1

              my personal atom microblogging engine in use at https://mro.name/microblog

            2. 24

              Former newsreader dev here. The duplication is valuable, actually.

              • The feed can list more posts than you choose to show on your blog home page. Putting more posts in a feed is good because it reduces the chance that an infrequent poller will miss posts.
              • The feed is probably a lot smaller than the home page HTML because it just contains the essentials. This reduces bandwidth. This may not be so true of a simple blog, but more complex sites usually seem to have a huge spew of metadata and other stuff in the HEAD. And with any site, the feed will be tiny if you omit the full text of the posts.
              • The feed can be served statically even if the HTML is dynamic. That saves resources and keeps a popular feed from overloading your server (remember that clients are fetching your feed hourly or more often.)
              • The feed’s Etag and Last-Modified only need to change when a new post is added (or edited), not every time there’s a new comment or some unrelated-to-posts change to the home page. This saves a lot of bandwidth (and CPU time on the client.)
              1. 11

                There’s http://microformats.org/wiki/h-feed but I doubt many feed readers support this.

                1. 4

                  If not so, you can pipe it through something like https://granary.io/ so you don’t have to generate that feed.

                2. 7

                  It’s not an issue worth solving.

                  Your list of posts is most likely auto-generated somehow, and whatever blog system you use, should have no problem generating it again in RSS. It’s just a static file.

                  Parsing a new HTML-formatted feed makes clients more complex. It’s enough hassle for clients to deal with multiple RSS versions and Atom.

                  The feed may have different content than the webpage. For example, it’s nice to include posts’ bodies, but you may not want to show full posts one after another on your webpage. If you include everything, it will bloat one or the other use.

                  1. 1

                    Agree on not worth solving because standards practically, but theoretically, including HTML into XML via CDATA is yuck. I’d be more happy with a dedicated /feed.html to tweak the content instead of pulling a different technology to describe the same info.

                    1. 1

                      Atom fixed the yuck thing. You can use the XHTML namespace in XML.

                  2. 5

                    There is stuff like https://indieweb.org/hAtom but don’t know about client support.

                    1. 3

                      Don’t like XML? Try JSONfeed.

                      I’m trying to understand your workflow here. Are you writing HTML by hand? If so, h-feed or manually writing Atom and restyling it is the way to go. If you’re generating HTML from another source like Markdown or Asciidoc, what’s the problem with letting a generator parse the data one or more extra times?

                      As a data point, I have a blog with 4.1M of MD content that generates HTML, Atom and JSONfeed in around 4s, using Perl. I implemented Atom support using a Perl module, ensured it validated, and haven’t had to touch it since.

                      1. 3

                        what’s the problem with letting a generator parse the data one or more extra times?

                        Yeah, that’s what I do. It works in practice (the best kind of “works”), but I don’t like that conceptually I need to supply two presentations of the same content, where one presentation (html) should be general enough.

                        I think h-feed is what I am looking for actually. Doesn’t seem to be alive enough though :-(

                        1. 3

                          You think one size should fit all, which is another way of saying that you want to restrict the “one size” to what which fits all.

                          Any restrictions would affect what you deliver to everyone.

                          1. 1

                            Exactly: as a publisher, I want to deliver my content in a single, semantically rich format, and make it consumer’s problem to transform that to whichever form they want.

                            1. 1

                              So you send all times as seconds since 1970 and use a blob of javascript to create a more human-readable format for humans, with the appropriate format, level of accuracy and perhaps timezone conversion.

                              Or maybe you send all dates/times in two formats in the same payload, because I’ve heard that some search engines and even web browsers don’t evaluate javascript. Or maybe you just choose to ignore that part of the audience and optimise for having a single, semantically rich format, and sending data twice isn’t exactly “a single format”.

                          2. 1

                            Most of the h-whatever indieweb stuff is a bit stale.

                            I looked at some of it last year when I was revamping my online presence but it’s basically a bunch of proposals and semi-RFCs, nothing really finished.

                        2. 2

                          Use hatom or h-atom and probably offer a link through one of the many translators like granary for those who only support regular Atom.

                          1. 2

                            At least for one of my blogs, there’s no duplication: the feed orders by modification date, while the main page of the blog orders by creation date. Thus feed subscribers get to see changes as they happen unlike those who just visit the homepage.

                            Feeds and homepages serve different purposes.

                            1. 1

                              Did something somewhat similar for a side project recently. Doesn’t work best for mobile browsers etc (tries to run as direct XML feed)


                              1. 2

                                Works fine on my phone (Bromite (a Chromium fork) on Android)