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.
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.
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.
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.
[+] [-] steveklabnik|13 years ago|reply
[+] [-] ricardobeat|13 years ago|reply
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.
[+] [-] MicahWedemeyer|13 years ago|reply
[+] [-] alexcroox|13 years ago|reply
[+] [-] rryan|13 years ago|reply
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.
[+] [-] taftster|13 years ago|reply
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.
[+] [-] justinph|13 years ago|reply
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...
[+] [-] mattmcinerney|13 years ago|reply
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"
[+] [-] chaz|13 years ago|reply
[+] [-] aaronpk|13 years ago|reply
[+] [-] zbowling|13 years ago|reply
[+] [-] hayksaakian|13 years ago|reply
I understand favicons and the apple touch thing -- those are used as icons on various systems.
What would this be for?
[+] [-] toyg|13 years ago|reply
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.
[+] [-] tass|13 years ago|reply
* 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.
[+] [-] hayksaakian|13 years ago|reply
[+] [-] Lukeas14|13 years ago|reply
[+] [-] nthitz|13 years ago|reply
[+] [-] modarts|13 years ago|reply
[+] [-] mattmcinerney|13 years ago|reply
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)
[+] [-] MicahWedemeyer|13 years ago|reply
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.
[+] [-] pdenya|13 years ago|reply
[+] [-] thesorrow|13 years ago|reply
[+] [-] mattmcinerney|13 years ago|reply
[+] [-] olegp|13 years ago|reply
[+] [-] eksith|13 years ago|reply
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.
[+] [-] SquareWheel|13 years ago|reply
[+] [-] benschwarz|13 years ago|reply
… its a cool idea, but somewhat floored when put into actual use.