Open beverloo opened 9 years ago
FTR, it's not Manifest specific, it's coming from <link rel=icon>
. Manifest folks are plagiarists like that :scream:
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.
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?
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.
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.
I think this is missing two major points:
window
wouldn't be the right place.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:
So I'm tempted to drop this from the Notifications spec as well, and really the only thing to deduplicate is the Icon.
@mvano I think that's a reasonable alternative. An Icon object that you can feed to various places.
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?
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.
+1. From an implementation point of view it makes very little different whether we do it for one attribute or multiple.
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 :).
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:
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