Given RFC 5988, link relations that are not yet standard should be URIs. This one is a great example of why: if you don't know what the rel means, you can de-reference it and get documentation.
What about negative versions? Grayscale? Transparent vs solid backgrounds? Logotypes usually have a different version for each of these situations.
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.
I'm thinking perhaps you could have multiple instances of the tag, each for a different purpose. Most tools would use the first one, but if it's something like a browser plugin it would just display them all to you and let you choose.
Yup. rel="logo-foo" where "foo" is optional and some set of standard subtags.
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'.
This annoys me more when the whole page swallows my right clicks. Or, when it's used on Flickr to obfuscate image URLs. This use case most likely gives the user what they were looking for, unless they wanted to inspect with Chrome/Firebug/etc...
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.
Right, and that's a bit like trusting a site's meta keywords to fully describe the search engine keywords used to rank your site.
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.
On the contrary, structured microdata is used quite often by companies like Google and Facebook to understand your site better. Here are a few examples:
Rich snippets on Google allow you to customize your snippets in search:
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.
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.
This is neat, but as a designer I would be very wary about more explicitly allowing anyone to use my logo without adhering to the standards of the branding system. Most brands have extensive guidelines on how logos can and cannot be used. Nothing in this proposal helps make sure that guidelines will be adhered to, and in fact makes it easier for them to be violated.
As a fellow designer who spends a lot of designing these guidelines, I've thought about how to include these but it does hurt the idea of making it automated.
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"
That was for the microformat for logo. It was rejected because use rel="icon" type="image/svg+xml" already existed which is what this standard seems to push.
I can see various applications where third-party sites could enjoy the opportunity to reliably "pull" official logos that never get old, without having to duplicate/rehost/modify them and/or incur in trademark diatribes.
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.
I created a web app search engine http://iwaat.com that could make great use of this. If you need to index 1000s of sites/apps, collecting logos is still a very manual process. I imagine any other website directory, Google, news site, etc would find it useful.
I'm excited to see this come up again on Hacker News (I'm the guy proposing it). I would love for this to be an opportunity to improve my proposal. I originally put up the site over a year ago, and it has since been rejected by Microformats. I think there is room for improvement by offering variations of logos (grayscale, knockout, etc) and some way to referencing guidelines. I'd like to revisit this in hopes that it sees some larger adoption.
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)
If you're wondering why this would be nice, it's very useful if you want to write a blog post or something and say, "Hey, we just added support for XYZ to our tool"
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.
I've done that myself, extremely time consuming. Still though, I don't like having this in the markup, it seems pointless since almost no one would benefit from it. It'd be better to have /logo redirect and serve the correct file. There would be no initial request for determining where it is and it adds nothing to the page loads of all the other people who don't need it.
By making the logo universally available via a complete URL (not relative), one may copy the format of the authentic web page to create a duplicate and the logo would still apply.
Of course, this can be circumvented by using whitelists, but then those can be compromised as well.
I'm not sure that this abuse would have much negative consequence. Am I missing something?
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?
If you have a "Share on Facebook" style service, for example, and make it available to mobile devices (which don't have the greatest security to begin with), it would be easier to forge a widget and upload to compromised websites to trap unwitting users. Because the logo source is the original homepage (I.E. it's an original resource location) the malicious individual doesn't now need to have a local copy of the logo.
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.
This would be very useful for the web app directory I'm building at https://starthq.com. At the moment I attempt to retrieve a higher resolution logo by pretending to be an iOS device via the User Agent header and pulling out the apple-touch-icon meta tag value.
Funny thing about standards... without adoption, they don't mean much.
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.
It be great to query the api/a directory site to find out alternate versions or perhaps usage guidelines for the logo. Then each provider/company can have a canonical method for people to use their brand.
… its a cool idea, but somewhat floored when put into actual use.
