icon density should be supported

[marcoscaceres]

Although discriminating on pixel density plays a big role in determining which icon to choose for a particular context, there are other factors that could come into play. In HTML, this is solved by the link element's media attribute.

I'm going to drop density and in a future version we can add a media attribute to the icon member to allow discrimination using media queries. It's possible to determine which icon to use solely by using the sizes attribute - though it does not handle more advanced use cases where one has the same size icons created for different DPRs.

[kenchris]

Sounds good to me... I wasn't a big fan of it anyway

[mrdewitt]

I'm surprised that this has been dropped. What's the motivation for explicitly not supporting known use cases? Icons are one of those things that are important to get pixel-perfect for a polished app and that's not possible without specifying the scale factor at which an icon was designed (or at least a particular representation for an icon). In particular, a representation designed for 1x at 100x100 may not be the same pixels as one designed for 2x at 50x50dip.

[marcoscaceres]

@mrdewitt I strongly agree. We just dropped it from V1 to try to make sure we could get more support from implementers. Simpler spec seemed easier to sell. We also need this on the Moz side. I'm happy to add it back, but want an ok from other implementers.

[marcoscaceres]

(Marking as V2 feature for now)

[sicking]

Is this something that's supported by the <meta> icon features? If so I think we can safely assume that implementations are willing to implement.

I wouldn't want any implementations or any web authors avoid implementing/using the manifest and instead to go with due to lack of support for high-density icons.

[marcoscaceres]

The HTML spec uses sizes and media attributes and says sizes represent absolute pixel values (meaning that the UA has to divide by the DRP to find the right icon).

So, something like:

<link rel="icon" href="hi-def.ico" sizes="32x32 64x64" media="all and (min-device-pixel-ratio: 2)">
<link rel="icon" href="lo-def.ico" sizes="16x16 32x32">

However, no one implements support for media on icons, so in reality this doesn't actually work.

[marcoscaceres]

I have also documented what different UAs do with icons here (bit rough, but good enough):
http://w3c-webmob.github.io/installable-webapps/#icons

[mrdewitt]

Are there any known use cases in which media queries would be necessary to achieve good results? "density" seems like the simple/straightforward approach.

[marcoscaceres]

Not that I can think of. I think resurrecting the density member should be sufficient.

[owencm]

Resurrecting this - in terms of vendor interest, there is a team in Chrome that would like this feature for selecting icons for our New Tab Page.

Specifically, they worry about some products that change their icon depending on the size it's to be displayed, so a 512x512 icon on a dense phone should be different to that on a low resolution computer.

Have there been more discussions about ways to support this (either by resurrecting "density") or by a more comprehensive approach?

[marcoscaceres]

We would need to redesign this in such a way that it get some protection from being accidentally poisoned by tooling in the wild (a WordPress plugin accidentally poisoned this on scale last time).

[mgiuca]

@marcoscaceres What do you mean by "poisoned"?

So is the issue basically that people are confused by the difference between size and density? I agree, it is very confusing. Basically you could have a 32x32 icon base size. Then you could also have:

• A 64x64 icon, which is twice as large.
• A 32x32 icon at "2x" density, which is the same size but twice as dense as the base icon.

Both of these assets would be 64x64 pixel images, and in many (most?) cases they would in fact be the same image. But they have a subtle semantic difference that is the former is intended to be displayed larger on screen, so the former may contain more detail while the latter contains less.

Generalizing this, you realise that an "icon" is actually a 2D array of images, with size along one axis and density along the other. Is this the model that was originally provided by "density" in the manifest spec? I think providing a facility to supply both different sizes and different densities of the same icon is potentially too niche; almost all icons are going to look the same in "large size" as they do in "high DPI", so only a single axis (that we already provide in the manifest) is sufficient.

@owencm

Specifically, they worry about some products that change their icon depending on the size it's to be displayed, so a 512x512 icon on a dense phone should be different to that on a low resolution computer.

Is there any case where it's inappropriate to just use a larger icon size on the dense phone? A 512x512 icon seems a bit extreme on a low-res PC (taking up half the screen). Perhaps a more realistic example is what I've given above: a site specifies a 32x32 icon and a 64x64 icon in its manifest. It needs to be displayed in a (logically) 32x32 square. On the standard-res PC, we just use the 32x32 asset. Is there any reason why we can't just use the 64x64 asset on the high-DPI phone, in the logically-32x32 square? Do we need to let the site specify a separate 32x32 high-DPI asset?

[marcoscaceres]

@marcoscaceres What do you mean by "poisoned"?

Most instances included the wrong value (e.g., "density": "4"), making the value so unreliable that only the lowest quality icon could be used, even though all the icons would have been perfectly suited for the task.

size and density?

A bit, yes. They think "this is the density that I designed it at" ... not, "please only display this at, or above, this density".

