This blog can't be viewed on LiveJournal. Instead see http://www.apparently.me.uk/8714.html.

On Discoverable Avatars

22nd Apr 2007

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.

Comments

  • Good proposal

    I like your proposal for rel-avatar. It's a good candidate for use as a POSH convention and one that plays nicely with the hcard photo element.

    To push forward with this -- I still would argue that the photo object in an hcard should suffice as an avatar, but that doesn't mean that you can't wrap that IMG in a rel-avatar link to the full size original. If and only if the photo-classed avatar on the page is *also* the full size avatar, might you see a dual-classed IMG, with "photo avatar" as the IMG's class values.

    I'd like to see if it'd be possible to apply this draft concept to existing profile pages in the wild and see, perchance, if we couldn't get some to adopt both our suggestions.
    By Chris Messina at 05:31 pm on 22nd Apr 2007

    • Re: Good proposal

      A photo that's wrapped in an hCard has enough context to be assumed to be an avatar, as long as the hCard can be determined to belong to the resource identified by the page (that is, the owner of the page). This would not be the case, for example, if an author were using XFN and hCard together to make a list of his friends.

      This sort of thing could potentially be added automatically for all LiveJournal users, but LiveJournal-hosted “avatars” are limited to 100×100px so they'd be well below your desired standard, and it might also make it difficult for users to override the avatar with their own, off-site image if LiveJournal is generating a LINK automatically; they'd be able to override it with an A element in their custom style per the rules I proposed, though.

      One problem with the avatar being visible data is that avatars generally appear on a profile page, but many OpenID URLs are actually weblog indices rather than profile pages; for all LiveJournal users, their provided OpenID URL is their journal. MyOpenID can feasibly embed a visible avatar on their pages, but LiveJournal could not mandate visible avatars across all of their hosted journals because the pages have another purpose alongside being an OpenID identifier.

      By Martin Atkins at 08:16 pm on 22nd Apr 2007

      • Re: Good proposal

        There have been discussions on how to pick out an "authoritative" or "definitive" hcard on a page with multiple hcards, to handle the case that you mentioned. As well, Tantek suggested using a "logo" classed image in the case of multiple photos within one hcard.

        In terms of sizing, my recommendation is that people *should* use a large size, like 512px, but that it's not a must -- given current trends and behavior. I've suggested the larger size to handle many different uses, including uneven avatar dimensions.

        I actually think that the OpenIDs that result in a blog indice is a perfect use case -- as it is, I have an hcard on my OpenID, as does Tara, and she even specifies her photo. There's no reason why you couldn't include the rel-avatar or class-photo/class-logo on that page. I think MyOpenID already supports this, and in my next post on this subject, I'd like to look at how easy it might be to retrofit existing sites.
        By Chris Messina at 01:39 am on 24th Apr 2007

  • Pavatar

    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.

    The specification is not stable yet, there are discussions about changing the term pavatar to avatar, see: http://pavatar.com/forum/forum_entry.php?id=13

    I thought that i do not have the right to take the english word "avatar" to use it that way. But if all people think it is ok, I have no problem with changing the spec, which is not stable yet.
    By ext_42659 at 08:23 pm on 22nd Apr 2007

    • Re: Pavatar

      While obviously I have no authority to give permission for this usage, I don't really see the harm in it. As long as what's being linked to is an avatar for the current page, that's entirely consistent with the semantics of the REL element. I don't think many people would argue that rel="avatar" could mean anything else.

      By Martin Atkins at 08:38 pm on 22nd Apr 2007

    • rel="avatar"

      Thank you!

      While "the Pavatar folks" are considering, two implementations already support this:

      http://openid.phpbb.cc/2007/03/13/avatar-invasion
      By Dmitry Shechtman at 04:52 pm on 23rd Apr 2007

  • (comment with no subject)

    Tatil Yerleri
    Vakfıkebir

    thanks for the information.
    By vakfike1 at 02:19 pm on 8th Jun 2008

  • pavatar

    I'm happy enough just working with HTML documents for now

    Zero-Day Blog
    By marryiness at 12:07 am on 28th Sep 2008