This very cordial downthread reply by an Apple engineer addresses that idea directly, and is open to it: From: Maciej Stachowiak <___@apple.com> Date: Mon

This very cordial downthread reply by an Apple engineer addresses that idea directly, and is open to it: From: Maciej Stachowiak <___@apple.com> Date: Mon, 15 Jun 2015 12:00:59 -0700 > On Jun 15, 2015, at 3:27 AM, Anne van Kesteren <annevk@annevk.nl> wrote: > > On Mon, Jun 15, 2015 at 12:18 PM, Kornel Lesiński <kornel@geekhood.net> wrote: >> The new Safari is still only a preview, so I hope Apple will switch to a better solution. > > It would be great if we could get some feedback from Ted & colleagues > on what the thinking here was. First: it looks like we neglected to send our proposal for this ahead of our preview release. It’s now been sent belatedly. We regret the error. Second: we’re definitely open to changing this if there’s consensus for a different syntax. Our original thinking on this: rel=icon is intended to support selection from multiple formats and sizes. It seemed natural to extend this to the notion of a monochrome icon that’s intended to be recolored. Before deploying the feature, we thought it would be cleaner to extend rel=icon than to invent a new rel value. (There’s already the legacy -apple-touch-icon value with in theory could be obsoleted by rel=icon with the appropriate size). For similar reasons, it seemed better to reuse the existing theme-color meta (which gives license to darken or lighten the color as needed). The nature of the problem: to avoid breaking the regular favicon, both in Safari and in other browsers, sites need to make their regular favicon explicit with a rel=icon link (instead of relying on favicon.ico), and need to put the mask icon first instead of last in the list of icon links. We thought clear advice to do this, plus the fact that breakage should be obvious, would limit the scope of the error and would lead sites to fix it promptly. That doesn’t seem to be happening, at least yet. We noticed this problem internally even before shipping (working with some sites to get mask icons up before release), but there was internal debate about whether the problem would shrink or grow over time. Where do we go from here: (1) We could add "mask" or something like it to the standard, and change browsers to ignore mask icons in contexts where they are looking for a regular icon. (2) We could change to a new rel type for mask icons, such as rel=mask-icon, but keep theme-color as the source of the color, with the possibility of darkening light colors used to make light colors viable. (3) We could change to a new rel type for mask icons, such as rel=mask-icon, and give it a color attribute to be used specifically for the icon. We don’t have a strong principle on this, and it’s not too late to change before shipping the release version of Safari 9. We welcome input on which of these would be best, or whether something else entirely is better. Sorry again for not bringing this up before the preview release that included this feature. Regards, Maciej https://lists.w3.org/Archives/Public/public-whatwg-archive/2015Jun/0020.html https://lists.w3.org/Archives/Public/public-whatwg-archive/2...