[uf-new] Re: Comment Questions

[Toby A Inkster]

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:mail at tobyinkster.co.uk>
<http://tobyinkster.co.uk>