Chris Messina has written about a possible new standard for avatar discovery. I agree with many of his premises, but few of his solutions.
My major bone of contention is the proliferation of so-called “URL conventions”. We already have /robots.txt and /favicon.ico, and these suck. Why? The web is all about hyperlinks. We discover other documents by following links from one document to another. This design principle works well, because everyone can make their own little world with whatever naming conventions suit them and yet everyone can still inter-operate. “Hard-coding” particular URLs reduces flexibility and creates implementation headaches.
There are various ways to create hyperlinks, the foremost being the A and LINK HTML elements; Chris rejects the latter because it is “invisible”, which is a legitimate gripe. He proposes the use of IMG instead, which on the surface seems sensible. However, IMG is not a hyperlink element as such, it's an embedding element. It indicates a “containing” relationship. This may seem like minor quibbling, but note that IMG lacks the REL attribute that is present on hyperlinks because there is only one possible relationship that IMG can express: the image is contained within the document.
I would propose, then, that both of HTML's hyperlink constructs be allowed, with rel="avatar" or similar, and the author be able to choose which is most appropriate. After all, it's the relationship that's important, not the element name. You'd have to say which one wins when more than one appear, so I'll just arbitrarily decide that A wins over LINK and if multiple of each appear the first one wins. So how would I embed my avatar now? I have two choices:
<link rel="avatar" href="/avatar.jpg" type="image/jpeg" />
<a rel="avatar" href="/avatar.jpg" type="image/jpeg"> <img src="/avatar-small.jpg" width="100" height="100" alt="" /> </a>
Making your avatar visible in the rendered page is possible, but optional. Browsers/plugins could still pick up on either and display it in their UI chrome. The important thing is to remember, though, is that rel="avatar" indicates that it's an avatar for the source URI. This URI might be a representation of a person, but it's the URI that the relationship is really with. This has a big implication: it is not appropriate to display a list of your friends' avatars on your page with rel="avatar".
That just leaves the topic of size. Chris proposes that the conventional size for an avatar defined in this way be 512×512. I've no real objection to that as a size, and I knocked up a test avatar at that size that weighed in at just over 40kB as a JPEG, which isn't too bad. It did get me thinking about ways to provide multiple image sizes, however. My first idea was an extension to HTTP content negotiation, but I don't think that's realistic in practice since it's likely to confuse existing cache implementations and wouldn't work for images embedded directly into HTML for client-side resizing. Instead, here's a different approach:
<link rel="avatar"
href="/avatar-small.jpg"
type="image/jpeg; width=100px, height=100px" />
<link rel="avatar"
href="/avatar.jpg"
type="image/jpeg; width=512px, height=512px" />
Now the consumer of images can find the one that seems like the best choice. This technique does allow for “dumb” clients that just embed the image URL directly into HTML and scale client-side, though, which I expect will be a common case for some time to come. (Not sure what you'd put in as the dimensions for a vector image, to be honest.)
It's a shame that the Pavatar folks didn't use “avatar” as their relationship, or else this'd be backwards-compatible with anyone publishing a “pavatar” in their HTML already. Note also that the Link HTTP header could be used in place of the LINK HTML element for non-HTML documents; I'm happy enough just working with HTML documents for now, though.
