How We Got the Favicon (2017) | Hacker News Reader

How We Got the Favicon (2017)

thehistoryoftheweb.com

146 pointssimonpure64 comments

When I'm testing locally with a trivial site, those favicon 404 requests bugged me when checking the log. I'm also a little bit obsessive about keeping my pages small. This resulted in me going down a rabbit hole of the GIF spec to see the smallest inline blank favicon I could create. I ended up with:

  <link rel="icon" href="data:image/gif;base64,R0lGODlhEAAQAAAAACwAAAAAAQABAAACASgAOw==">

Putting that small line in my HEAD tag gets rid of those annoying extra requests, and results in no favicon (it's just a totally transparent image).

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).

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.

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).

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/

That works until you get crawled by totally broken crawlers that interpret data: URIs as a relative URL. (It's happened to me.)

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.

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.

https://github.com/mathiasbynens/small

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...

I've never heard the definitive story of how autocomplete got added to the URL bar, but it might've been a particular route from Emacs...

I was talking with a manager for one of the Web browsers in '96, and mentioned a little Emacs add-on, https://www.neilvandyke.org/webjump/ , which combined Emacs autocompletion with a bunch of arbitrary site-specific code to be a smart hotlist/bookmarks/search/etc. for Web browsers. The manager suddenly ignored everything else we were talking about, which I thought was more important, and drilled down into this little Emacs curiosity. Next thing I knew, completion was added to their browser's URL bar (but not the other things WebJump did).

The autocompletion wasn't my invention (it might've been Emacs's, decades earlier), of course, and a lot of people knew about it, including via noted Emacs hacker JWZ famously at Netscape, so there are numerous other paths it could've coincidentally gotten into browsers. I'd just be slightly tickled if that one conversation happened to be the prompt for someone's effort to add it.

When people went through or analyzed their Web logs, bandwidth was expensive, and a page load was often 1 small HTML request plus maybe a GIF/JPEG or 3... the addition of these favicon requests was annoying. Also, Microsoft was widely disliked by Internet people, so this didn't help.

Another funny thing about the favicons... Sun had a template that a lot of people ended up copying, but the file format contained multiple resolutions. So it wasn't that unusual to see a Sun favicon logo on a site that wasn't Sun, because some site developer or Webmaster used Sun's template, replaced only the one for the resolution they used, so it looked good to them.

I've always been deeply annoyed by the name "favicon," which as the article notes has its roots in the "favorites" list.

No, Microsoft, when I marked this page for later, that doesn't make it my favorite. Maybe I'm researching political enemies, or have a "favorites" folder of "software companies I can't stand"

Between this and the "My Computer" icon from Windows 95, I have a deep and abiding hatred of whomever was in charge of naming things at Microsoft in the nineties.

C:\Documents and Settings\Lammy\

Yeeesss, let's just add an extra 25 characters to our user's root directory. Oh and also add capitals and spaces to it, within a system that typically hates those.

My totally baseless assumption is that it was a cute passive way to force developers to properly support UNC Paths of all types by making something as essential as %USERPROFILE% include spaces and intentionally break all the eight-dot-three conventions.

A nice thing about the initial ico-format is that it can contain multiple resolutions. Nowadays you will see multi-res using separate files but that took a long time to happen.

You can set the shortcut icon meta tag to point to a fairly big (256x256) png file, and all modern browsers will re-scale it for use where-ever needed.

The only place where I've seen multiple sizes needed was for SPAs on mobile phones etc. and that's a whole different set of tags.

Sometimes you want more control over the low-res result than a re-scale will give.

Use SVG with CSS media queries.

At the scales we're taking about, bitmap image is both faster and smaller than equivalent SVG & CSS with media queries.

Indeed, I think ICO is the only common-use format to support that (I guess JPEG "sort of" does support it but not in any usable multi-resolution way).

Mipmaps are common in video game graphics format though!

macOS's .icns files (typically used for app icons) can (and usually do) also store multiple resolutions in a single file.

> common-use format

Pretty much nothing outside the apple ecosystem supports .icns

I believe that with svg, you can have multiple breakpoints and style rules depending on canvas size.

> it was not at all unusual to see browser makers experiment with new features and ideas in the hopes of gaining some sort of advantage

Another feature introduced this way was AJAX in IE 5.0, specifically the XMLHttpRequest JavaScript object.

It’s funny how the whole modern web 2.0 was enabled by an obscure feature. For the initial few years only Microsoft’s own products used that. It was implemented for Outlook web access, a component of their Exchange server that allows users to access their e-mails and relevant stuff without Outlook installed.

Then google found about it, made gmail.com, the rest is history.

There were other interfaces too - RSExecute should have worked with IE3+ and NN3+ [1].

And XMLHTTP while shipped quickly was hardly accidental. MSXML was Microsofts big push for XML, it was always meant to fetch data without page reload (XML data islands in IE4). And it was ActiveX component which was bringing Microsoft to the Web strategy.

Another famous ActiveX-based software - Flash.

[1] https://daurril.org/wrox/ASPToday/990930-191.htm

One of the more interesting techniques we used for finding phishing websites was to start indexing the favicons. Since then we've used them for lots of other cool things and I'm always surprised when people don't know what they are. They can also be used to provide a somewhat different perspective of what the Internet looks like:

https://faviconmap.shodan.io/

> Incidentally, you’d be surprised just how many relatively major browser features have snuck their way into releases like this.

I don't think I would! Explains a lot about the nightmares of web development.

Early on, it was a race between the browsers to differentiate themselves with proprietary extensions, and to be "this site best viewed with ___" (a very common saying on Web pages, and sometimes with image badges provided by the browser vendor).

W3C reined that in, and the W3C staff people are the real deal. Though eventually big browser vendors were able to push through whatever they wanted, maybe sometimes sabotage things they don't like (e.g, HTML5 Offline mechanisms competing with browser vendor's app store), etc.

