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 [mailto:whatwg-boun...@lists.whatwg.org] On Behalf Of Jonas Sicking Sent: dinsdag 29 juli 2014 23:22 To: Anne van Kesteren Cc: WHATWG 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 <ann...@annevk.nl> 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: https://bugzilla.mozilla.org/show_bug.cgi?id=921014 > > > -- > http://annevankesteren.nl/
