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

> The idea behind the `badge` purpose is that it's an icon that can be used in space constraint locations like the address bar and device status bar, where the exact appearance (display size, overlay colour, maybe on top of a circular surface) may not always be well defined, or known at all. In other words, a clear, generic icon that is mendable in regards to colour. I agree that the prose can use refinement.

OK, that description does match what I had in mind for this. I think we could use `purpose: badge`.

But there needs to be _some_ guidelines as to how it will be interpreted by the user agent. Otherwise you don't know what you're designing against. Ideally, the designer doesn't need to take any platform-specific design criteria into account (if they do, then we will find sites that are biased towards one particular platform to the detriment of others).

For example, you say "maybe on top of a circular surface"; well, we have a precise definition of "maybe on top of a circular surface" in [Icon masks and safe zone](https://www.w3.org/TR/appmanifest/#icon-masks). So if "badge" referred to that, designers would have a clear idea of which parts of the icon _may_ be cropped out.

Similarly, for colour: it seems that some "badge" contexts (e.g., Android app icon shortcuts) are expected, but not required, to have all non-transparent pixels as the same colour, matching the app's theme colour, and [this colour should contrast well with light grey](https://commondatastorage.googleapis.com/androiddevelopers/shareables/design/app-shortcuts-design-guidelines.pdf). Other contexts, such as the Android system bar, have the icon be all white on a transparent background. If you look at other platforms, there will be different guidelines. Maybe some platform will say the colour must contrast with black; then the foreground colour you choose will be quite different.

Now, we don't want to ask web developers to develop against the Android guidelines, or the Windows guidelines, etc. We want to clearly specify our own very specific guidelines, then have user agents map that onto the individual platform. For example, we say "it must be greyscale with no transparency, where the background is black and the foreground is white, and also the maskable safe zone applies". Then on Android, to map it to the status bar, we convert luma into alpha, setting all non-transparent pixels to white. To map it to a shortcut icon, we do the same but set all non-transparent pixels to the app's theme colour, possibly darkening so it contrasts well with light grey. On another platform, we can map it onto a different colour scheme to fit the platform's guidelines and contrast requirements. This way, nobody is thinking about Android or Windows, they're just targeting our platform.

The worst case scenario I can imagine is we just say "use `purpose: badge`" to developers, and then user agents just take the `purpose: badge` icon and put it in the shortcut menu without modification. Then developers targeting Android realise that they need to conform to the [Android shortcut icon guidelines](https://commondatastorage.googleapis.com/androiddevelopers/shareables/design/app-shortcuts-design-guidelines.pdf) in order to look good, and now those icons can't be used properly on other platforms.

> While I appreciate the goal of being able to precise how everything will be used, because some of these graphics will be handed off to the underlying operating system that isn't always an option across OS versions and flavours (e.g. Android OEMs). ... As a concrete example, on Android users are free to install a launcher of their choice that may decide to do something different. Browsers cannot hardcode the configuration of each possible launcher.

I disagree. While the browser doesn't know exactly what launcher the user has installed, or other OEM-specific details, the browser does know exactly as much as any other native app providing icons (which is to say: a lot more than what the web developer knows, since they don't even know what OS they're on). The web developer can't follow the OS icon guidelines. The browser can manipulate a generic "web icon guideline" icon into an image that follows the OS icon guidelines (e.g., the [Android icon guidelines](https://commondatastorage.googleapis.com/androiddevelopers/shareables/design/app-shortcuts-design-guidelines.pdf)). Thus, our web apps will be presenting the same quality of icons as any native app. From there, the individual OEM changes to the OS need to uphold their end of the OS-specific icon contracts (e.g., if an Android OEM places icons that follow the Android icon guidelines onto a black background, then our browser-generated icons and all other native app icons will look bad).

Again, `purpose: maskable` is a good example of this in action. Our Android implementation of Maskable doesn't take the icon from the manifest and cut it into a circle, or a squircle, or a teardrop, etc. The browser doesn't know what the OEM or user-specific icon mask shape is. Instead, we take the icon that matches the Manifest standard, and add padding so that it matches the Android icon sizing requirements, and then we give it to the OS, and from there, some unknown masking happens to the icon. We don't care what that masking is, because we did our job, which is to produce something conforming to the Android OS guidelines.

-- 
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-532972770