Web Site Icons

I recently got this following short article posted in the Mac-focused Kibbles & Bytes. I thought that there was probably a pretty small overlap between readers of this blog and Kibbles & Bytes, so I’m reprinting it here (with permission, of course) minus the author introduction (which would only make me blush). I hope you’ll find it interesting.

More on Favicons

Two issues ago there was an introduction to favicons. If you found it informative, read on, as there’s lots more to favicons (and more generically page icons) than was covered in that first article. In particular there are three things that should be additionally mentioned: favicons have another important capability, they have one key limitation, and they have a more standard alternative.

To really understand favicons at a deeper level it’s necessary to consider very briefly their origins. It’s clear that Microsoft hadn’t really thought through either the favicon implementation or its consequences when they first introduced favicon support in Microsoft Internet Explorer (MSIE) 5.0. There were a few obvious issues:

1. The .ICO format was very much an MS-Windows specific format. Even today it’s not too well supported on non-MS-Windows systems, and it didn’t yet have an official registered MIME type (further slowing its adoption elsewhere). Even MSIE itself didn’t support .ICO files in its Solaris, HP-UX, and Mac OS incarnations.

2. The versions of MSIE that did support favicons did something contrary to the nature of the Web itself by automatically assuming that a particular file would exist in a particular location on every server in the world. They automatically tried to download /favicon.ico whenever a user tried to set a bookmark. This sort of behavior is strictly taboo and it got lots of webmasters really upset with Microsoft.

3. Because the favicon resource would be downloaded only when users tried to set bookmarks, privacy advocates also got a little upset with Microsoft as it became theoretically possible for webmasters to track individual users who bookmarked their sites.

4. The recommended favicon <link> tag of:

    <link rel="shortcut icon" type="image/x-icon" href="/favicon.ico" />

   is logically invalid HTML because the rel attribute officially contains space-delimited items, so shortcut icon should be treated as two separate relations rather than one. It’s also already been mentioned that the MIME type listed in the type attribute was unregistered. Of course, this line could be omitted as MSIE would try to download /favicon.ico regardless; it was only necessary if an alternative location for the icon were specified.

5. When Microsoft finally registered an official MIME type for the .ICO format (image/vnd.microsoft.com) they didn’t go out of their way to support it and encourage webmasters to stop using the unofficial image/x-icon type. In fact, even today, if you’re going to be using favicons, you’re advised to use the improper form for compatibility reasons.

