Drop density descriptor from spec

[marcoscaceres]

There seems to be a lot of confusion about how to properly use the density member. It was designed to support discriminating against the user's screen: that is to say, if the end-user screen greater than or equal to X, then use this icon.

When we started this effort a few years ago, this use case was driven by iOS developers that were having to create specific icons for 1x and 2x - not only for performance, but because 2x icons were getting scaled incorrectly in 1x displays. However, this is a bit of an edge case nowadays because most phones have +2x displays.

Because of misuse and confusion around this feature, we are seeing a lot that is using density as a descriptor of the icon instead. E.g., a 36x36 pixel icon is "0.75"... which doesn't make any sense. Anyway, this gets worst for larger icons, where some developers have specified things like "density": "4" - where those icons would be fine to use on a 2x density display.

As such, I propose we drop density from the spec.

@mounirlamouri, @kenchris, @RobDolinMS, @boyofgreen, wdyt?

[andreasbovens]

I agree. The density descriptor serves too much of a niche use case, and is more confusing than valuable, in my opinion.

[boyofgreen]

at manifoldjs we see very few devs using this. I know one of the generation tools will insert this in for you, but generally I see it left out. Likewise, I don't see "types" used often by developers, as it's normally determined by the extension type of the image.
My vote would be to drop it.

[domenic]

Doesn't removing this break parity with <picture>/<img srcset>?

[RobDolinMS]

Discussing with @seksenov and @boyofgreen ...

[marcoscaceres]

Doesn't removing this break parity with <picture>/<img srcset>?

A little, yes. But the use case is a little bit different and I think it would be better we address this now, rather than having to change the semantics of the member (its current usage is meaningless to the UA, so we'd have to ignore it in practice).

If later people start asking for this feature, we can add it back in once more developers understand its utility (and why it was there in the first place).

[mounirlamouri]

Chrome actually uses density but we got a lot of issues with websites over using it. Unfortunately, it seems to all boil down to some early examples using density for all images in the Manifest. I have to say that I've never met anyone who actually understood density without me explaining :)

[marcoscaceres]

@kenchris or @mounirlamouri, I've sent a patch to have this removed from Gecko:
https://bugzilla.mozilla.org/show_bug.cgi?id=1264813

Can you do the same on the Blink side pretty please 🍒.

[mounirlamouri]

Opened a bug: https://crbug.com/603848

[mounirlamouri]

FTR, Chrome dropped support for 'density'. It will no longer be used in Chrome 52.

[mgiuca]

Cross-linking this here because I was having a hard time finding this: this has been re-discussed over on #118, and there are two reasons to not reverse this decision:

1. It's confusing for developers and quite subtle (the difference between 32x32@2x and 64x64@1x, for example), and in most cases there won't be a difference between the "large" and "high-density" versions of an icon.
2. The "density" namespace is "poisoned" by existing manifests that implemented this incorrectly, so we would have to spec something different (and the same thing might happen again, since this is so confusing).