Before you get your pitchforks out: this is a better start for the discussion than the apple-touch-icon mess from the past. They attempted to extend the standard in an almost intended way, but it turns out that it was not really ever considered well enough for this.
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.
That was my thought as well. Why needlessly create the tag collision? It's especially inelegant that Apple suggests defining the tag twice for the sake of other browsers.
I think the suggested solution of 'ignore <link> tags that have a "mask" attribute' also creates needless work, and is backward-incompatible --- existing browsers are looking for "rel=icon" for a favicon, and will ignore "mask" or other unknown attributes.
Exactly. New tags should "fail safe" in old browsers (i.e. do "nothing"). The problem with the mask attribute and "only render the last one" concept is that older browsers might not be doing so already, and therefore the new tag doesn't fail safe (it is fail-active, so older browsers might render solid black favicons).
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. »
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.
Option 4 is that if the icon links are in the wrong order Safari should also break. That would force developers to put them in the right order and not break other browsers.
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.
Technically SVG doesn't require a colour. In absence of a fill colour renderers will render shapes in black anyway.
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.
It seems like the intent here was that someone like Twitter would provide a blue bird icon in SVG, and then specify that it is also suitable for use as a mask by providing the "mask" attribute. That icon could be used both for normal favicons and for this mask. Instead Twitter provided a black bird.
> 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
Interesting, since their proposal says: "A simple author opt-in saying that an icon is suitable would help UAs pick the right icon to download and, unlike the sizes and type attributes, there's no need for a complicated attribute value microsyntax."
Mandating that it also has to be black seems like it would eliminate most existing favicons.
Especially since it would have been easy for the browser to derive an all-black mask from any image. Then sites only have to do extra work in order to support the new functionality, as opposed to what we see here where they have to do extra work in order not to break.
Is it just me, or does anyone else feel that style of writing rubs them the wrong way...? It seems excessively verbose and vague.
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."
I wouldn't say it's a "new" syntax as much as it's an experimental syntax (at least according to the Apple dev stating the reason for the choice in the pre-release version and explaining that they're not committed to the new syntax for the release version [https://lists.w3.org/Archives/Public/public-whatwg-archive/2...). I'd be surprised if it makes it into Safari's released version, and will hold my outrage until then.
Yeah I thought it was ironic that Twitter switched to black favicon given their logo guidelines [1] specifically say to never change the color of the logo.
In the bookmarks bar, no favicons show up. This is the major reason I can't switch to Safari: most of my bookmarks bar items have no label in Chrome, I just visually recognize their favicons and that's sufficient.
Windows implements SNTP. The goal is to keep the clock within tolerance for Kerberos (5 minutes). It's embarrassingly bad but they don't seem to have any real reason to fix it. Also the w32tm code is ... bad.
At least NTP works on windows I have been trying to migrate a small 15 mac office to use networked users - because of the changes apple made to NTP all the networked macs lose sync after a couple of hours and crash quite often screwing up the outlook database.
It's certainly soured me on apple period I am recommending getting some nice dell i7 hexcore work stations.
Worse they are implementing it incorrectly. Apparently placing a normal favicon tag after the Apple one would fix the issue and Apple suggests doing so.
Golly gee, web development sure seems to be getting complicated. Do you think there will ever be tools that can test web pages against a diversity of browsers in order to catch this sort of problem before it hits production?
Maybe an Apple intern could sit in front of a computer that runs ImageMagick's compare utility. However, it stands to reason that Apple would be left with a choice between hiring two interns and not having an intern write their production code. Or maybe Apple could have the intern work on automating a visual testing process so that builds break when they break other browsers.
But I never said anything about "automating" since even manual testing would be a QA improvement.
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.