Rel="logo" (2011)
relogo.org
relogo.org
rel="http://relogo.org/"
It's too weird to have a meta tag that is only useful for websites with a white background. The narrow use case for this was solved years ago with the hcard micro format. We should be pushing microdata, not creating new niche standards.
You could even consolidate this so you had rel="logo-favicon" and the favicon just become another aspect of your logo.
All that said, I think it's a solution looking for... well, not a "problem" really, because the problem is obvious. Rather, the whole thing seems like a solution to a problem that not enough people have. I'd wager the 2011 proposal would have gotten more traction and some format adopted if this were really a pressing concern.
You know what? What I'd like to see is some kind of de facto standard rel="foo" database that, a bit like the WHATWG, kind of becomes a place where you can submit rel types, spec a schema behind it, go through some semi-formal vetting and standardization process, and be able to crawl this information in a semantically-meaningful way (in addition to just researching the different types). It'd also be nice to formalize a migration path from a <link rel="x-foo"> as a prototype declaration to a <link rel="foo"> as a 'standard'.
The closest we have to this is probably the HTML spec and WHATWG's page (http://blog.whatwg.org/the-road-to-html-5-link-relations).
That said, for this case, this right click implementation seems smart.
This is useful because it's an easy way for you to declare what your logo is to spiders looking at your site. Google/Facebook/Foursquare/etc. can then use this annotation to know what logo to associate with your page instead of having to guess algorithmically.
This is an interesting thing, because how much does a search engine exactly trust your site content, especially very specific tags like this? Not very much trust, it seems to me.
Rich snippets on Google allow you to customize your snippets in search:
http://support.google.com/webmasters/bin/answer.py?hl=en&...
Using microdata and Schema.org annotations you can control the snippet that is used when your article is shared on Google+:
https://developers.google.com/+/plugins/snippet/
Google+ Local / Maps use microdata on your page to understand things like store hours, address, telephone number, categories, etc.
http://maps.google.com/help/maps/richsnippetslocal/faq.html
In fact, in the Google Webmaster Tools dashboard there is a central place where you can go to verify that the structured data Google has extracted from your site is correct (and if not, change your markup).
Facebook's Open Graph microdata format allows you to describe your site in a way that Facebook can understand. This helps when generating snippets or treating your content as media content when it gets shared on Facebook. For businesses / places they surely use this for phone numbers, address, services, etc.
http://ogp.me/ https://developers.facebook.com/docs/concepts/opengraph/
Using a logo annotation, if Facebook were to make a synthetic place page for your business or company you could imagine them looking at a logo annotation on your site to decide what logo to use. This stuff is commonplace.
The easiest and most egregious use I could anticipate is not using proper white space, which almost every logo requires. Example: https://fedoraproject.org/wiki/Logo/UsageGuidelines#Clear_sp...
If this proposal is to remain in it's simplest form, it would require the default logo selected to be one that is as flexible as possible and would require the design to possibly build in the space required, background color, etc.
There may also be room for additional tags that would describe the usage i.e. rel="logo grayscale" or rel="grayscale knockout"
I understand favicons and the apple touch thing -- those are used as icons on various systems.
What would this be for?
* News site writes an article about you, grabs your logo for the article.
* Mapping applications could display your logo with your address information
Basically, it's just a way of getting an officially sanctioned website/business/whatever logo without needing to ask.
For example, a stock-trading website could have official logos near (or even replacing) stock tickers. "Log in with *" buttons could be dropped altogether, mandating websites to pull the official logo. And so on.
However, like every "machine-oriented" standard that promotes embedding, I can't help but feel there are security implications, something which might not be obvious now but will end up biting our ass 5 years down the line, when spammers and gangsters start exploiting some hole in the mechanism. Embedding untrusted images is already unsafe as it is, adding support for SVG looks even more unsafe.
EDIT: and as someone else mentioned, it makes phishing easier.
As a side note, for anyone interested in further thinking on this, I've discussed it on this podcast: http://onthegrid.co/post/40903339954 (discussion starts at 29:20)
Think of the sites that allow you to share on different services and they have like 100s of logos. Imagine trying to build that list. I've done stuff like that and it's a pain to try and find all the images. If there were a Chrome plugin that would tell me that a site has a sanctioned logo, it would simplify this kind of task by a ton.
Of course, this can be circumvented by using whitelists, but then those can be compromised as well.
Let's say I copy the Google homepage and in the <head> there is a reference to http://google.com/logo.svg How does that create any more problems than already exist?
This is why the original resource provider that hosts the logo would need to have a whitelist of which sites may allow their logo to be displayed. Of course, if a whitelisted site is compromised, then you still have the same problem.
It would also mean that there is the potential for a man-in-the middle attack by injecting code to the SVG file as it is delivered through the widget. Some browsers may allow scripting to be executed (since SVG is basically XML) if the script is within a CDATA block. If the original resouce location is compromised, then pretty much anyone using the direct link to the logo (be it widget, website or other consumer service) may end up receiving an unpleasant package with the logo.
This can be corrected by proper browser standards that don't allow execution of code within SVG files, so I hope in that regard it does catch on. Overall, it's a good idea that still has a few hiccups, but that's mostly due to browser/consumer security issues that need to be corrected.
And before you know it, you're littering pages with fallbacks for browsers that don't support it. I hope this one catches on though. It makes a lot more sense to have just one or two files for logos that can be reused everywhere.
… its a cool idea, but somewhat floored when put into actual use.