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
Response Type: move "reply" to 2nd to last to enable p-summary fallback use-cases #25
Comments
You'll have to help me understand this a bit better. Are you saying that newer kinds of replies, for example edits, should also include the |
@prtksxna precisely! All (especially newer) responses should include the u-in-reply-to to enable fallback behavior with p-summary with any consuming code that may or may not understand that particular type of response. |
Discussed in https://www.w3.org/wiki/Socialwg/2017-07-25-minutes#Post_Type_Discovery today's Social Web WG telecon, with resolution of accepting editor proposal, and approving new WD with that change. |
Great! Thanks for the logs. |
Resolve issue #25 with proposed change moving in-reply-to / reply recognition to last of explicit response type recognition (right before mention catchall for response type algorithm, and right before non-response types in full post type discovery algorithm). Link issue #s in changes section for easier accessibility.
Changes made in repo and published updated WD: https://www.w3.org/TR/2017/WD-post-type-discovery-20170801/ |
Based on implementer feedback from @aaronpk and @sebsel, it may make more sense to move the "reply" recognition step to 2nd to last in the Response Type Algorithm, that is, right before the "else it is a mention".
Specifically, anyone posting a "like", "repost", "RSVP", (or any other new response type!) has incentive to provide u-in-reply-to fallback plain text equivalent perhaps in p-summary that expresses the reaction/response as prose, e.g.:
This way even if the receiving site only supports receiving Webmention replies/comments, something sensible will still show up, and provide a good experience to the author of the response, the author of the post, and any readers of the post.
If we formalize this kind of fallback markup as a publishing guideline (perhaps a feature request for https://github.com/microformats/h-entry) it also provides a nice path forward for expanding response types over time that provide meaningful behavior even to existing systems without explicit support for the new response types.
The text was updated successfully, but these errors were encountered: