A Crime Called Favicon
Post from May 9, 2019 (↻ July 22, 2019), 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 than I thought.
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 that are however likely to occur at all.
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 just 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 must for once mean an insult to any breathing person that has 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).
About the Author
Jens Oliver Meiert is a technical lead and author (sum.cumo, W3C, O’Reilly). He loves trying things, including in the realms of philosophy, art, and adventure. Here on meiert.com he shares and generalizes and exaggerates some of his thoughts and experiences.
If you have any thoughts or questions (or recommendations) about what he writes, leave a comment 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
Perhaps my most relevant book: CSS Optimization Basics (2018). Writing CSS is a craft. As craftspeople we strive to write high quality CSS. In CSS Optimization Basics I lay out the, at least some of the most important aspects of such CSS.
Looking for a way to comment? Comments have been disabled, unfortunately.