[uf-discuss] solidifying multiple hatom feed behavior

Wed Jul 26 07:08:40 PDT 2006

On Jul 26, 2006, at 9:47 AM, Scott Reynen wrote:

> On Jul 26, 2006, at 7:59 AM, Chris Casciano wrote:
>
>> I can think of two offhand...
>>
>> - first is an example feed when talking about mfs... which i admit  
>> coud be rare
>> - something like my versionhistory mini-feeds[1][2], though I've  
>> used them on non-blog pages, might be a more common scenario for  
>> those that keep similar content in blog posts[3] or forum posts [4]
>
> I can think of a few more, but Is there any reason all of these  
> couldn't simply add class="hfeed" to the body feed when it becomes  
> obvious that it is or will be needed?  I don't yet see where the  
> current hatom spec is insufficient in addressing this issue.   
> Multiple feeds on the same page need to be explicitly marked with  
> class="hfeed".  Isn't that solid enough?
>
> Peace,
> Scott

the author has to be the same person who controls the template in  
these cases.. clearly in the forum case I'm not.. in the blog case  
'it depends'

it also poses a risk of some other person not associated with the  
site who can just inject a random <span class="hfeed"> into some  
comment area or forum post or bug report thread or basecamp content  
area and blow things up for the author and because its /anywhere/ in  
the document it blows the feed relying on the document root semantics

but really.. I'm ok with the behavior.. myself I'll probably never  
author another hatom feed relying on this case.. . I'm just concerned:

(1) that we really know what the parsing rules are saying so tool  
developers can take a first stab at building in multiple feed parsing.

(2) there aren't any big holes in the usage cases for feeds and we're  
not creating a string of allowed cases that will cause headaches for  
authors and subscribers alike in the long term

Even in the case of <body class="hfeed" id="mainfeed"> i worry about  
the behavior over time of subscribing to page.html vs.  
page.html#mainfeed

-- 
[ Chris Casciano ]
[ chris at placenamehere.com ] [ http://placenamehere.com ]