"this site best viewed with ___"

Amazingly, this still happens today.

I run into it occasionally. Most recently over the weekend on a county voter registration web site which stated that Internet Explorer was "required."

When you call $company support about anything related to their web applicaations, one of the first questions they're instructed to ask is "what browser are you using? X? Have you tried using Chrome instead?"

9/10 (maybe 99/100) times, the issue has nothing to do with the browser, but these questions have a strong normalizing effect. Even if the browser has nothing to do with it, people who don't know better will stick to Chrome, "just to be safe".

I see it often too, and most of the time, that sentence ends with Chrome. Chrome is truly the IE of our era.

And explains XmlHttpRequest, also from Microsoft.

still the only way to do requests with progress bars

They had to sneak that one into IE through the MSXML library.

http://web.archive.org/web/20070210004825/http://www.alexhop...

You mean XMLHttpRequest. The two acronyms are capitalized differently for added quality.

I loled

I started using XmlHttpRequest immediately when I saw it documented somewhere at MS, probably MSDN. It was before google used it for auto-complete, and before I'd seen it being used anywhere, in fact. I'm sure other small pockets of developers were using it, but sites like StackOverflow, HackerNews, Twitter, etc didn't really exist to share such things. Slashdot was around, but I never saw it discussed there.

My team was blown away when I delivered pages that dynamically changed with fresh data without the user having to interact with it, and without page refreshes or auto-refreshed iframes. Of course it only worked in IE but that was OK.

The server-side data format I chose was XML since that was in vogue.

You could even do that before XmlHttpRequest, and on non-MS browsers. But it was unusual for anyone to bother.

People mostly didn't think of it until XHR became popular.

Uh, how?

There was RSExecute, claimed to work with IE3+ and NN3+.

IE4 implemented XML Data Islands with Java Applets, anyone could do it.

MSXML XMLHTTP was ActiveX component, as was one of the crossorigin tools - Flash, anyone could do it.

I have to check JSONP support.

> anyone could do it

Plugins like flash and java applets were non-starters for many enterprises.

