ian at hixie.ch
Mon Nov 5 09:33:26 PST 2007
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
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
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
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
> > > 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. `._.-(,_..'--(,_..'`-.;.'
More information about the whatwg