Sarven Capadisli wrote:
Here is my understanding of rel="in-reply-to" and why that alone is
sufficient to indicate that an hentry is a response to another hentry
(anywhere). Commonly:
* chronological comments (e.g., Wordpress)
* threaded comments (e.g., Slashdot)
* a blog entry as a reaction to another blog entry (e.g., Technorati)
Advantages:
* Creates a single instance of a comment [1]
* Minimal set of requirements
* Applicable to various forms of replies
Disadvantages:
* @id required
I agree that it is a very simple and flexible solution, but you're
leaving out what most people think is the biggest disadvantage: it
requires an <a> link from the comment to its parent, which is not
very common in the wild. (Yes, there are examples out there, but
they're the exception rather than the rule.)
Of course, these links could be hidden via CSS. The normal arguments
about hidden data becoming out of date are less applicable here, as
virtually all comment systems are driven by databases and CMSes. But
requiring a link which is going to be hidden by most people seems a
bit of an icky route to go down.
That's why I propose we adopt this *and* class="replies hfeed". The
advantages and disadvantages of each complement each other, like two
pieces of a jigsaw puzzle. Authors could choose whichever most
closely matched their publishing patterns, or choose to use bits of
both.
It seems like two patterns will make it more difficult for parsers,
but they don't need to conflict if you specify that rel=in-reply-to
wins over class="replies hfeed", and what I've found is that once
Sarven's proposal is implemented, class="replies hfeed" is very easy
to add on. About 16 lines of code in my case. (And eight of those
lines contain just a single bracket - my coding style is very
generous with line breaks.)
--
Toby A Inkster
<mailto:[EMAIL PROTECTED]>
<http://tobyinkster.co.uk>
_______________________________________________
microformats-new mailing list
[email protected]
http://microformats.org/mailman/listinfo/microformats-new
