There is a discussion on the mail thread about how to deal with this issue properly. This is for a preview version of Safari and this is not the final specification.
Seems silly. They should just use a new rel value for this specific purpose. Although broadly speaking it feels like the icon rel has had its day, and now we need a replacement that is DESIGNED to support multiple resolutions, and things like masks.
« If multiple icons are provided, the user agent must select the most appropriate icon according to the type, media, and sizes attributes. If there are multiple equally appropriate icons, user agents must use the last one declared in tree order at the time that the user agent collected the list of icons. »
(edit for formatting)
In this case, the icons are specified that they are equally appropriate but they really aren't.
From: Maciej Stachowiak <firstname.lastname@example.org>
Date: Mon, 15 Jun 2015 12:00:59 -0700
> On Jun 15, 2015, at 3:27 AM, Anne van Kesteren <email@example.com> wrote:
> On Mon, Jun 15, 2015 at 12:18 PM, Kornel Lesiński <firstname.lastname@example.org> 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.
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.
Perhaps the problem is the use of SVG. SVG requires specifying a colour, yet it's going to be discarded by the browser. Maybe what's needed is a proper mask format? Some subset of SVG? If that were used, then browsers which don't support it would naturally skip it, whereas currently browsers which don't support the masking display the SVG with the colour it specified.
Furthermore, SVG supports masking already: http://www.w3.org/TR/SVG/masking.html#Masking – although the use of black there would mean transparent, not opaque. Wouldn't be terribly bad to align the feature with the spec in that regard, though. As far as I understood it, the intended result is essentially a single-colour image, masked by the given SVG.
> You can set the icon that the user sees when they pin your site by providing a vector image. Use 100% black for all vectors with a transparent background in SVG format
 https://developer.apple.com/library/prerelease/mac/releaseno... (ctrl+f pinned tabs)
Mandating that it also has to be black seems like it would eliminate most existing favicons.
I would've preferred something more direct and to-the-point, perhaps an "oops, we didn't consider that it would conflict with existing browser behaviour; we'll move to a different rel."
If it is there for pinned sites, why not add it for all of them?
Networked macs lose connection to the OSx Server as clocks drift apart and kerberos authentication fails
It's certainly soured me on apple period I am recommending getting some nice dell i7 hexcore work stations.
But I never said anything about "automating" since even manual testing would be a QA improvement.