[whatwg] PaceEntryMediatype

[Ian Hickson]

On Thu, 7 Dec 2006, Martin Atkins wrote:
> > 
> > <h1>Feeds for this site</h1>
> > <ul>
> >    <li><a href="status.xml" type="application/atom+xml">Status feed</a></li>
> >    <li><a href="news.xml" type="application/atom+xml">News feed</a></li>
> >    <li><a href="links.xml" type="application/atom+xml">Links feed</a></li>
> > </ul>
> 
> This makes a lot more sense to me. When that orange button lights on up 
> on my browser's toolbar, I tend to think of it as "subscribe to this 
> page", not "subscribe to some random thing that happens to be on this 
> site somewhere and may or may not have anything to do with this page."
> 
> rel="feed" the way Ian has defined it sounds more like type="feed" to 
> me. (ignoring of course the fact that the type attribute actually takes 
> a MIME type.)

Yes, indeed. The primary difference is that type="" is specific to 
individual MIME types, whereas rel="" is a generic way of saying what the 
remote document is and how to process it (at least, that's what 
"relationship" in this context has come to mean).


> I think it's much more likely in the above scenario that those links in 
> Alexey's example would be links to HTML documents containing the items 
> from the feed, and *on there* would be the feed auto-discovery stuff. 
> That's how I'd author it, anyway. (and also, by extension, how I'd 
> expect other sites to author it.)

That's an option, yes; but I don't think we should restrict authors to 
those techniques.


On Fri, 8 Dec 2006, Alexey Feldgendler wrote:
> > 
> > This is not how <link> is defined in HTML5.
> 
> 3.8.4: "The link element allows authors to indicate explicit 
> relationships between their document and other resources."
> 
> What kind of explicit relationship do we have here?

Hm, good point. Fixed.


> > Then the browser wouldn't take these links and make them available in 
> > a "list of feeds" interface, which is the problem we are trying to 
> > solve.
> 
> Current browsers easily make lists of all links found on the page by 
> enumerating all <a> elements. I can't see why a list of feeds cannot be 
> a subset of that. The type attribute gives enough information for this, 
> especially if combined with the proposed ";type=feed".

But we don't want to restrict the types of feeds to just the currently 
supported MIME types. Whether something is a feed or not is independent of 
it's type.


On Sat, 9 Dec 2006, Alexey Feldgendler wrote:
> > 
> > Well they sort of have a relation -- they're feeds that the author 
> > thinks the user would find useful.
> 
> This is no more tight a relation than "a page that the author thinks the 
> user would find useful", which is usually expressed with <a> rather than 
> <link>.

Indeed. But I don't see that as a problem.


> > This is something that happens already in the real world -- I'm just 
> > trying to make the spec distinguish "alternate" from "feed" when it 
> > comes to such feeds.
> 
> Whoever is doing it abuses <link>.

Only if we say it is abuse, which I don't think we should. What do we gain 
by classifying this as abuse?


> rel="feed" means "the feed for the current document", rel="alternate" 
> means "an alternate representation of the current document". Therefore, 
> rel="alternate feed" means "alternate representation of the current 
> document by a feed".

Actually the spec defines this in detail, and it doesn't quite match your 
definition.


> > > Currently the orange RSS icon means "Subscribe to this page". This 
> > > is a lot more useful (in my opinion) than it meaning "subscribe to 
> > > some random thing".
> 
> > No, it doesn't. It means "subscribe to something the author made 
> > available". Currently you have no way to know if it is the current 
> > page's feed or just a list of random related feeds.
> 
> Surely the author could have referenced any irrelevant feed but that's 
> not a good thing to do. Conscious authors should only use rel="feed" as 
> defined in the spec.

I agree, but the spec doesn't say what you want it to, and I'm not 
convinced that it should or that authors want it to.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'