Skip to content
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

URLs with fragments should only have the node identified by the fragment and its descendents parsed #46

Closed
dshanske opened this issue Jul 24, 2019 · 3 comments

Comments

@dshanske
Copy link
Member

http://microformats.org/wiki/hcard-parsing#URL_handling

This is already proposed in an h-card context.

This would allow multiple h-feeds on a page to be accessed. Also, multiple h-entrys on the same page to be uniquely identified, if you are publishing an h-feed where each h-entry permalink is identified by a fragment on the same page.

@sknebel
Copy link
Member

sknebel commented Jul 24, 2019

This would allow multiple h-feeds on a page to be accessed.

That also was something you provided as an example for #44 - has your thinking on this changed/why have a different way of getting at this information?

@Zegnat
Copy link
Member

Zegnat commented Jul 24, 2019

I think there are a number of questions that needs to be answered before having a go at implementing this as part of the spec:

  1. What effect does this have on algorithms that were developed based on the idea that the consumer has the parsed the entire document?

    An example is the authorship algorithm, which in steps 4 and 7.4 wants to look at other objects in the same document for data. If the mf2 parser only returns the h-entry object that was linked to, a consumer will not be able to follow those steps without reparsing the document in its entirety again.

  2. What does this mean for rel-value parsing?

    Will we continue to parse all the links found in the document, thus still be parsing the entire document? Or will we limit all parsing to only the chosen node and its descendants? (I do not know if the answer to this depends on the scope of the rel value or not, probably not as we have never done that.)

    Choosing not to parse everything will run into similar problems as seen in Q1: step 6.1 of th authorship algorithm uses rel="author", which may not be found if the link that has this is not included as a descendant of a linked to h-entry node.

(Full disclosure: I posted this earlier, but from the wrong GitHub account, meaning notifications went wrong and I am reposting.)

@dshanske
Copy link
Member Author

As the original individual who opened this issue, the arguments made today at the Microformats session convinced me that #44 addresses this issue and as long as the id is available, this should not be part of the parsing specification. It may be something that should be implemented as an option by parsers on an individual basis.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants