Not really. The Windows icon format .ico did "responsive design" before the term was even coined. It supports multiple sizes and bit depths (remember Windows used to have to support everything from 1-bit to 24-bit colour) stored within a single file.
> There's no way of in-lining the icon (e.g. for single page applications, appliances, etc).
Huh? <link rel="shortcut icon"> works with data: URIs just like everything else. For example, my personal site uses one: http://ajf.me/
Source code:
<link rel="shortcut icon" href="data:image/x-icon;base64,AAABAAEAEBACAAEAAQCwAAAAFgAAACgAAAAQAAAAIAAAAAEAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA////AP//AAD+fwAA/38AAP9/AADFbwAAuW8AAL1vAADBbwAA/W8AAL1vAADDQwAA/+8AAP9vAAD/8wAA//8AAP//AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA">
This is mostly true, but I guess they wanted to avoid scaling up 16x16 favicons into a blurry mess on iOS, so made icons specially tailored for the iOS homescreen into their own category.
> They can be used to trick less technical users into believing a HTTP site is a HTTPS one. For example make the favicon a green padlock. This is mostly a browser issue, and may be resolved by marking all HTTP sites as insecure (which some have proposed).
This could be solved in future by allowing them only for HTTPS sites :D
Ooh... this would be a good first step in gradually introducing marking all HTTP connections as insecure, similar to how Chrome is gradually deprecating SHA-1 certificates:
(1) Stop showing favicons for HTTP connections
(2) Start showing a cautionary icon (perhaps a yellow triangle containing an exclamation point) for HTTP sites and self-signed HTTPS sites
(3) Start showing a scarier looking warning for HTTP sites, but leave a cautionary warning for self-signed certs
(4) Start showing a cautionary icon for connections not using perfect forward secrecy
With Ed25519, Curve25519 and ChaCha20, the computational overhead for perfect forward secrecy has come down significantly.
Now if only we had a good standard for in-browser support of one or more password-authenticated key-agreement (PAKE)[1] algorithms for password input fields so that websites never held passwords. (This could be done via adding an extra attribute to the password input tag, so older browsers would submit the password, and newer browsers would perform PAKE verification.)
Hey, a guy can dream.
[1] https://en.wikipedia.org/wiki/Password-authenticated_key_agr...
Vista introduced dumping pngs directly into icos[1].
I think Apple went this route to avoid having to download the ico as it contains multiple images and is hence quite a bit larger than the e.g. single 57x57 png you are looking for.
http://en.wikipedia.org/wiki/Base64 http://en.wikipedia.org/wiki/Data_URI_scheme
Remember, that favicon is an icon for the list of favorites (IE's term for bookmarks) -- that was the original use of them, although if you are referring to having the icon next to the URL in the URL bar, that I can agree with -- that can be mostly pointless. Although some tabbed browsers make good use of them, by having them in the tabs themselves. Makes it real easy to see which tab belongs to which website.
Somebody should have told the team responsible for the Windows 7 start menu, where the items in the right-hand column have no icons until you're already pointing at them (and pause a moment) at which point they pointlessly draw attention away with a giant icon in a different place on the screen.
Edit: Chrome. I read further down that Safari is no longer showing them in the tab bar.
The <link rel="icon" href="./whatever.ico" /> was a further improvement still on the basic concept a year later.
The only concerns I've heard about favicon is:
- They've grown beyond the original use case (e.g. address bar, tabs, drag to desktop/app tray, etc).
- The icon definition hasn't expanded with its new scope, so specifying low, medium, and high definition formats is left up to server hacks (i.e. providing the right one based on the browser user agent string).
- There's no way of in-lining the icon (e.g. for single page applications, appliances, etc).
- Apple now has their own incompatible favicon "apple-touch-icon" which is just a higher resolution favicon.
- They can be used to trick less technical users into believing a HTTP site is a HTTPS one. For example make the favicon a green padlock. This is mostly a browser issue, and may be resolved by marking all HTTP sites as insecure (which some have proposed).
To be honest all of these could be fixed with some subtle changes to the ref="icon" definition to support a quality modifier, and also being able to point at an in-line graphic object for the favicon.
The last point requires us to mark HTTP as insecure. Instead we treat HTTPS CA signed as "secure" and HTTPS self-signed as "insecure" when the reality is that HTTPS self-signed is more secure than plain old HTTP (yes, I know, you can MITM self-signed, but at least it is encrypted).