On Thursday, January 27, 2005, at 01:26 AM, Henri Sivonen wrote:
I'd prefer an element, because the nature of the favicon reference is not that a user would want to manually follow the link. That is:While I agree with this sentiment, the working group has rejected attempts to add language to the spec to limit the use of <link>, so I assume we do not have consensus on the desire to limit it's usage. So that's not necessarily a very strong argument for creating new elements (not that there aren't other arguments for it).
<icon src='...'> or <icon href='...'>
Of the two options you listed, I'd prefer @src to @href...for reasons related to my agreement with the sentiment about the use of <link> here. "src" is much more description of how the attribute's value is going to be used.
Which brings me to PaceIconAndImage--the pace itself makes forbids putting one of the attributes of Link Constructs in the elements (@rel). Another of them (@href) is not accurately descriptive of what it would be used for. Another of them (@title) doesn't seem very useful for icon (unless for accessibility--do people more involved in accessibility issues think that's needed--that it's going to be used to say anything more than "xyz.com's icon"?) Is it really appropriate to call this a Link Construct?
Also, why limit this to feed/head, and not entry? So that Atom feeds will be easily convertible to RSS 2.0? Certainly there are ways to add images to entries in RSS 2.0, though not icons (as far as I'm aware), but I don't think that's a big deal. Because link/@rel="enclosure|attachment" can be used for images at the entry level? Then why not do the same at the feed level? Because we don't have prior art for needing it at the entry level? True for icons, less true for images, but still probably the strongest argument. But I would still argue for allowing them in entries.
