A Crime Called Favicon
Post from May 9, 2019 (↻ May 29, 2021), filed under Web Development.
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.
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.
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.
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).
I’m Jens Oliver Meiert, and I’m an engineering manager and author. I’ve worked as a technical lead for Google, I’m close to the W3C and the WHATWG, and I write and review books for O’Reilly. Other than that, I love trying things, sometimes including philosophy, art, and adventure. Here on meiert.com I share some of my views and experiences.
If you have questions or suggestions about what I write, please leave a comment (if available) or a message.
Have a look at the most popular posts, possibly including:
- How Can We Make Website Maintenance Work More Visible?
- Understanding Image Compression: Tooling and Context
Looking for a way to comment? Comments have been disabled, unfortunately.
Perhaps my most comprehensive book: The Web Development Glossary (2020). With explanations and definitions for literally thousands of terms from Web Development and related fields, building on Wikipedia as well as the MDN Web Docs. Available at Apple Books, Kobo, Google Play Books, and Leanpub.