By now you may be thinking “what does all this have to do with additional capabilities, limitations, and alternatives?” The answer is that (as you might guess from #1 above) there are some tricks and issues that arise from the .ICO format’s MS-Windows origins, and (as you might guess from all the points above) there was some motivation to try and clean up a messy situation by introducing alternatives.

First I’ll touch on the additional capability of traditional favicons. Basically it’s the fact that the .ICO format isn’t really an icon as it may appear at first blush; it’s more of a bundle of icons. A single .ICO file can contain one or more icons of different sizes, and MS-Windows can make use of more than just the common 16×16 size. In fact, MS-Windows will happily gobble down 16×16, 32×32, and 48×48 icons and use each appropriately (16×16 for various places including the URL box and the others for various places including the desktop). In fact, if a favicon lacks larger versions, MS-Windows will take the 16×16 version and attempt to scale it up with sometimes hilarious (at least on other people’s favicons — with your own favicons it tends to be more depressing) results. I’ve also heard, but never personally verified, that certain versions of MS-Windows in certain circumstances will use both 24×24 and 64×64 favicons if available. The obvious drawback with providing more sizes is that it leads to a larger .ICO file and thus slower download times. Certainly though if you’re planning to create a favicon for your site, it’s worth making at least the 16×16, 32×32, and 48×48 versions, and Microsoft themselves recommend including at least this many.

Other browsers and other platforms have had to add some favicon support. Nowadays the 16×16 icon is supported by pretty much every graphical browser on every platform, but the support for other sizes remains weak. Of particular interest though is that Mac OS X natively supports 128×128 icons, and Vista natively supports 256×256 icons. Really forward-thinking webmasters will realize that these sizes probably also ought to be embedded into favicons sooner rather than later as they’re pretty much guaranteed to find a use, but again consider file sizes.

Next it’s important to mention the big limitation with traditional favicons: color. To make a favicon that’s guaranteed to display the same everywhere, it’s necessary to stick to the limited 4-bit, 16-color “Windows Default Palette”. This palette basically consists of white, red, yellow, blue, green, magenta, cyan, dark gray, and darker versions of the same (with “dark white” being light gray, and “dark dark gray” being black). This palette does not usually lend itself to the creation of beautiful favicons. There are two work-arounds. The first is to accept that some viewers will see your favicon as a psychedelic mess and use a larger palette; if you stick to the regular 216-color “Web Safe Palette” the vast majority of users will have no trouble. The second is to include multiple icons of different palettes within the favicon. This latter approach quickly leads to large file sizes (a favicon with both 8-bit and 24-bit color versions will not be just twice the size of the favicon with only an 8-bit version, it’ll be roughly four times the size), and it’s still not guaranteed that every system will be smart enough to pick the best color depth it can properly display.

Actually making a multi-icon favicon is a topic for another article. I’ll provide a quick tip though for advanced readers who aren’t afraid to use the Terminal.app: check out the free NetPBM utilities. The included program ppmtowinicon can create multi-icon favicons.

Now it’s finally time to get to the standard alternative. Basically all one does is to use:

 <link rel="icon" type="image/png" href="/icon.png" />

in lieu of the common shortcut icon version mentioned above. Note that this changes three things:

1. The shortcut icon changes to icon fixing the HTML logic issues with the original.

2. The type changes to image/png, a standard, platform-neutral image format with a proper MIME type. You’re also free to use GIFs rather than PNGs. Either way, they are more size-efficient than .ICO files. While it’s still prudent to stick to the Web Safe Palette in most cases (and the need for even this is reducing each day), one never has to worry about a 16-color Windows Default Palette. PNGs and GIFs are also far easier to work with, and advanced features like transparency and animation are already somewhat supported.

3. The href attribute should be set to point to an image of the appropriate type. There’s no longer a default. In fact, there’s not even a requirement that the icon be hosted on the same domain.

You can freely use both a favicon and a standard icon without worrying about making your site slower. Browsers are generally smart enough to automatically pick between the two as needed without having to download both. Usually you’d want the two versions to look fairly similar to one another, but that’s not a requirement.

The last topic I’ll mention (because its name and purpose are similar enough to cause confusion) is the somewhat related notion of domain picons. A picon is a personal icon, and a domain picon is a special icon you create that represents your entire domain. The details of how to make and use picons are clearly outside of the scope of this article, but the most important facts are that:

1. Picons don’t generally get used within your site — they get used in other places that refer to your domain in some way. For example, many forums, e-mail & news clients, mailing lists, and similar entities display domain picons with each message appropriate to the originating domain. (Locally in Massachusetts two examples that use picons include ShellTown's online mail system and Saugus' forums.)

2. There’s a global master repository of picons maintained at the Indiana University called the “Picons Archive”. Forums and other similar sites that make use of picons typically synchronize their local picon databases with this master copy periodically. Everyone is allowed to submit new picons for their own sites to this repository.

3. Picons are 48×48 images provided in both monochrome (in XBM format) and indexed color versions (in at least XPM format but also usually GIF).

4. As a consequence of #1, you can (and probably should) make a picon in addition to your other icon(s) in order to preserve your own site branding, and it normally makes sense to make your picon look like your other icon(s).

5. As another consequence of #1, providing a picon doesn’t make your site any slower to download.

That’s enough to get you started. If there’s enough interest I’ll perhaps write a little in the future on creating multi-icon favicons and/or creating picons.