deprecate icon and logo elements?

[James Snell]

Ok, this is something that has bugged me for quite a white... the atom:icon
and atom:logo elements are terribly underspecified as just a simple IRI.
Those these really should be link objects. What I'd like to propose is a
deprecation of those elements in favor of <link rel="icon" href="..." /> and
<link rel="image" href="..." />. The icon and image rel attributes would be
added to the registry of link relations...

So instead of..

<feed>
<icon>Loading Image...</icon>
...
</feed>

It would be...

<feed>
<link rel="icon" href="http://.../image.jpg" type="image/jpeg" />
...
</feed>

The nice thing about this approach is that it does not actually require any
changes to the spec. The icon and image rel values would be added to the
registry and implementations would need to be modified to look for them as
an alternative to the icon and logo elements.

Thoughts?

[Antone Roundy]

I've never been a fan of using <link> for connecting to every sort of
external entity, since it makes it impossible to write general purpose
<link> handling code (for unknown @rel values) without ending up doing
things that degrade the user experience. But that battle has already
been lost (when the idea of reserving <link> for links intended for
traversal was rejected).

The question now is, what benefit do we get in exchange for
implementations having to be updated to look for the images in a new
location? If there's no concrete benefit, I'd vote for keeping it as
it is. It'll be simpler for new implementers if they don't have to
discover that something in the spec has been deprecated. And it'll be
simpler for everyone if there are fewer ways to do the same thing.

Antone

[James Snell]

Concrete benefits include being able to specify the media type of the linked
resource, as well as take advantage of other extensions such as the Atom
Link Extensions I've proposed, and Google's convention of using child
elements within atom:link to provide additional metadata such as multiple
alternative representations of an image (e.g. thumbnails, etc). At the very
least, we should be able to specify the media type of the linked image.

Post by Antone Roundy
I've never been a fan of using <link> for connecting to every sort of
external entity, since it makes it impossible to write general purpose
things that degrade the user experience. But that battle has already
been lost (when the idea of reserving <link> for links intended for
traversal was rejected).
The question now is, what benefit do we get in exchange for
implementations having to be updated to look for the images in a new
location? If there's no concrete benefit, I'd vote for keeping it as
it is. It'll be simpler for new implementers if they don't have to
discover that something in the spec has been deprecated. And it'll be
simpler for everyone if there are fewer ways to do the same thing.
Antone

[Aristotle Pagaltzis]

Post by Antone Roundy
I've never been a fan of using <link> for connecting to every
sort of external entity, since it makes it impossible to write
without ending up doing things that degrade the user
experience. But that battle has already been lost (when the
idea of reserving <link> for links intended for traversal was
rejected).

This is parallel to the URN vs URL dispute. You cannot really do
this if links are typed in any generic way, ie. `rel`. Maybe it
would have been worth thinking about an additional mechanism to
designate links of this kind as such. But that assumes the
distinction is tenable in the first place.

Regards,

[Peter Keane]

+1

--peter

Post by James Snell
Ok, this is something that has bugged me for quite a white... the atom:icon
and atom:logo elements are terribly underspecified as just a simple IRI.
Those these really should be link objects. What I'd like to propose is a
deprecation of those elements in favor of <link rel="icon" href="..." /> and
<link rel="image" href="..." />. The icon and image rel attributes would be
added to the registry of link relations...
So instead of..
<feed>
  <icon>http://.../image.jpg</icon>
  ...
</feed>
It would be...
<feed>
  <link rel="icon" href="http://.../image.jpg" type="image/jpeg" />
  ...
</feed>
The nice thing about this approach is that it does not actually require any
changes to the spec. The icon and image rel values would be added to the
registry and implementations would need to be modified to look for them as
an alternative to the icon and logo elements.
Thoughts?

[Bob Wyman]

+1

Things which are simply links should be encoded as links... It is frequently
seductive to provide special syntax to handle common or well-known cases,
but the end result is often just an unnecessary increase in complexity. It
is best to consistently encode all objects of the same general type and
reserve special cases for the truly special cases.

bob wyman

Post by James Snell
Ok, this is something that has bugged me for quite a white... the atom:icon
and atom:logo elements are terribly underspecified as just a simple IRI.
Those these really should be link objects. What I'd like to propose is a
deprecation of those elements in favor of <link rel="icon" href="..." /> and
<link rel="image" href="..." />. The icon and image rel attributes would be
added to the registry of link relations...
So instead of..
<feed>
<icon>http://.../image.jpg</icon>
...
</feed>
It would be...
<feed>
<link rel="icon" href="http://.../image.jpg" type="image/jpeg" />
...
</feed>
The nice thing about this approach is that it does not actually require any
changes to the spec. The icon and image rel values would be added to the
registry and implementations would need to be modified to look for them as
an alternative to the icon and logo elements.
Thoughts?

[Sam Johnston]

+1

Simple >> Complex.

Post by James Snell
Ok, this is something that has bugged me for quite a white... the atom:icon
and atom:logo elements are terribly underspecified as just a simple IRI.
Those these really should be link objects. What I'd like to propose is a
deprecation of those elements in favor of <link rel="icon" href="..." /> and
<link rel="image" href="..." />. The icon and image rel attributes would be
added to the registry of link relations...
So instead of..
<feed>
<icon>http://.../image.jpg</icon>
...
</feed>
It would be...
<feed>
<link rel="icon" href="http://.../image.jpg" type="image/jpeg" />
...
</feed>
The nice thing about this approach is that it does not actually require any
changes to the spec. The icon and image rel values would be added to the
registry and implementations would need to be modified to look for them as
an alternative to the icon and logo elements.
Thoughts?

[Mo McRoberts]

Post by James Snell
Ok, this is something that has bugged me for quite a white... the atom:icon
and atom:logo elements are terribly underspecified as just a simple IRI.
Those these really should be link objects. What I'd like to propose is a
deprecation of those elements in favor of <link rel="icon" href="..." /> and
<link rel="image" href="..." />. The icon and image rel attributes would be
added to the registry of link relations...

A great big +1 from me.

[Hadrien Gardeur]

+1 from me too and rel="icon" is already widely used in HTML

[Niklas Lindström]

+ 1 (and what Hadrien said).

Best regards,
Niklas


On Fri, Oct 15, 2010 at 6:12 PM, Hadrien Gardeur

Post by Hadrien Gardeur
+1 from me too and rel="icon" is already widely used in HTML

[Sam Johnston]

Bonus points for specifying length and width.

Post by Niklas Lindström
+ 1 (and what Hadrien said).
Best regards,
Niklas
On Fri, Oct 15, 2010 at 6:12 PM, Hadrien Gardeur

Post by Hadrien Gardeur
+1 from me too and rel="icon" is already widely used in HTML