Here is my solution to the "problem". In Nginx config: location = /favicon.ico { return 204; access_log off; error_log off; }
Those of us who like to bookmark sites on our bookmarks toolbar without any text will find your suggestion very annoying.
Favicon Cheatsheet
11–20 of 55 posts
Re: Favicon Cheatsheet
#12This collection of vendor-specific hacks is an excellent demonstration of the failure of the Web standards process.
Historically, the web standards process was theorized to work like:
1) vendor introduces new feature, tagged with vendor name to not pollute the namespace (e.g. -webkit-foo, or msapplication-TileColor from the OP)
2) once feature becomes popular enough to warrant its permanence, vendors agree on some new standard name for the agreed-upon behavior
3) ???
4) everyone uses the new standard name
The problem with this idea is that step 3 is missing. Browsers can't drop their -webkit CSS support because old pages rely on it, and new pages still use -webkit to work on old browsers. The original name is effectively permanent so there's little incentive to even take step 2, because all that produces is two names for the same thing (e.g. you use an attribute with "apple" in the name to choose the Android icon).
In recognition of the failure of this process, Blink (and other browsers) is using a different approach, where new features are not namespaced; instead, they'll require users to individually opt-in to nonstandard features, under the idea that it's hard for an idea to become permanent if it requires each user to individually configure their browser:
http://www.chromium.org/blink#vendor-prefixes
I am a little skeptical that this will only result in going too far the other way -- new features will wither because you can't experiment with them enough to get enough mass behind them to standardize them -- but at least it's not retreading the known broken path.
Re: Favicon Cheatsheet
#13Here is my solution to the "problem". In Nginx config: location = /favicon.ico { return 204; access_log off; error_log off; }
Wouldn't "return 410" (potentially) be better?
Re: Favicon Cheatsheet
#14For what its worth i made a tool a while back that takes a big image and makes a bunch of sizes for you as well as the code etc. I've not touched it in over a year but it still gets used every now and again. http://allthefavicons.com/
Looks useful, thanks for the link. In case its news to you, with iOS7, a few more suggested dimensions have been introduced than what is available on allthefavicons.com at the moment. More details at the cheatsheet.
Cheers. I may integrate the changes in the cheatsheet one day if i ever get round to updating my old side projects. :)
Re: Favicon Cheatsheet
#15I declare 2013 as the year of Favicon Wars.
Re: Favicon Cheatsheet
#16This collection of vendor-specific hacks is an excellent demonstration of the failure of the Web standards process.
Historically, the web standards process was theorized to work like: 1) vendor introduces new feature, tagged with vendor name to not pollute the namespace (e.g. -webkit-foo, or msapplication-TileColor from the OP) 2) once feature becomes popular enough to warrant its permanence, vendors agree on some new standard name for the agreed-upon behavior 3) ??? 4) everyone uses the new standard name The problem with this ide…
5) wait another 7 years for IE to implement it, with their own "twist".
6) wait another 5 years for IE to properly implement it.
Re: Favicon Cheatsheet
#17Earlier quoted context omitted.
Historically, the web standards process was theorized to work like: 1) vendor introduces new feature, tagged with vendor name to not pollute the namespace (e.g. -webkit-foo, or msapplication-TileColor from the OP) 2) once feature becomes popular enough to warrant its permanence, vendors agree on some new standard name for the agreed-upon behavior 3) ??? 4) everyone uses the new standard name The problem with this ide…
5) wait another 7 years for IE to implement it, with their own "twist". 6) wait another 5 years for IE to properly implement it.
I haven't tested nor cared how something appears in IE in years. Since like 2009. I have worked on major frontends for a couple of big companies all this time and recently a startup. IE is the new opera. IE needs to make sure that everything works. It may have large marketshare, but it's the market that's irrelevant to anything I've worked on (IT and business related tools and control panels).
Re: Favicon Cheatsheet
#18This collection of vendor-specific hacks is an excellent demonstration of the failure of the Web standards process.
Exactly. Reading the whole document, and realizing I already knew every single piece of information in it, almost made me want to cry. The fact that I've spent so much time accumulating knowledge that, in the end, is such garbage.
But at least I've had the luxury of accumulating it slowly, over what has been, by now, almost 20 years. I can't even imagine showing this page to someone getting started in web development. They'd think the whole thing was designed by insane people.
Re: Favicon Cheatsheet
#19This collection of vendor-specific hacks is an excellent demonstration of the failure of the Web standards process.
Historically, the web standards process was theorized to work like: 1) vendor introduces new feature, tagged with vendor name to not pollute the namespace (e.g. -webkit-foo, or msapplication-TileColor from the OP) 2) once feature becomes popular enough to warrant its permanence, vendors agree on some new standard name for the agreed-upon behavior 3) ??? 4) everyone uses the new standard name The problem with this ide…
Is this really how it works? I know many do go solely with the -webkit or -moz property name to experiment with new features but for any site that's important (not an experiment, needs decent cross browser support) what I see happening is that most developers will do it the right way - they'll use all the available prefixes and end with the eventual standard property name while at the same time ensuring that use of these new features doesn't look completely broken in browsers that don't support the prefixes or non-prefixed version.
It's very rare that I'll see a developer code in such a way that they totally leave out a fallback or code with just one browser in mind. At least not when it comes to any site of importance (these include any site meant for a large audience, non-techies, business, and just generally not a site put together purely for showing off the uses of an experimental feature).
I didn't know Blink was going that route too. I fear that the use of new experimental features will stagnate if Chrome becomes too popular among non-techies.
Re: Favicon Cheatsheet
#20Hi, author of the cheatsheet here.
I'm thinking of changing the snippet under "The Basics" to be what's suggested in issue #3 (https://github.com/audreyr/favicon-cheat-sheet/issues/3). Any feedback before I make the change?