New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add optional ID for h-* elements #206

Open
dshanske opened this Issue Nov 18, 2018 · 13 comments

Comments

Projects
None yet
5 participants
@dshanske
Copy link

dshanske commented Nov 18, 2018

This came out of trying to uniquely identify elements on tantek.com, where there are multiple h-feeds in a page. I'm not sure how to uniquely refer to any of them. The suggestion is that an id property can be generated by taking the HTML id of the element that the h-* is on. It can be uniquely addressed by adding that as a fragment to the URL. For example, in the case of tantek.com, http://tantek.com#recent_articles should be his recent articles h-feed.

@mblaney

This comment has been minimized.

Copy link

mblaney commented Nov 18, 2018

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

@dshanske

This comment has been minimized.

Copy link

dshanske commented Nov 18, 2018

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

@dshanske dshanske changed the title Add experimental implied UID for h-* elements Add optional ID for h-* elements Nov 18, 2018

@dshanske

This comment has been minimized.

Copy link

dshanske commented Nov 18, 2018

@mblaney

This comment has been minimized.

Copy link

mblaney commented Nov 19, 2018

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.

@dshanske

This comment has been minimized.

Copy link

dshanske commented Nov 19, 2018

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

@aaronpk

This comment has been minimized.

Copy link
Member

aaronpk commented Nov 19, 2018

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

@mblaney

This comment has been minimized.

Copy link

mblaney commented Nov 19, 2018

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.

@gRegorLove

This comment has been minimized.

Copy link
Member

gRegorLove commented Nov 19, 2018

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.

@mblaney

This comment has been minimized.

Copy link

mblaney commented Nov 19, 2018

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

@mblaney

This comment has been minimized.

Copy link

mblaney commented Nov 19, 2018

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.

@Zegnat

This comment has been minimized.

Copy link
Member

Zegnat commented Nov 19, 2018

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.

@mblaney

This comment has been minimized.

Copy link

mblaney commented Nov 19, 2018

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.

@mblaney

This comment has been minimized.

Copy link

mblaney commented Nov 21, 2018

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

@gRegorLove gRegorLove added this to the 0.4.7 milestone Nov 21, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment