<link rel=icon> needs a way to specify CSS pixels (or DPI)

[CendioOssman]

This note of the spec needs to be addressed at some point:

An icon that is 50 CSS pixels wide intended for displays with a device pixel density of two device pixels per CSS pixel (2x, 192dpi) would have a width of 100 raw pixels. This feature does not support indicating that a different resource is to be used for small high-resolution icons vs large low-resolution icons (e.g. 50×50 2x vs 100×100 1x).

This is becoming a problem as browsers have started using the icons for other things than the classical 16x16 format. So as a page author do I design my 64x64 icon with lots of detail expecting it to be shown in a large format on a low resolution display? Or with few details so it will be recognizable in a low format on a high resolution display?

[annevk]

This is addressed with the sizes attribute. That way you can specify multiple icons. The user agent will pick the one suitable for the UI.

[CendioOssman]

I'm afraid it's not. As the note states sizes is in raw pixels, but there is no way to specify any physical dimension (e.g. CSS pixels). In short the sizes attribute is ambiguous what use the icon is designed for.

[annevk]

@CendioOssman in what scenario do you need to distinguish between 50x50 2x and 100x100 1x?

[domenic]

/cc @marcoscaceres as I believe web app manifest used to have this distinction and removed it.

[marcoscaceres]

Indeed. The concept of density is really hard for authors to get right so we had to yank support for it (it was so often wrong, and at such large scale, that it was doing more harm than good!).

Although the use case for discriminating on density is valid, 2x and 3x density displays are increasingly becoming the norm (so 1x, where this makes sense, is no longer super relevant). As such, with manifest, we concluded that treating images sizes as "raw" pixels is best, and just let the UA pick the best one to show.

[CendioOssman]

@CendioOssman in what scenario do you need to distinguish between 50x50 2x and 100x100 1x?

Whenever there is complexity to the icon that needs to be adjusted for small sizes (i.e. often). E.g. look at the calculator icon from GNOME's default theme:

vs

As you can see the number of buttons have been reduced and the rounding as been exaggerated in the smaller picture in order to make it easy to identify. And this is an issue of physical size, not pixels.

As you scale up you can see this trend continuing:

https://gitlab.gnome.org/GNOME/adwaita-icon-theme/blob/master/src/fullcolor/legacy/accessories-calculator.svg

[CendioOssman]

Although the use case for discriminating on density is valid, 2x and 3x density displays are increasingly becoming the norm (so 1x, where this makes sense, is no longer super relevant). As such, with manifest, we concluded that treating images sizes as "raw" pixels is best, and just let the UA pick the best one to show.

I'm afraid I'll have to disagree with you on that one. :)

2x and up may be dominant on phones, but I have a hard time believing that is the case for PCs. I'd be very surprised if they are even a majority there.

And even if that was the case, the issue is similar (if not the same) if you need to design for 2x and 4x at the same time. And we have lots of devices in both of those categories.

The ideal scenario IMO would be the ability to specify multiple SVG, each with a different physical dimension specified.

[annevk]

The calculator example is somewhat compelling. It might be good for someone to do some research on why we ended up without density for sizes (prolly "link sizes inurl:whatwg").

[marcoscaceres]

I think it’s just that sizes predates retina displays.

FWIW, we did do a lot of research as part of manifest. What we found is that beyond 2x it doesn’t matter. People can’t really distinguish pixels beyond 2x, so at that point SVG or just a large image is better.

[annevk]

That would depend on the viewing distance, no? 2x vs 3x vs 4x seems relevant for VR at least, and potentially desktop monitors too. And given the trend in phones it likely matters there too.

Per https://lists.w3.org/Archives/Public/public-whatwg-archive/2008May/0071.html it does indeed seem that density was not yet a consideration.

[domenic]

Given how rel=icon and the manifest feed into the same processing model in most implementations, I think if we want to solve this, we should make sure we have parity across both the manifest and the link tag representations.

As for whether we want to, I'm unsure. It seems at least we'd need to do something different this time around if we're to avoid just going through the same cycle manifest did and removing it after implementations notice that respecting the parameter gives bad results. I don't know what we could do though.

[annevk]

I'm somewhat surprised by that conclusion for manifests given it's far from widely deployed thus far and <picture> and srcset do have density. @marcoscaceres can you point to the issue and PR surrounding the removal?

[CendioOssman]

Perhaps an even more tangible example would help. The main problem is that right now you have to chose between two bad options:

Either you design for low density displays, ignoring high density ones.
This gives you this small icon on high density displays:
When we would have preferred this small icon:

Alternatively you design for high density displays, ignoring low density ones.
This gives you this large icon on low density displays:
When we would have preferred this large icon:

This problem is caused by the fact that in all cases the icon uses the exact same tag:

<link rel="icon" sizes="64x64" type="image/png" href="example.png">

[marcoscaceres]

@CendioOssman, thanks for the example. I'm completely sympathetic to the use case, and why I had added density to manifest in the first place.

@annevk, please see: w3c/manifest#450
There are links from there to further discussions.

Most of the background research I did into this dates back to 2013, and presented here:
http://w3c-webmob.github.io/installable-webapps/#icons

And:
https://groups.google.com/d/msg/mozilla.dev.webapps/WBWsaP87IRk/tqccLEcNMF8J
(Don't read past the first few posts. The thread veers off course and hits a dumpster fire.)

Another good articulation of the problem can be found here:
http://bjango.com/articles/designingforretina2/

There are other great articles from a few years back discussing this problem... but I think it's only a problem for icons smaller than about 48x48px. Above that, IIRC, it's possible to use SVG without significant issues ^{[citation needed]}.

I'm still of the opinion that this is somewhat of an edge case... but if we can come up with a neat solution, I'm supportive of aligning HTML and Manifest (again).

[CendioOssman]

It's been a couple of years. Anything new in this space? :)

[mm201]

Maybe you could have <link rel="small icon"> (same syntax as rel="icon") where the developer can provide a less detailed icon if they so desire? Existing UAs would always choose the more detailed version which is the safe choice.

[CendioOssman]

FYI, reference to the current discussion in Firefox on how to handle icon sizes:

https://bugzilla.mozilla.org/show_bug.cgi?id=854956

[CendioOssman]

There is another problem with the lack of density information, and that is the overall "weight" of the icon. Historically, 16x16 icons have ignored the weight issue and filled out the available space completely. Larger icons, however, tend to make sure every icon has similar weight. That means that a square icon has more padding around it than a round icon.

Failure to specify density means that a designer will again be unable to produce icons that work everywhere. Either you design for the small use case, which means the icon will be overly large if used in a launcher. Or you design for the large use, which means the icon will be overly small when used on a tab.