Favicon Cheatsheet

https://github.com/audreyr/favicon-cheat-sheet

by eliot_sykes • 13 years ago

301 54 13 years ago

eliot_sykes2• 13 years ago

Could 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.

masklinn• 13 years ago

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...

giovannibajo1• 13 years ago

SVG has a "shape-rendering:crispEdges" option that you can use to snap lines to pixels. See this blog post for more details: http://simurai.com/post/19895985870/icon-sharpness-limbo

TallboyOne• 13 years ago

More favicon goodies: http://pineapple.io/tags/favicons

TamDenholm2• 13 years ago

For 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/

eliot_sykes2• 13 years ago

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.

TamDenholm2• 13 years ago

Cheers. I may integrate the changes in the cheatsheet one day if i ever get round to updating my old side projects. :)

thisishugo2• 13 years ago

I remember this from the the original hacker news thread and still use it. Anything 'real' gets custom rendered icons for each size, but for side projects where the icon quality isn't critical it's very convenient.

tagawa2• 13 years ago

For reference, the original HN thread: https://news.ycombinator.com/item?id=4529963

joeblau2• 13 years ago

Can you open source this so I can beef it up please?

Edit: Actually, I just realized I can probably build this in a weekend with image magic.

mattrad• 13 years ago

Icon Slate is pretty good too. Mac only.

http://www.kodlian.com/apps/icon-slate

NelsonMinar2• 13 years ago

This collection of vendor-specific hacks is an excellent demonstration of the failure of the Web standards process.

bpatrianakos2• 13 years ago

I disagree and believe there is more upside to this than downside. You certainly can't say that the fact that different browsers and devices handle favicons differently is a standards issue. If you were to try to standardize this then we'd end up with either a very large and complex standard (close to what we unofficially have now) or a lack of innovation. Innovation isn't the exact right word I'm searching for but what I'm getting at is that forcing vendors to use set sizes and naming conventions would detract from some of the small but important UI and even hardware differences in devices and browsers.

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 <link> 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.

evmar• 13 years ago

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.

ftwinnovations• 13 years ago

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.

bpatrianakos2• 13 years ago

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.

crazygringo• 13 years ago

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.

javajosh3• 13 years ago

an excellent demonstration of the failure of the Web standards process

After reading the wikipedia article, it appears that IE is the only browser that doesn't support the W3C standard.

It's high time to stop supporting the monstrosity that is IE. All webapps and websites should be built for standards-compliant web browsers, and prompt the user to install one if they are on IE, and simply refuse to work otherwise.

The success of the web standards process is in users hands, and what users do is in developers' hands.

cmircea2• 13 years ago

Good luck with that.

tagawa2• 13 years ago

Failure? There may be problems with the Web standards process but I don't think it could be classed a failure.

cgtyoder• 13 years ago

This is so incredibly handy. I've been searching the internets for this page for years now.

aquarin• 13 years ago

Here is my solution to the "problem". In Nginx config:

location = /favicon.ico { return 204; access_log off; error_log off; }

psychometry• 13 years ago

Those of us who like to bookmark sites on our bookmarks toolbar without any text will find your suggestion very annoying.

tombrossman• 13 years ago

This is exactly what I do, too. I've got the Bookmarks Toolbar in Firefox with just favicons all the way across. I don't need the text alongside and prefer to remove it to fit more icons instead.

stock_toaster• 13 years ago

Wouldn't "return 410" (potentially) be better?

marban• 13 years ago

I declare 2013 as the year of Favicon Wars.

audreyr3• 13 years ago

Hi, 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?

sergiotapia• 13 years ago

Here's an idea for an app:

1. Upload a large, centered image, and have it spit out all of these different sized, optimized favicon images for me.

The initial image should be large enough to accommodate all lower sizes.

Any takers? :)

thisishugo2• 13 years ago

http://www.allthefavicons.com/

glitchdout• 13 years ago

The thing is, it's pretty much impossible to optimize images for such small sizes. If you want perfect favicons, you'll have to make them yourself.

Look at this example: http://www.typophile.com/node/60577 (Youtube's old favicon)

benguild• 13 years ago

Updated it as follows: 64x64 ... Safari Read Later sidebar in HiDPI/Retina

lyndonh3• 13 years ago

I think I'm going to vomit if I see another web page written in the 21st century that condones the use of ICO format.

Please, please, please can we have some kind of multi image PNG format ?

How about multiple PNG images wrapped in a TIFF container ?

With cross browser support, pretty please.

Anything but ICO. ICO format is nasty.

audreyr3• 13 years ago

That's what I thought too, until I did more research on ICO and couldn't come up with an answer for "Why use png in addition to ico?" in the FAQ (well, except for touch devices where ico isn't supported). Notice how that FAQ question is empty.

But if you could submit a pull request with a bulleted list of PNG advantages over ICO, I'd be happy to include it. Seriously.

lyndonh3• 13 years ago

PNG is a properly specified format with written documentation.

ICO has many undefined and assumed values.

The only reason you would use ICO for favicons instead of PNG is that it supports multiple images.

e12e• 13 years ago

Awww. Without formats like BMP, ICO and friends, there are so many fewer libraries to exploit buffer overflows in!

mappu2• 13 years ago

ICO is a kind of multi image PNG format.

lyndonh3• 13 years ago

ICO is multi image BMP and it's poorly defined

HipstaJules• 13 years ago

http://www.jonathantneal.com/blog/understand-the-favicon/ this is really related and clear!

ianstormtaylor• 13 years ago

Don't you always want your favicon at / regardless because everything that grabs favicons automatically will look there, and not parse your /index.html to figure out what the meta tag is?

Other than that, this seems very handy!

mherkender• 13 years ago

Why don't we have mipmapping on the web? I've never heard anyone suggest it before, but it seems like a good solution to this problem and all the other pixel ratio kinds of problems.

cben• 13 years ago

If you mean ability to supply several, potentially hand-crafted images for different sizes — that's exactly what .ico already offers.

If you stick to the precise definition of mippmapping, where they're exact downscalings of one texture, that solves a different problem — efficient downscaling, only sampling O(1) texture pixels per displayed pixel.

On the web CPU isn't the problem; there are 2 other reasons so serve several sizes:

(1) Tiny images (like favicons) don't scale well, you might want manual intervention. (2) Too large images waste bandwidth => you want negotiation, especially to transmit less to mobile devices.

.ico was a quite elegant solution to (1) actually. I guess all the mess comes from icon resolutions growing enough to turn the problem into (2)...

There several efforts to solve this generally — google "Responsive Images", "srcset". I'd think progressive JPEG and PNG could have solved (2) well — just stop downloading when you had enough quality — but many people say that's not enough :-(

oneeyedpigeon• 13 years ago

"Forcing a Favicon Refresh ... For yourself and all site visitors: Append a query string. (TODO: find out if any browsers have problems with this.)"

Don't do this - it prevents the file from being cached by some proxies [1]. Instead, use a filename-based approach to 'cache busting' [2].

[1] http://www.stevesouders.com/blog/2008/08/23/revving-filename... [2] https://github.com/h5bp/server-configs-apache/blob/master/.h...

the1• 13 years ago

pollute yo metadata with vendor crap. just like jpeg.

joeblau2• 13 years ago

There is also this: http://favicon.io/

Favicon Cheatsheet

Related Stories