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.
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-entryin 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.