Given that the /favicon.ico fallback is really only there for IE5/6/7 
compatibility to my knowledge, and final support for the last of those 
realistically ended 3 months ago along with Windows XP, I'd be all for 
deprecating that in upcoming revisions of the standards. Vendors can then 
decide for themselves how long they will keep supporting it based on  actual 
usage, as newly developed sites will all be using the more structured methods 
with finer grained control.

It makes sense to have both the <link> and manifest routes, since the first 
saves bandwidth and a request if you don't need the added value of a manifest. 
The /favicon.ico fallback on the other hand just promotes laziness.

As for the touch icons I'd recommend the same sane route - have a single well 
defined usable standard like <link sizes>, and allow vendors to keep supporting 
the crapple proprietary syntax during a transitional period as they see fit, 
and practical usage of it within their audience. Any syntax with a company name 
in there shouldn't be polluting recommendations by definition.

-----Original Message-----
From: whatwg [] On Behalf Of Jonas Sicking
Sent: dinsdag 29 juli 2014 23:22
To: Anne van Kesteren
Subject: Re: [whatwg] apple-touch-icon

I'd really like to avoid sticking this in specs. We already have 3 ways of 
adding icons, /favicon.ico, <link rel=icon> and <link rel=manifest>. That's 
probably about 2 too many. We shouldn't add a 4th one. Generally speaking, 
eventually I think manifests is what will encourage the best UX and the easiest 
syntax for authors.

Given that both Blink and Gecko is adding support reluctantly and is planning 
to remove support, adding it to the spec will make this deprecation harder. At 
the very least, if it's added to the spec, add very clear language about it 
being deprecated.

/ Jonas

On Sun, Jul 27, 2014 at 5:13 AM, Anne van Kesteren <> wrote:
> For <link rel=icon> we already define the /favicon.ico fallback. If a 
> page lacks <link rel=icon sizes> we should probably also look at 
> Apple's proprietary extension here given that it's quite widely 
> adopted. Chrome supports it and there is some work going on in Firefox 
> as well:
> --

Reply via email to