@dshanske why not just use p-name when u-uid is not available? In the example given, using p-name would give you "Recent Articles" which seems like a pretty good identifier for the h-feed.

Mostly because a URL like the one in the example, makes it easy to share feeds with others.

microformats/microformats2-parsing#44

ok if sharing feed urls is the goal here, then sure #id is the most recognizable format. The downside is that all parsers and content need to change to support it. Even with those changes, this is still a new convention that needs to be supported by readers looking for multiple h-feeds on a page.

Here's another new convention that would also work, and not require any changes: http://tantek.com?name=Recent+Articles for the p-name case, or similarly ?uid= if you've discovered u-uid on the h-feed. If there's other query parameters on the url, the h-feed identifier just goes on the end.

I am fine with continuing the discussion, we just in my opinion, need something we can collectively adopt

Are there any examples of this other than Tantek's website?

I haven't see any others @aaronpk, but I don't mind supporting it if the solution is simple enough. Another idea is to borrow from https://indieweb.org/fragmention and basically stick to your original url @dshanske, but use the fragment to match the h-feed. Without the mf2 type in the query you would just need to check it against both p-name and u-uid which I think would be ok.

I'm leaning in favor of @sknebel's proposal in microformats/microformats2-parsing#44, adding a new id attribute to the parsed microformat object. It gives flexibility to consumers how they want to use the id for a feed element.

@mblaney I think those query params would still require updates for readers to understand the special meaning of them. They also are more likely to conflict with existing, non-microformat-related query params.

@gRegorLove yes both methods require readers understand a new convention for multiple h-feeds in the same file. I agree that fragments are better than parameters, but I don't see a good reason for including ids in parser output. This is probably a separate issue but if you only want the mf2 identified by the fragment you can use parseFromId.

actually, going back to the start of this thread if you pass the original url to parseFomId you get the h-feed you wanted. So the solution is to check if there's a fragment on the url first and try parsing from that point only. If you don't get a result you can try looking for p-name or u-uid on each h-feed in the page that matches the given fragment.

So the solution is to check if there's a fragment on the url first and try parsing from that point only.

It is very easy to lose context when doing things that way because you lose the rest of the document’s data. Case: use XRay to parse this fragment-URL identified post. It will fail to apply step 4 of the authorship algorithm because it didn’t parse the entire document and therefore misses out on the parent object’s author.

A double parse where you both parse the entire document and only the fragment identified section is a little fragile. The smaller object still needs something that uniquely identifies it if you want to find its location in the bigger tree. So either an ID or uid property.

Making the HTML ids a unique identifier for mf2 objects, in addition to already being a unique identifier for the HTML element, solves that problem. A fragment URL will point to the same data within the HTML and mf2 documents. If we treat the fragment URL for HTML as portable, that same property is automatically inherited by the mf2 document too.

yes you're right @Zegnat, I was implementing this today and hit that exact problem trying to use parseFromId :-)

Back on multiple h-feeds on a page, if you're going to do discovery and you find an h-feed without an id, you're still going to need to differentiate the feeds somehow. I'm just suggesting that the fragment identifier can be matched against mf2 properties as well.

speaking of double parsing, there's plenty of times when I'm calling parse and just wanting items. Does anyone think it's worth having a few more flags such as enableAlternates to avoid the extra calls done here? (If yes then probably should continue this discussion in a new issue.)

Implemented in #207