Microformats tinkering

I have a strong like for Microformats.

Designed for humans first and machines second, microformats are a set of simple, open data formats built upon existing and widely adopted standards. http://microformats.org

Which means you write for humans just like you always do, and as well as wrapping HTML around them to aid in reading (adding in semantic things like bold and paragraph, as well as enhancements as linking to other pages and images). Microformats are additional 'flags' that get added to the existing content, which the microformat readers recognise and can pull out meaningful information - for example, adding a p-author class to my author byline means microformat readers know that's a Person-record and can do Person-things with it.

When I started work on my new non-WordPress website, I was starting from scratch with my templates. This made it super easy to bake in the self-descriptive class elements around h-entry, h-event and h-card. My individual posts are h-entry marked up, I'm toying with a new event template that uses h-event, and my homepage has h-card about me. Simples. h-feed, however, is where I'm having concerns.

h-feed is a simple, open format for publishing a stream or feed of h-entry posts, like complete posts on a home page or archive pages, or summaries or other brief lists of posts http://microformats.org/wiki/h-feed

Historically, blogs used RSS or more recently ATOM feeds for publishing a stream of posts (or syndication). Each is an XML file (like HTML, only not for a browser, but still describing the content in a standard way), and we used to have things called RSS Readers that could aggregate lots of feeds into one place, for ease of following lots of people/ companies/ newspapers in one place.¹

With my auto-generating website, an RSS or ATOM feed is easy to generate alongside my blog posts; I have an RSS feed that rests in a simple, consumable form next to my pages at https://vonexplaino.com/blog/rss.xml. The feed has a summary of all my posts to 0BC (Blog Creation), and sits at a comfortable 61Kb at the time of writing. Each entry in the feed links to the full article, and has only a summary to drive traffic to my site as well as not burden people with full texts of articles they don't plan on reading after the summary.

To generate an h-feed, I altered my List Page template to have the h-feed specific tags. This results in no additional files, just a bit of padding to the source page. However the source page was created to be an HTML page read by a browser and rendered for a person. So it has some extra bits that the pure RSS feed (serving the single purpose of syndication) does not. Also, the HTML list page doesn't list all my pages, it's paginated to cater for low bandwidth/ people who don't like parsing a long page and prefer things chunked. In that cut-down format it's at 19Kb, so less than my RSS feed - but it's also serving less than my RSS feed. If I cut my RSS feed down to the 10 posts the h-feed list page shows, it drops to 6 Kb. So the HTML page is certainly larger per content.

On the flip side, RSS/ ATOM feeds feel like a brick. It's one, long list, and you can like it or lump it.

So here are my initial thoughts on h-feed and where it could/ should go.

UPDATE: Talking on the IndieWebCamp slack channel, I got some immediate replies. Tagged as UPD1

• Next/ Previous links. RSS/ ATOM feeds are stuck with the all or nothing. If your RSS feed only returns the last 10 articles, that's all you're getting. Or if it returns everything since the dawn of time, be ready for increasingly larger downloads every time. If a h-feed understood pagination, and included next/ previous links like a lot of *Graph APIs do, it could lend itself to smaller and more directed payloads.
  • UPD1: Since the h-feed is over HTML, it can use the HTML rel tags of rel=prev ; rel=next. Nice!
• HTML Only. h-feed are only applicable to HTML, but the standard 'payload' should be expandable to a more generic feed structure. Should that be separated out as a generic 'thing' (same with events, entries and cards), with h-* the HTML attribute/ class implementation? Nothing stopping others from doing it otherways (LaTeX maybe? RTF? Heck, even Word docs are now XML files in Zips)
• Tumblr replacement. h-entrys already have the in-reply-to attribute to help with commenting/ discussion streams. Should the h-feed include that specifically so that h-feeds can be read/ parsed/ incorporated into a tumble-blog style approach? Could this allow for h-feeds with full entries in them, complete with specific comment capacity, so threads etc. can be visualised?
  • UPD1: I've had it clarified how replies work:
    1. I subscribe to a feed.
    2. I read my collection of feeds, aggregated by my feed reader.
    3. I read a post that I like and want to reply/ like.
    4. I reply/ like on my site, with a in-reply-to reference to the original post as referenced in the feed
    5. A webmention is sent to the site hosting the post I liked/ replied to, so they can store the interaction in comments or other sections.
    6. That gets inside my feed others can subscribe to.
• Social Web. The above could be me just having incomplete thoughts; but one of the major draws that Tumblr/ Twitter/ Facebook had over the Blogging web was the interaction and ease of seeing everyone you're following in one firehose that was simple to navigate. Indieweb's doing a great job of owning your own content and then sharing as you see fit; but is the game changer how we find a way to independantly replicate the Stream Of Articles that Tumblr/ Twitter/ Facebook have captured? That and the ease of interaction with them, which is where RSS/ ATOM falls well short.