Subject: deprecate icon and logo elements?

From: James Snell <[email-masked]>
Date: Wed, 13 Oct 2010 09:59:06 -0700

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?

---

From: Antone Roundy <[email-masked]>
Date: Wed, 13 Oct 2010 12:37:32 -0500

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

---

From: Peter Keane <[email-masked]>
Date: Wed, 13 Oct 2010 12:34:23 -0500

+1

--peter

---

From: James Snell <[email-masked]>
Date: Wed, 13 Oct 2010 10:44:41 -0700

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.

---

From: Bob Wyman <[email-masked]>
Date: Wed, 13 Oct 2010 13:51:30 -0400

+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

---

From: Sam Johnston <[email-masked]>
Date: Wed, 13 Oct 2010 20:03:19 -0400

+1

Simple >> Complex.

---

From: Mo McRoberts <[email-masked]>
Date: Thu, 14 Oct 2010 10:18:36 +0100

> added to the registry of link relations...

A great big +1 from me.

---

From: Hadrien Gardeur <[email-masked]>
Date: Fri, 15 Oct 2010 18:12:41 +0200

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

---

From: Niklas Lindström <[email-masked]>
Date: Sat, 16 Oct 2010 21:54:58 +0200

+ 1 (and what Hadrien said).

Best regards,
Niklas

---

From: Sam Johnston <[email-masked]>
Date: Sat, 16 Oct 2010 16:08:22 -0400

Bonus points for specifying length and width.

2010/10/16 Niklas Lindström <[email-masked]>

---

From: Aristotle Pagaltzis <[email-masked]>
Date: Mon, 25 Oct 2010 22:01:19 +0200

* Antone Roundy <[email-masked]> [2010-10-13 19:40]:
> 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).

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,
-- 
Aristotle Pagaltzis // <http://plasmasturm.org/>