Apple's new not-quite-favicon syntax causing problems in other browsers | Hacker News Reader

Apple's new not-quite-favicon syntax causing problems in other browsers

lists.w3.org

144 pointstbassetto48 comments

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.

Is it my flawed impression or this could be avoided rather neatly with a <link rel="tabbed-icon" thing?

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.

To be fair, WhatWG does say in https://html.spec.whatwg.org/multipage/semantics.html#rel-ic...

« 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)

> If there are multiple equally appropriate icons

In this case, the icons are specified that they are equally appropriate but they really aren't.

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/2...

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.

Interesting.

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.

Apple's documentation [0] says to use black:

> 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

[0] https://developer.apple.com/library/prerelease/mac/releaseno... (ctrl+f pinned tabs)

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.

An apple dev actually replied and said you can use other colours but because its interpreted as a mask, non-black makes the result translucent.

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."

Probably just you. I found it detailed and clear.

Pretty standard fare for mailing lists.

And clearly they were aware it could cause problems and tried to avoid them.

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.

Ohh. So that's why Twitter's tab icon turned black.

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.

[1] https://about.twitter.com/company/brand-assets

On what device?

Firefox 38.0.5 / Linux x86_64

Firefox on Windows.

It's showing fine for me (Firefox on Windows 7)

The worst is that Safari needs a new type of favicon disrupting other web browsers but still doesn't display standards favicons natively.

I am not sure what you mean. Safari shows favicons of sites I visit?

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.

Precisely, I'm in the same boat. And while I've seen workarounds (like http://include.aorcsik.com/2014/12/04/add-favicons-to-safari...) I really don't want to have to add SIMBL extensions just to get something every other browser already does. :(

If it is there for pinned sites, why not add it for all of them?

Ah! Yes, I hate that too! Thanks for clarifying.

Everyone who read this has now given more thought to this issue than Safari's developers seem to have.

Typical for apple I have spent days trying to sort out the NTP fiasco that apple introduced in mavericks.

Networked macs lose connection to the OSx Server as clocks drift apart and kerberos authentication fails

Why is NTP so hard for a proprietary OS? I have never had a problem on Linux, while on Windows I can't remember seeing NTP ever actually work.

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.

Why are Twitter, Yelp, and Pinterest implementing this when it clearly causes problems?

So they could be demoed in the WWDC keynote.

And break it for existing actual users. Brilliant.

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.

Here's the proposal they meant to send out prior to the announcement, which explains the rationale: https://lists.w3.org/Archives/Public/public-whatwg-archive/2...

So why exactly can't Safari just use Favicon's for pinned tabs like everyone else? Gotta love standards.

It does work with standard favicon, this is to extend it.

Embrace, extend, extinguish? I thought that was Microsoft...

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?

Is there any automated tool that would catch a visual-only issue with a favicon that doesn't throw any errors or warnings?

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.

Reply on news.ycombinator.com