A Crime Called Favicon

Published on May 9, 2019 (↻ June 14, 2024), filed under Development (RSS feed for all categories).

At sum.cumo we have just opened a larger investigation into the current situation and best practices with respect to favicons (including bookmark and desktop icons). I knew the situation was bad, but it’s much worse.

On the surface the favicon situation looks simple: A site or app is to provide a couple of icons that user agents can use for address bar, bookmarks, home screen, system tiles, &c.

The reality is that it’s totally obscure what user agents use what icons for what use cases for whatever probability to occur.

Like a taste? Top-ranking results recommend, at least mention, the following sizes alone, which I’ll list in one paragraph so that you don’t have to scroll for half an hour:

16×16, 30×30, 32×32, 48×48, 57×57, 60×60, 64×64, 70×70, 72×72, 76×76, 90×90, 96×96, 114×114, 120×120, 128×128, 144×144, 150×150, 152×152, 160×160, 167×167, 180×180, 192×192, 195×195, 196×196, 228×228, 256×256, 270×270, 310×150, 310×310, 558×270, 558×558.

These are 31 “icon” sizes. Anecdotally, this isn’t the end of it—a colleague had just evaluated a tooling option that generated 45 icons.

This whole situation around favicons is completely out of control.

Worse: No one knows anything. It’s all guesswork, there are no data: What user agents need what icons? What icons do they support? For what purposes are the icons actually used? How probable is each use case; how many users actually bookmark, save to desktop, or take other actions involving favicons? What are the fallbacks in each case when there is no icon, is it acceptable, is it not? &c. pp.

Therefore, the situation around favicons is not only totally out of control, the technical solutions (for an icon!) are actually so embarrassingly overdone that when looking at it all, it’s an insult to any breathing person with just a handful of functioning synapses.

The ideal situation, my wish, is that we, our field, define and push for a simple standard: a favicon.svg (with browsers falling back to favicon.png and then favicon.ico) that sits at respective site root and is not required to be referenced from the markup. That sketch, to be defined further, would keep it simple for maintainability and HTML best practices, so that sites and app can provide an icon, one icon, that user agents can use as an all-purpose symbol for that site or app. [The HTML spec so far starts off promising but ends up contributing to the dilemma.]

At sum.cumo we’re looking closer at the situation at least for our clients, and have some ideas. I personally urge that we don’t accept this mess anymore, this giant technical failure we have all ignored for years by concealing our blindness with tooling that generates tons of images and tons of markup for, what. Favicons in the year 2019 are a disgrace. Let’s do something about it.

Prince Valiant looks at his tiny queen in dismay. Dionseus, as leader of the revolt, deserves hanging; instead Aleta merely exiles him, provides a ship to go away in and allows her sister to go with him!

Figure: What would you do. (Copyright King Features Syndicate, Inc., distr. Bulls.)

Update (July 9, 2019)

A problem description and some suggestions are now on file with the WHATWG: Rephrase icon section (to help curb icon proliferation).

About Me

Jens Oliver Meiert, on November 9, 2024.

I’m Jens (long: Jens Oliver Meiert), and I’m a frontend engineering leader and tech author/publisher. I’ve worked as a technical lead for companies like Google and as an engineering manager for companies like Miro, I’m a contributor to several web standards, and I write and review books for O’Reilly and Frontend Dogma.

I love trying things, not only in web development (and engineering management), but also in other areas like philosophy. Here on meiert.com I share some of my experiences and views. (Please be critical, interpret charitably, and give feedback.)