Re: [w3c/manifest] Support different shortcut icon requirements/guidelines on different platforms (#795)

> Would the `badge` purpose be sufficient? It specifically leaves such flexibility as we have the same constraints in other UI surfaces:
> 
> > A user agent can present this icon where space constraints and/or color requirements differ from those of the application icon.

It looks like `purpose: badge` was added in #480. I'm not sure if any user agent is actually using `purpose: badge`, but it doesn't seem very useful to me in its currently specified state. The text of the spec is meaningless: what does "space constraints and/or color requirements differ" really mean? Without further guidance from us, a user agent could not make any assumptions about what it means to developers.

As an example, let's say there's a hypothetical platform where shortcut icons are supposed to be monochrome. Let's say that a user agent on that platform interprets "space constraints and/or color requirements differ" as "the color requirements are monochrome", so decides to prioritize `purpose: badge` icons for shortcuts on this platform, intending to receive monochrome images from the site. Now two scenarios can emerge:

1. Sites interpret "space constraints and/or color requirements differ" in another way, perhaps they use `purpose: badge` for much simpler icon designs, but still full-color. Thus, our hypothetical user agent isn't getting monochrome images from these sites.
2. The hypothetical user agent becomes so popular that sites realise if you put a monochrome icon in `purpose: badge`, it looks perfect on this platform. Any non-monochrome icon in `purpose: badge` looks very bad, so everybody stops doing it. Thus a de facto standard is created, governed by a single user agent's interpretation of vague spec language.

Either way, there is a mismatch between the spec text and the user agent interpretation. If we're going to define alternative purposes for icons, I think we should define very precisely the graphical expectations of that purpose, establishing a contract between sites and user agents, so that sites know how user agents may interpret the image data. `purpose: maskable` is a good example of this done right, very clearly establishing spatial rules about which pixels may be cropped by the user agent. I think we could define a `purpose: monochrome` which says that either the image must be monochrome, or the user agent is allowed to use the brightness of each pixel, ignoring the chromaticity of the pixels. The current `purpose: badge` I would like to remove if possible.

We might also need a `purpose: monochrome_maskable` (a combination thereof), or a way to define multiple purposes on an icon.

Also, @christianliebel :
> And/or should `ImageResource`’s `platform` member be evaluated for that scenario?

Whoa, I didn't actually know this existed, contrary to what I was saying above ("I want to avoid any ability for developers to supply an "iOS icon" and a "Windows icon", etc"). Ideally this usage would be discouraged, for the reason I gave above.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/manifest/issues/795#issuecomment-532950542