Favicon Cheatsheet
github.com
Favicon Cheatsheet
1–10 of 55 posts
Re: Favicon Cheatsheet
#2Re: Favicon Cheatsheet
#3Re: Favicon Cheatsheet
#4I've not touched it in over a year but it still gets used every now and again.
Re: Favicon Cheatsheet
#5Could not believe we should be considering giving so many different favicon sizes from 195px (Opera Speed Dial) down to 16px. Wider SVG support in favicons would be welcome.
I believe SVG still has no support for hinting (or not enough to be worth talking about).
Because of the resolution range, either extremely strong rasterizer hinting (supporting not only pixel-snapping but the complete addition or removal of features and the like) or multiple bitmaps is necessary to avoid getting either blocky output at "high" resolutions or a blurry and unusable mess at low ones. You can see the issue by comparing OSX's actual Pictures folder icons[0] with what you get just by scaling the biggest icon down[1] or the smallest one up[2]. [0] looks good and recognizable at all sizes, [1] is a blurry mess from 32px down and [2] looks terrible above 32px (and not too good at 32px either).
And even at constant resolution, different densities (and thus different physical sizes) require different levels of details: Opera puts 195px in up to 4.5~5cm (as far as I can see by opening Opera, maximizing it and looking at the speed dial screen) where an iPad puts 144px (152 in iOS7) in about 1cm (not measured as I don't have one, if somebody can provide the exact dimensions of app icons it would be great). You can't[3] put precise information in an iPad icon as most users will be unable to see it, whereas a huge icon and nothing else would be a waste of space on Speed Dial.
[0] http://media.tumblr.com/tumblr_l456vgN8oa1qz50x3.png
[1] http://media.tumblr.com/tumblr_lurpsf1owX1qz50x3.png
[2] http://media.tumblr.com/tumblr_lurpyq9FPu1qz50x3.png
[3] well you can, and it makes for great easter eggs, Apple's icon designers — amongst others — are known to have great fun with that[4], but I'm sure you get the point
[4] http://gigaom.com/2009/07/27/a-closer-look-at-apples-icons-s...
Re: Favicon Cheatsheet
#6For 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/
Re: Favicon Cheatsheet
#7Re: Favicon Cheatsheet
#8Re: Favicon Cheatsheet
#9location = /favicon.ico { return 204; access_log off; error_log off; }
Re: Favicon Cheatsheet
#10This collection of vendor-specific hacks is an excellent demonstration of the failure of the Web standards process.
iOS had the retina display with mobile safari first, then came Microsoft's metro interface which brought tiles and going forward we're probably going to see many more devices and browsers that handle some aspects of web resources differently and for good reason. We can't expect the web standards committees to be able to account for all of these advances as fast as they come about and I'd argue that's exciting and good.
Furthermore I'd say web standards already do take care of this in the most elegant way I can think of. The tag is totally standard and future proof when it comes to favicons. I don't see anything wrong with adding a link tag with standard attributes to support multiple devices here. The purpose of a favicon is to associate a small image with a website or URL in general. Not all sites need the apple-touch icon or windows tile but some do. What we're seeing here is an attempt to target specific browsers on specific devices for very specific cases. By and large the standard desktop browser favicon has never changed. When you take all that into consideration I think its actually quite reasonable for these different methods of specifying favicons to exist.
I'll grant you that adding all that in your markup is ugly and having to think about which devices you want to target is a pain especially once you've decided on it and then have to start thinking about which markup to use and in what order.
Still, this isn't a case where vendors are using proprietary markup to capture more of the market or doing anything "evil". It's more a case of using an existing standard to take advantage of a specific device capability. Standardizing the way web/markup languages are handled is good but trying to standardize favicons in this context seems like an awkward way of trying to standardize how a device and/or browser and/or OS handles its UI and is not good.
Edit: I can't think of a good way we can standardize this but I am curious if there's anyone out there that has a decent idea for how we can standardize how we specify favicons for the plethora of devices we have now and will continue to see going forward.