Supporting multiple image definitions for a Notification

[beverloo]

Currently Notifications support a single image to be defined, but on today's world of many different screen densities we may want to consider a syntax for multiple syntax.

My proposal is to adopt the Web Manifest's syntax for defining an icon size: http://w3c.github.io/manifest/#icons-member

This would look as follows:

registration.showNotification('My Notification', {
  body: 'Hello, world!',
  icon: '/legacy-icon.png',  // optional, only used as fall-back
  icons: [
    { src: '/icon-1x.png',
      type: 'image/png',
      density: 1 },
    { src: '/icon-2x.png',
      density: 2 },
    { src: 'icon.ico',
      sizes: '128x128 256x256' }
  ]
});

On a tangent, we may also want to consider some sort of "small icon", to be used when the platform displays such icons in a status bar. (E.g. my little flag man on Android -- we're going to show a generic Notification icon when shipping them.)

+@mounirlamouri

[mounirlamouri]

FTR, it's not Manifest specific, it's coming from <link rel=icon>. Manifest folks are plagiarists like that :scream:

[annevk]

Here is an alternative idea. Since it seems likely many more APIs going forward will want to show some kind of icon (we have two entry points for notifications here and one for media sessions per @foolip), perhaps we can come up with an API to determine the appropriate icon before feeding it to the final API.

That way we don't have to continue duplicating the API surface for each API that might need this.

[mvano]

The simplest thing would be to define an Icon interface and / or dictionary with src, type, and sizes in some lower level spec like HTML. What do you think?

[domenic]

I think @annevk's idea was something like

const chosenSrc = window.chooseImage([
    { src: '/icon-1x.png',
      type: 'image/png',
      density: 1 },
    { src: '/icon-2x.png',
      density: 2 },
    { src: 'icon.ico',
      sizes: '128x128 256x256' }
  ]);

which would return one of /icon-1x.png, /icon-2x.png, or icon.ico. No need for new classes like Icon. Then specs like this one would just take a string, instead of an array of objects.

[annevk]

Implementations might support different sizes for notifications and media session artwork and such, so it might require some kind of destination input as well. Not sure if that's a size we expose as a static somewhere or something else.

[mounirlamouri]

I think this is missing two major points:

• the image has a target size and the target size might not be known by the developer. For example, a Notification might have a small and large image, the size of the image will depend on the device, it's OS and the version of the OS.
• the image might be used in different devices which means that window wouldn't be the right place.

[mvano]

I really think exposing some kind of Icon interface / dictionary is the most urgent bit for reducing duplication.

As for the url selection algorithm, there are a few issues:

• The Manifest and Media Session specs don't have one and don't seem to want one.
• Url selection may be asynchronous so it's not possible to expose the selected url on anything that is returned synchronously.
• As Mounir pointed out, the implementation may want to use more than one of the provided icon sources in different rendering contexts.

So I'm tempted to drop this from the Notifications spec as well, and really the only thing to deduplicate is the Icon.

[annevk]

@mvano I think that's a reasonable alternative. An Icon object that you can feed to various places.

[coox]

Profane question from an enthusiastic visitor: am I right to assume that the proposal would also cover the badge use case?

If so, would it be preferred to open a separate issue tracking just multiple badge definitions?

[annevk]

I think we would apply it to all image fields. No need for a separate issue I think unless implementers want to tackle them one-by-one over time.

[beverloo]

+1. From an implementation point of view it makes very little different whether we do it for one attribute or multiple.

[beverloo]

The Web App Manifest now exposes an ImageResource type, which would be great for this purpose. We're currently moving Background Fetch to use it, and I'd be happy to enable this for the Notification API too :).