Intent to Implement and Ship: icon purposes in the Web Manifest

[pkot...@google.com]

Contact emails

pkot...@chromium.org, ha...@chromium.org, pe...@chromium.org, zp...@chromium.org

Spec

This is an addition to the Web Application Manifest, see:

https://www.w3.org/TR/appmanifest/#purpose-member

Summary

Add a "purpose" field to icons in a page's Web Manifest to enable websites to customize the default icon which shows up in the system tray for notifications shown by WebAPKs.

Sample Web Manifest

{
 "name": "News",
 "icons": [{
   "purpose": "badge",
   "sizes": "16x16",
   "src": "icons/badge.png",
 }, {

   "sizes": "144x144",
   "src": "icons/icon.png",
 }],
}

WebAPKs are lightweight APKs which act as bookmarks to web pages. WebAPKs are installed to the device when a user adds a page to the homescreen provided that the web page meets certain requirements. WebAPKs were presented at the Chrome Developer summit https://www.youtube.com/watch?v=YJwrBbze_Ec. WebAPKs are an experimental feature in Chrome and currently need to be enabled in Chrome via chrome://flags.

 
 

Customized notification status tray icon for https://tests.peter.sh/notification-generator/

Motivation

The badges displayed on a device's status bar are critical for attribution of the available notifications. Developers can already provide their own on Android M+ on a per-notification basis using https://www.chromestatus.com/features/5630897160192000, but Chrome's icon remains the default due to platform limitations.

This change will make it possible for a website to customize the system tray icon on Android J, K & L for WebAPKs only. This feature is limited to WebAPKs because WebAPKs are full fledged APKs. When a WebAPK is added to the homescreen, Chrome will select the icon to use for "notifications from the WebAPK" and will package it in the WebAPK's resources. When a user launches a WebAPK, Chrome will check whether the Web Manifest has changed and install an updated WebAPK if needed.

Interoperability and Compatibility Risk

There is very little interoperability risk. This feature is tied to WebAPKs. There is a plan to make non-Chrome browsers be able to install WebAPKs.

Adding this feature will not break any sites.

Ongoing technical constraints

None

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Android only, WebView excluded.

OWP launch tracking bug

http://crbug.com/649771

Link to entry on the feature dashboard

https://www.chromestatus.com/features/6690807302062080

Requesting approval to ship?

Yes. WebAPKs are an experimental feature. The use of the "purpose" field in the Web Manifest will be gated on the same flag in chrome://flags as WebAPKs. We are not planning anything special.

[Kenneth Rohde Christiansen]

Why is this limited to Android J, K & L and not enabled on newer versions, like M and N?

Kenneth

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[zp...@chromium.org]

On M+, web developers can provide the icon for notifications to use in the
status tray via the Notification.badge property
(https://notifications.spec.whatwg.org/#dom-notification-badge)

link to feature dashboard:

https://www.chromestatus.com/features/5630897160192000

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[Reilly Grant]

For consistency should the badge from the manifest provide a default for Notification.badge if not otherwise specified?

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Peter Kotwicz]

reillyg@: Yes, we can make the badge from manifest provide a default for Notification.badge

[Kenneth Rohde Christiansen]

That makes a lot of sense to me.

Kenneth

On Fri, Dec 9, 2016, 21:04 'Peter Kotwicz' via blink-dev <blin...@chromium.org> wrote:

reillyg@: Yes, we can make the badge from manifest provide a default for Notification.badge

--

[Mounir Lamouri]

It would be great if the badge from the Manifest was used as a default
for the Notifications API whenever the Notification code doesn't specify
one. Ideally, it should apply whenever the Manifest is used so for
WebAPKs but also traditional added to homescreen web applications (even
if that means M+ only).

Otherwise, the changes lgtm! Thank you for working on this :)

-- Mounir

[Rick Byers]

I see there's been quite a bit of discussion (including with Mozilla folks), eg. here.

LGTM1

Only partially related: I see a bunch of the examples use 'platform: "android"' but the only known platform on the Wiki is "play".  Can you please make sure the wiki is up-to-date wrt. what platform values Chrome on Android respects?

Thanks,

   Rick

On Sat, Dec 10, 2016 at 6:18 AM, Mounir Lamouri <mou...@lamouri.fr> wrote:

It would be great if the badge from the Manifest was used as a default
for the Notifications API whenever the Notification code doesn't specify
one. Ideally, it should apply whenever the Manifest is used so for
WebAPKs but also traditional added to homescreen web applications (even
if that means M+ only).

Otherwise, the changes lgtm! Thank you for working on this :)

-- Mounir

On Fri, 9 Dec 2016, at 21:45, Kenneth Rohde Christiansen wrote:
> That makes a lot of sense to me.
>
> Kenneth
>
> On Fri, Dec 9, 2016, 21:04 'Peter Kotwicz' via blink-dev <
> blin...@chromium.org> wrote:
>
> > reillyg@: Yes, we can make the badge from manifest provide a default for
> > Notification.badge
> >
> > --
> > You received this message because you are subscribed to the Google Groups
> > "blink-dev" group.
> > To unsubscribe from this group and stop receiving emails from it, send an

> > email to blink-dev+unsubscribe@chromium.org.

> >
>
> --
> You received this message because you are subscribed to the Google Groups
> "blink-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an

> email to blink-dev+unsubscribe@chromium.org.

[Peter Kotwicz]

Rick, thank you for pointing out the inconsistency in the documentation of the "platform" member. I will follow up to fix the inconsistency I think that the concern about the platform member is unrelated to the proposal to add support for the "purpose" member

