[uf-discuss] solidifying multiple hatom feed behavior

[Ryan King]

On Jul 24, 2006, at 6:38 AM, Chris Casciano wrote:

> ...
>
> I've added to the hatom issues page draft rules for multiple feeds  
> -- they don't necessarily alter the 0.1 behaviors, or add any new  
> "requirements" to the spec but outline the expected behavior in the  
> various scenarios.
>
> http://microformats.org/wiki/hatom- 
> issues#Draft_Rules_for_multiple_feeds


> Issue: what is the result of trying to address a feed at a non- 
> existing fragment identifier? Same as no fragment id specified, or  
> a not found error?

I think we should do what browsers do - just ignore it and work on  
the entire page.

> Issue: for authors, is there any way we can control a redirect for  
> a feed addressed via fragment id?

With HTTP, no. With javascript, yes. Of course javascript won't  
always work for non-visual user agents.

> Issue: is the reliance on class + id too strict? we may be losing  
> other non-ambiguous constructs for sake of simplicity (e.g. roots  
> are [1]body [2] hfeed w/id or [1] body w/ id [2] hfeed w/id)

I'm not quite sure what you're asking here. Can you expound a bit?

thanks,
-ryan