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