XML Data Islands, as I recall, did not do any network requests. They were chunks of XML. Anyone could not do network requests with XML Data Islands.

RSExecute... I looked it up. Ok I stand corrected although it is not clear when that was released for IE.

JSONP? What? JSON did not exist back then. Are you trolling?

RSExecute: I've got Microsoft Scripting Libary 1.0a

Versions above are from the article [1].

XML Data Islands network requests:

    <OBJECT width=0 height=0
      classid="clsid:550dda30-0541-11d2-9ca9-0060b0ec3d39"
      id="xmldso">
    </OBJECT>
    <SCRIPT for=window event=onload>
      var doc = xmldso.XMLDocument;
      doc.load("books.xml");

JSONP: I've referred it as an idea of loading data in remote <script> callback.

>>>> You could even do that before XmlHttpRequest

MSXML is just a widely deployed ActiveX control, not part of the browser like favicon. Anyone could implement it or java applet.

[1] https://daurril.org/wrox/ASPToday/990930-191.htm

JSONP, or the iframe equivalent.

I know, you're thinking JSON didn't exist back then, I must be trolling.

I'm not, and it did!

JSON is short for "JavaScript Object Notation". With rare exceptions, it's valid JavaScript already! So JSONP only needs pure JavaScript, nothing else.

However, back then it wasnt necessary to use object notation at all. As it was returning a script to run, the script could just call functions directly instead of assembling an object.

Aside from JavaScript, people also used a Java applet or Flash to do the communication (faster than JSONP) as most browsers had at least one of those installed. Java and Flash could both be called from JavaScript.

A while later Mozilla added support for favicons to be any graphics format. When it went live in nightly builds, I immediately changed the favicon at MozillaNews to be an animated GIF, thus creating the world’s first animated favicon.

It’s interesting to read about how it actually happened, but it does seem like one of those inevitable features that would’ve been added sooner or later.

What do you consider inevitable about it? It feels like bookmarks are falling out of fashion, at least in that nobody looks at them in their traditional list format, and they are mostly useful for url bar autocompletion.

And I don't remember seeing favicons of random web sites in the URL bar, which is how they were otherwise prominently featured when introduced.

So if anything, I would say their existence was short-lived but their demise was inevitable ;)

More interesting feature that was introduced with IE (3 I think) was link hovering, and Netscape only caught up with 4.0 which took ages to come out. That has changed the accepted styling for hyperlinks forever and was the first instance of smooth non-JS "animations" in wide use!

Another interesting thing was the "active desktop" that came out with IE4 I think, though that never caught on. It was still fun to put a web page as your desktop background on NT4 which I used during that time before moving full time to GNU/Linux.

Favicons live on in the tab.

Not just live on, but are essential in navigation. I have so many open tabs that the favicon is the only differentiating thing between them. When I last tried to switch to FF from Chrome the lack of pre-cached favicons made all my bookmarks look like shit and I just couldn't stand it, so I bounced back.

Just closed and reopened FF 79 and all icons are right there where I have left them.

On Firefox, you could go to the Library and right click the Bookmarks folder, choose "Open all in tabs". It'll take a moment but all your icons should be fetched afterwards.

Good point — I stand corrected, thanks!

In Chrome, I like to remove the names of all the bookmarks in the bookmark bar to save space. It is just a row of icons for me.

I've kind of wondered what percentage of HTTP requests are requests for non-existant favicon.ico files.

It could be time for browser maintainers to start removing support for automatic favicon.ico requests, and fall back to simply supporting the meta tag.

This would break the favicon for direct image links, PDFs and automatic directory listings.

Well, the browser could just stop doing it for certain types of content.

It was an interesting time because IE actually broke a lot of new trails on the web by breaking standards and single-handedly adding features. Netscape, the more "standards-complaint" browser, lost out because of conformity.

thehistoryoftheweb.com is a cultural treasure and I'm very happy it's there. One thing that would make me like it more: if I could submit a pull request or two....

More Microsoft Suck

Reply on news.ycombinator.com