A reply context> 是显示reply贴子回复的内容，包括链接到原始贴子并带有in-reply-to 标记，显示作者姓名，图标，摘要/省略内容和日期时间等原始帖子的一些发布内容。
当回复开始拥有自己的顶级永久链接时，回复上下文变得更加重要，这个已经在 Twitter 中被广泛使用，将 @-replies 当作其它的推文。 Twitter通过显示 @-reply 的直接reply-context回复的内容，但最后开始在线程中递归显示reply-contexts。.
为什么显示回复上下文?
象吃货jeremycherfas 说的, “一个回复没有上下文就象蛋汤没放盐。” 回复下下文提供：
如果你在你的 主页流上显示回复 (e.g. 例如在 composite_stream中), ，或者甚至在他们自己的页面或存档页面上显示一个列表，你应该在回复中至少显示一个最小的回复上下文, 基于以下原因(例如，至少用u-in-reply-to 内嵌链接到 in-reply-to URL) :
Why not more reply-context?
How should reply contexts be displayed?
For general guidance on primarily textual reply-context presentation best practices, see
How to reply to a photo, see this real world photo reply-context example:
And brainstorming:
回复上下文应该怎样标记?
For consistency with comment markup, reply contexts should be marked up as an embedded h-cite in a .u-in-reply-to so that it’s a nested microformat property of the parent (example). Like this:
<div class="h-entry"> <div class="u-in-reply-to h-cite"> <p class="p-author h-card">Emily Smith</p> <p class="p-content">Blah blah blah blah</p> <a class="u-url" href="permalink"><time class="dt-published">YYYY-MM-DD</time></a> <p>Accessed on: <time class="dt-accessed">YYYY-MM-DD</time></p> </div> <p class="p-author h-card">James Bloggs</p> <p class="e-content">Ha ha ha too right emily</p> </div>
Why mark up reply contexts?
Why use h-cite instead of h-entry for reply contexts?
Why not use h-entry in addition?
There is a broad spectrum of reply-context presentation that can be roughly ordered in terms of fidelity and difficulty, from simplest/easiest to richest (silo-parity) and most challenging.
Since a reply has to be in-reply-to to <em>something</em> (a URL), the simplest reply context is to simply show the URL (hyperlinked of course) of the original with perhaps a text label like: <blockquote>In reply to: hyperlinked-URL-of-original</blockquote> IndieWeb Examples of URL-only :
The next easiest thing to add is the icon (or avatar) of the author of the original post.
For example, replies to tweets can retrieve the icon purely by inspecting the URL for the first path segment for the Twitter username, and then embedding a dynamic image redirect URL, e.g. https://twitter.com/benwerd/profile_image: https://twitter.com/benwerd/profile_image?x=.jpg See Twitter: Profile Image URLs for details.
Replies to indieweb posts can retrieve the icon from a nicknames-cache.
IndieWeb Examples of icon plus URL:
Next, you can sometimes determine the author's name from a nicknames-cache.
Determining the author's name and their icon (more broadly/reliably than above), requires implementing the authorship algorithm on the original post, which requires more work than just parsing it for its h-entry as above.
IndieWeb Examples of icon URL dt-published and author name:
The original's published date is the next interesting (and slightly harder) thing to retrieve and display in a reply-context. With this step, an implementation must retrieve the original post and determine its “dt-published” (e.g. from parsing its h-entry).
The date and time of the original should be displayed and hyperlinked to the original's URL.
IndieWeb Examples of icon URL and dt-published:
Lastly, the <em>content</em> of an original post is the hardest thing to display <em>well</em> in a <em>singular</em> reply-context, due to numerous additional variables. Some challenges:
IndieWeb Examples of icon URL dt-published author name and original content:
recursive reply-contexts (previously called: reply thread and history thread)
Popular silos (e.g. Twitter) recursively display reply-contexts of originals/replies from the tweet that you're replying to, and if it was a reply itself, what it replies to etc. on up through the original tweet at the start of the thread.
IndieWeb Examples of icon URL dt-published author name original content for reply-contexts up through the original post that started the thread:
Sites should send notifications using webmention for every h-cite / URL (u-url) in reply-contexts of posts.
reply-context-examples In order of deployment:
Reply contexts where the original is on a silo may sometimes need or deserve special treatment.
If you reply to a silo post where the silo does not mark up their HTML pages with h-entry, (e.g. post a comment on your own site, and the POSSE it to an Instagram post), you will need to do further processing in order to display the reply context as high fidelity as other indieweb posts.
You may find the following tools useful:
t: Some ideas for improvements over: “in reply to: (URL)”. (some from improve_reply-context_support)
For multi-reply context, space separate the generated @/domain/URL and link 2nd and later to respective in-reply-to URLs.
Possibly worth a small CASSIS function, takes in-reply-to array, returns display HTML.
Note that the above brainstormed reply contexts are actually two separate things - the “In reply to” pre-text which is specific to a reply-context (e.g. RSVPs would be different), and the synthesized summary of the url e.g. “a comment …” or “issue n of Github project xyz”.
The latter can be used in a number of different contexts for providing a more human text-friendly synthetic summary of a URL if you have no other information (i.e. a URL-only h-cite, and no retrieval of the URL itself for link-preview properties).
Thus it’s probably better to make two CASSIS functions, one for the reply_to_text and one for an auto_url_summary.
Though one advantage of storing and showing a reply-context is freezing the original context of what you're replying to, it may make sense to accept some updates.
For this to work, an original post that accepts and displays comments should send webmentions to all the comments permalinks when the original post is updated or deleted.
Examples:
Even though possible, it may be inefficient to send individual webmentsions from an original post to all the responses of that post.
With each nth response (reply, like, etc.), the source then has to send n-1 webmentions to all the previous responses.
It results in a geometrically growing responsibility of sending webmentions.
There may be other notification mechanisms that should be explored such as PuSH, e.g. if a response wants updates on that post in particular, perhaps it could do PuSH discover on the post, and then explicitly subscribe to receive PuSH updates on that post. (suggestion from aaronpk)
This applies to event posts as well, and any responses to them, e.g. any changes to the event (name, , location, times, description etc.) should make the event send a webmention to any
So that they can update their respective reply-contexts accordingly.
See event: Response context CRUD for more details on how event posts should send webmentions to enable RSVP/reply-context CRUD.
Fork On Text is an open source project in development to provide reply-contexts as a service, self-described as “Service to upgrade simple reply contexts with full reply contexts by fetching and storing remote content.”
We could write a single reusable JS library that fetches, renders, and injects reply context(s) into the current page. Details: Client side reply contexts with JavaScript.
reply-context-examples#Silo_Examples Some silos display reply-contexts.