Background: Chrome on Android does not support the "platform" member in the Web Manifest icons dictionary but it does for the related_applications dictionary. The folks from Mozilla have recently changed the "platform" attribute to be valid for both the "related_applications dictionary" and the "icons dictionary" We will write a separate intent-to-ship if we decide to add support for the "platform" member in the "icons" dictionary

[Rick Byers]

Thanks.  Yeah this is only related in that most of the examples I saw for purpose used platform also (since I guess the format/restrictions on the icon is likely to be OS-specific - eg. Android  notification badges should be a certain size with  no partial transparency).

[Kenneth Rohde Christiansen]

Actually, the spec allows the platform to represent a software distribution ecosystem or an operating system.

For related applications, "play" definitely makes sense, given there can be additional stores, which for instance is the case in PRC (China), but "android" might make more sense for the launcher icons, and developers might even be able to differentiate between the icon to show in Play Store (if it would list PWAs in the future) and what is shown on Android. You could even image a "gsearch" value in the future, or "bing".

Cheers

Kenneth

   Rick

> > email to blink-dev+...@chromium.org.

> >
>
> --
> You received this message because you are subscribed to the Google Groups
> "blink-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an

> email to blink-dev+...@chromium.org.

[Peter Kotwicz]

Kenneth I understand your point. I think that the spec should be clarified regardless of which values "platform" should take. For instance, if both "play" and "android" are valid values for the "platform" attribute https://github.com/w3c/manifest/wiki/Platforms should be updated.

Can you please file a bug in https://github.com/w3c/manifest in order to discuss how to best clarify the spec?

- Peter

   Rick

> > email to blink-dev+unsubscribe@chromium.org.

> >
>
> --
> You received this message because you are subscribed to the Google Groups
> "blink-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an

> email to blink-dev+unsubscribe@chromium.org.

[Dimitri]

LGTM2.

[Chris Harrelson]

LGTM3

On Thu, Dec 15, 2016 at 11:26 AM, Dimitri <dgla...@chromium.org> wrote:

LGTM2.

[Kenneth Rohde Christiansen]

We are not defining the exact values in the spec, but letting that up to browsers, platforms (stores, search etc). 

Chrome can decide whether it wants just "play" or a combination of "play", "android" or something else. Whatever makes the most sense for you. 

Of course, just make sure to document it well. We will probably keep the values in use documented in a wiki referred to by the spec (I think Marcos might have done that already).

Feel free to file an issue if you want some of this clarified better - we are open to input :) and I will make sure to comment.

Kenneth

   Rick

> > email to blink-dev+...@chromium.org.

> >
>
> --
> You received this message because you are subscribed to the Google Groups
> "blink-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an

> email to blink-dev+...@chromium.org.

[Rick Byers]

Yes that's what I was saying - the wiki page doesn't appear to reflect our current implementation.  IMHO we (Peter and other owners of the implementation in Chrome Android) should keep the wiki page up-to-date matching our implementation (NOT an issue for the spec / WG).

On Thu, Dec 15, 2016 at 6:06 PM, Kenneth Rohde Christiansen <kenneth.ch...@gmail.com> wrote:

We are not defining the exact values in the spec, but letting that up to browsers, platforms (stores, search etc). 

Chrome can decide whether it wants just "play" or a combination of "play", "android" or something else. Whatever makes the most sense for you. 

Of course, just make sure to document it well. We will probably keep the values in use documented in a wiki referred to by the spec (I think Marcos might have done that already).

Feel free to file an issue if you want some of this clarified better - we are open to input :) and I will make sure to comment.

Kenneth

On Thu, Dec 15, 2016, 20:18 Peter Kotwicz <pkot...@google.com> wrote:

Kenneth I understand your point. I think that the spec should be clarified regardless of which values "platform" should take. For instance, if both "play" and "android" are valid values for the "platform" attribute https://github.com/w3c/manifest/wiki/Platforms should be updated.

Can you please file a bug in https://github.com/w3c/manifest in order to discuss how to best clarify the spec?

- Peter

   Rick

> > email to blink-dev+unsubscribe@chromium.org.

> >
>
> --
> You received this message because you are subscribed to the Google Groups
> "blink-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an

> email to blink-dev+unsubscribe@chromium.org.

[Peter Kotwicz]

I have filed https://github.com/w3c/manifest/issues/538 about making the spec clearer

On Fri, Dec 16, 2016 at 12:04 PM, Rick Byers <rby...@chromium.org> wrote:

Yes that's what I was saying - the wiki page doesn't appear to reflect our current implementation.  IMHO we (Peter and other owners of the implementation in Chrome Android) should keep the wiki page up-to-date matching our implementation (NOT an issue for the spec / WG).

On Thu, Dec 15, 2016 at 6:06 PM, Kenneth Rohde Christiansen <kenneth.christiansen@gmail.com> wrote:

We are not defining the exact values in the spec, but letting that up to browsers, platforms (stores, search etc). 

Chrome can decide whether it wants just "play" or a combination of "play", "android" or something else. Whatever makes the most sense for you. 

Of course, just make sure to document it well. We will probably keep the values in use documented in a wiki referred to by the spec (I think Marcos might have done that already).

Feel free to file an issue if you want some of this clarified better - we are open to input :) and I will make sure to comment.

Kenneth

On Thu, Dec 15, 2016, 20:18 Peter Kotwicz <pkot...@google.com> wrote:

Kenneth I understand your point. I think that the spec should be clarified regardless of which values "platform" should take. For instance, if both "play" and "android" are valid values for the "platform" attribute https://github.com/w3c/manifest/wiki/Platforms should be updated.

Can you please file a bug in https://github.com/w3c/manifest in order to discuss how to best clarify the spec?

- Peter