-
Notifications
You must be signed in to change notification settings - Fork 37
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
Comments
@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. |
ok if sharing feed urls is the goal here, then sure Here's another new convention that would also work, and not require any changes: http://tantek.com?name=Recent+Articles for the |
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 @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. |
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 Making the HTML |
yes you're right @Zegnat, I was implementing this today and hit that exact problem trying to use Back on multiple h-feeds on a page, if you're going to do discovery and you find an h-feed without an |
speaking of double parsing, there's plenty of times when I'm calling |
Implemented in #207 |
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.
The text was updated successfully, but these errors were encountered: