a post by an authoran author ( )
Thanks to Ruxton for making available the source to the IndieWeb Best Nine, here are my “Best 9 Photos of 2019”. The app walks your pe...

Thanks for your updates Marty, I’ll get them into the app.  I just wanted to touch on one thing you wrote in your post, and that’s:

but I don’t consider e.g. /2019/01/ to be a “feed”,

Because it is a feed.

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.

Your /year /year/month pages are archive pages and these are exactly what h-feeds are for. A feed is a collection of entries and this is a collection of entries. A good use-case for having them as feeds wanting to follow people for a year or month only.

I really don’t see any reason for it not to be a feed and I’d argue for the sake of implementing spec and having tools that ‘just work’, it should be a feed.

 

One thought on “

  1. Thanks for taking a look at the changes! And thanks for the response!

    While I agree that I could wrap the entries on my archive page in an h-feed, I disagree that every collection of h-entry “is a feed”.

    The microformats2 spec for h-feed is still a draft and open to change. Even so, it states that h-feed is “for publishing a stream or feed”. The use cases listed there, and on indieweb.org/h-feed specifically discuss feeds and feed readers subscribing to content.

    I made the specific choice not to make the archive pages into a feed, because I don’t want to encourage folks to subscribe to something only to find that it becomes static over time.

    In my thinking, an microformats2-capable crawler should be capable of handling a collection of h-entry in a page whether or not they are wrapped in an h-feed. There was some brief discussion about it today in the #indieweb-dev chat.

Leave a Reply

Your email address will not be published. Required fields are marked *