I was looking into the same issue and learned that modern browsers now also support SVG images for favicons.
So far, this is what I've come up with -
<link rel="icon" href="data:image/svg+xml,%3csvg%3e %3c/svg%3e">Interesting solution! It shows at the "no favicon" image on the page tab (the dog-eared page icon) in the latest Chrome/Edge for me, not as a blank/clear icon. (I get that same result when I used GIFs that were invalid).
Thanks for letting me know. I probably have to tweak it a bit to make sure it's valid in all browsers.
While researching, I've found some fun things people have been doing using text and emojis in SVGs [0]
[0] https://lean8086.com/articles/using-an-emoji-as-favicon-with... [1] https://css-tricks.com/emojis-as-favicons/
Re:How We Got the Favicon (2017)
by ComputerGuru on Monday August 10, 2020 @05:08PM
(#24114009)
Check out small, it’s a collection of the smallest perfectly cromulent instance for common file types. The last time I saw it the repo was not being very actively maintained but had lots more samples filed as pull requests.
They come in handy more often than you’d think.
Yeah, Mathias and I already exchanged on this. (I know him from working on V8). The GIF in that repo doesn’t work as a favicon:
https://twitter.com/billticehurst/status/1288721150780964866...
Re:How We Got the Favicon (2017)
by eat_veggies on Monday August 10, 2020 @01:28PM
(#24111732)
You can also use:
<link rel="icon" href="data:,">I tried stuff like that. While it does remove the extra web request, the favicon that shows on the browser tab shows as the broken image/dog-eared page (at least in Chrome/Edge), not as a lack of a favicon (i.e. transparent image).
Very clever solution!
There should be a browser directive for this. It feels like we should be able to tell the browser no.
A favicon is historically associated with a site, rather than a page. If you look at it that way it seems wrong to attach an extra header to every HTTP request, rather than just incurring the overhead on the first visit to a site.
Of course you can now have a different favicon for every page, or update it dynamically, so that semantic argument is no longer as strong.
Good point. But then many (most?) sites these days don't use a favicon.ico file in the root, but point to a .png or similar via a header tag as shown in the article (e.g. "<link rel=”icon” href=”/path/to/icon.png”>"). That has the same 'semantic' issue of the favicon being specific to the page and not site.
Re:How We Got the Favicon (2017)
by theandrewbailey on Monday August 10, 2020 @01:43PM
(#24111897)
That works until you get crawled by totally broken crawlers that interpret data: URIs as a relative URL. (It's happened to me.)
Re:How We Got the Favicon (2017)
by adventured on Monday August 10, 2020 @02:00PM
(#24112095)
Why would that matter though? Crawlers of that low quality are almost guaranteed to be worthless for traffic purposes and should likely just be blocked as incorrectly functioning trash.
If interested in the format, I put a gist up at https://gist.github.com/billti/81d4b601c9022ba3655a3a03873ca... with the small node.js script I wrote to generate various examples. (You can see more examples and links in the comments in the top if interested).