Both of these assets would be 64x64 pixel images, and in many (most?) cases they would in fact be the same image. But they have a subtle semantic difference that is the former is intended to be displayed larger on screen, so the former may contain more detail while the latter contains less.

Yep - that's the bit people sometimes don't grasp... so, we figured single density is going away anyway on mobile... and anything over 3x really doesn't matter. In which case, just treat everything as 1x and use "real pixels" to do the conversion for density (i.e., I'm on 2x, so I'll only grab anything 64x64 and above).

The case where developers would make custom icons for single density and double density is rare (although nice when it happens)... but most people don't notice such tiny details, so in the end it doesn't really matter.

almost all icons are going to look the same in "large size" as they do in "high DPI", so only a single axis (that we already provide in the manifest) is sufficient.

Yeah, that's the conclusion we reached originally.

[mgiuca]

Yep - that's the bit people sometimes don't grasp...

And let me be clear this is not an easy thing to grasp. I don't blame developers for being confused about this.

but most people don't notice such tiny details, so in the end it doesn't really matter.

I think possibly the legitimate case here is where it isn't a variation in detail, but actually a different concept at different logical sizes. For example, a company might just use the first letter of its brand name as the logo for "small" sized icons, but use the full word for "large" sized icons. The 64x64 version might be the full word whereas the 32x32x2 version might be a high-res (64x64) image of the first letter.

Still, I'd assume this is rare and my feeling is that you made the right decision to remove the density axis, and just use large size icons in place of high density.

[kenchris]

Wouldn't it be better to add tests for the icons inside DevTools pointing out that icons are missing for new tab page etc? or even make it part of the lighthouse tests?

[marcoscaceres]

That might be very noisy. I imagine very few developers will end up running lighthouse or looking in devtools at all (specially folks depending on CMS - which remember lead us here).

[kenchris]

I don't think it will be noisy - you will have to go to the right pane inside the devtools to see it - not talking about spamming the console here :-) But the CMS thing is very valid - but we will help some by making this part of devtools, ie educate devs who then later write articles and the like.

[mgiuca]

Wishing a big 10th anniversary to this on-again-off-again issue! 🎉

Aaaaannd... I'd like to reopen it again. This has come up again and I think it's time we finally addressed it. It's impossible for a web app to add the final layer of polish without being able to create icons of different levels of detail for different sizes. You practically can't do that today because it means the user will see different detail levels depending on their DPI, so practically a web app can only use the same icon at different resolutions.

It looks like it was dropped in 2017 because websites in the wild were abusing the density parameter for the wrong purpose (search above and in #450 for "poison"). Maybe in the six years since then, it's become rare enough that we can restore it, or maybe we just use a different name.

[marcoscaceres]

Yeah, we might be ok to resurrect it. I wonder if we know anyone that could maybe query HTTP Archive and check?

I guess if this is implemented by at least one browser, developers will be able to see the effects more obviously.

@mgiuca, what's are folks wanting to target? I guess most screens are 2x nowadays? So maybe also 3x?

[khalyomede]

Hello everybody 👋

I follow the repository since a few days (after having done a deep dive in the Manifest W3C document).

I just read the comments and I would like to ask if you guys think the CSS resolution media query would allow developpers to achieve this (assuming the manifest is updated to support the media attribute - is there any issue about it I can reference?)

"icons": [
  {
    "src": "img/logo-48-1x.png",
    "sizes": "48x48",
    "media": "@media (min-resolution: 1dpi)",
    "type": "image/png"
  },{
    "src": "img/logo-48-2x.png",
    "sizes": "48x48",
    "media": "@media (min-resolution: 360dpi)"
    "type": "image/png"
  }
]

N.B.: Not sure if intended, but the MDN documentation for the icons attribute seems to give an example of usage for the density attribute, is it legit?

"icons": [
  {
    "src": "icon/lowres.webp",
    "sizes": "48x48",
    "type": "image/webp"
  },{
    "src": "icon/lowres",
    "sizes": "48x48"
  },{
    "src": "icon/hd_hi.ico",
    "sizes": "72x72 96x96 128x128 256x256"
  },{
    "src": "icon/hd_hi.svg",
    "sizes": "72x72",
    "density": 2
  }]

[marcoscaceres]

Yeah, we've gone back and forth a ton over the years about using media queries for similar things (see #1045) ... the challenge is always that the icons are thrown over the fence to the OS, which doesn't know about media queries, so that puts us in a challenging position: we end up having to potentially describe a small subset of allowed media queries, which could be translated to whatever the OS understands... or we are explicit ("density: X").

There are ton of pros and cons to each approach. I'm thinking we should just do "density" for simplicity.

[marcoscaceres]

Not sure if intended, but the MDN documentation for the icons attribute seems to give an example of usage for the density attribute, is it legit?

Probably just a left over from when we had density specified.