Intent to Implement and Ship: Notification Action Icons

[Michael van Ouwerkerk]

Contact emails

mvanou...@chromium.org

Spec

https://notifications.spec.whatwg.org/#action-icon-url

Summary

On some platforms the button rendered for a NotificationAction can display an icon. This change adds an optional icon url for notification actions.

As proposed and discussed in: https://github.com/whatwg/notifications/issues/59

Motivation

On platforms that support action icons they help convey the purpose of the action to the user. Not displaying an icon on such a platform may be viewed by users as an odd deviation from the platform style, or a bug. The Notifications API aims to enable a high-fidelity user experience that fits well into the underlying platform, even if not all features can be supported on all platforms.

Interoperability and Compatibility Risk

Low risk. Specifying an action icon is optional. Chrome will be the first browser to implement this feature. Mozilla expressed support for this feature in the spec discussion.

Ongoing technical constraints

None.

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

An icon url can be specified on all platforms where notifications are supported (currently Windows, Mac, Linux, ChromeOS and Android). Whether the icon will be displayed depends on the capabilities and UI style of the platform.

OWP launch tracking bug

https://crbug.com/585128

Link to entry on the feature dashboard

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

Requesting approval to ship?

Yes

[Domenic Denicola]

Will SVG be supported? The linked spec bug discusses the issue of how to provide multiple resolutions/densities, and that seems like an easy way to give authors the capability.

Will the alpha-channel "hack" discussed in the linked spec bug be used? I see it didn't make it into the spec. More generally, what platform-specific constraints will be imposed on the display of the icon, according to your current implementation and shipping plan?

[Mounir Lamouri]

What's the plan with regards to icon sizes? I can't see this being
discussed in the link you posted.

-- Mounir

On Mon, 8 Feb 2016, at 18:40, Domenic Denicola wrote:
> Will SVG be supported? The linked spec bug discusses the issue of how to
> provide multiple resolutions/densities, and that seems like an easy way
> to
> give authors the capability.
>
> Will the alpha-channel "hack" discussed in the linked spec bug be used? I
> see it didn't make it into the spec. More generally, what
> platform-specific
> constraints will be imposed on the display of the icon, according to your
> current implementation and shipping plan?
>
> On Monday, February 8, 2016 at 1:21:29 PM UTC-5, Michael van Ouwerkerk
> wrote:
> >
> > Contact emails
> >

> > mvanou...@chromium.org <javascript:>

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

[Michael van Ouwerkerk]

On Mon, Feb 8, 2016 at 6:40 PM, Domenic Denicola <d...@domenic.me> wrote:

Will SVG be supported? The linked spec bug discusses the issue of how to provide multiple resolutions/densities, and that seems like an easy way to give authors the capability.

We currently rely on ImageDecoder which supports jpeg, png, gif, webp, ico, and bmp. Rendering svg would be a non-trivial addition, especially for service workers running in the background, because most of the rendering pipeline is not initialized in that state.

I think it's more likely we'll move in the direction of using multiple bitmap definitions: https://github.com/whatwg/notifications/issues/28

 

Will the alpha-channel "hack" discussed in the linked spec bug be used? I see it didn't make it into the spec. More generally, what platform-specific constraints will be imposed on the display of the icon, according to your current implementation and shipping plan?

On Android a color filter is applied to the alpha channel for the Material theme, using color #757575. The spec does contain a note on the possibility that platforms may modify the icon before display (search for "Some platforms may modify an action icon resource"). In addition, there is a maximum size limit, and overly large images are downsized before passing them to the platform, to preserve memory.

[Michael van Ouwerkerk]

On Mon, Feb 8, 2016 at 11:35 PM, Mounir Lamouri <mou...@lamouri.fr> wrote:

What's the plan with regards to icon sizes? I can't see this being
discussed in the link you posted.

It is referred to in the link I posted, it's issue 28: https://github.com/whatwg/notifications/issues/28

I think we can treat resolving issue 28 as an incremental improvement. It affects things other than action icons as well.

[Peter Beverloo]

On Tue, Feb 9, 2016 at 12:32 PM, 'Michael van Ouwerkerk' via blink-dev <blin...@chromium.org> wrote:

On Mon, Feb 8, 2016 at 6:40 PM, Domenic Denicola <d...@domenic.me> wrote:

Will SVG be supported? The linked spec bug discusses the issue of how to provide multiple resolutions/densities, and that seems like an easy way to give authors the capability.

We currently rely on ImageDecoder which supports jpeg, png, gif, webp, ico, and bmp. Rendering svg would be a non-trivial addition, especially for service workers running in the background, because most of the rendering pipeline is not initialized in that state.

For further reference, support for SVG icons is pretty much dependent on https://code.google.com/p/chromium/issues/detail?id=294179.

Thanks,

Peter

[Nico Weber]

On Tue, Feb 9, 2016 at 8:33 AM, 'Michael van Ouwerkerk' via blink-dev <blin...@chromium.org> wrote:

On Mon, Feb 8, 2016 at 11:35 PM, Mounir Lamouri <mou...@lamouri.fr> wrote:

What's the plan with regards to icon sizes? I can't see this being
discussed in the link you posted.

It is referred to in the link I posted, it's issue 28: https://github.com/whatwg/notifications/issues/28

I think we can treat resolving issue 28 as an incremental improvement. It affects things other than action icons as well.

Given how many different resolutions devices in the wild have today, I don't think it's a good idea to ship anything new that supports only a single bitmap across all supported form factors.

[Michael van Ouwerkerk]

On Tue, Feb 9, 2016 at 8:11 PM, Nico Weber <tha...@chromium.org> wrote:

On Tue, Feb 9, 2016 at 8:33 AM, 'Michael van Ouwerkerk' via blink-dev <blin...@chromium.org> wrote:

On Mon, Feb 8, 2016 at 11:35 PM, Mounir Lamouri <mou...@lamouri.fr> wrote:

What's the plan with regards to icon sizes? I can't see this being
discussed in the link you posted.

It is referred to in the link I posted, it's issue 28: https://github.com/whatwg/notifications/issues/28

I think we can treat resolving issue 28 as an incremental improvement. It affects things other than action icons as well.

Given how many different resolutions devices in the wild have today, I don't think it's a good idea to ship anything new that supports only a single bitmap across all supported form factors.

Do keep in mind that the Notifications API already has an identical way of specifying a general icon for a notification: https://notifications.spec.whatwg.org/#icon-url

The solution proposed in issue 28 [1] builds on top of this in a compatible way, for all the places where one might specify an icon.

There is currently developer demand for action buttons, but frequently this is blocked on our lack of icon support. Considering the existing precedent in the Notifications API and the proposed and compatible solution, I don't think we need to block incremental improvements here.

[1] https://github.com/whatwg/notifications/issues/28

[Mounir Lamouri]

On Tue, 9 Feb 2016, at 13:33, Michael van Ouwerkerk wrote:
> On Mon, Feb 8, 2016 at 11:35 PM, Mounir Lamouri <mou...@lamouri.fr>
> wrote:
>
> > What's the plan with regards to icon sizes? I can't see this being
> > discussed in the link you posted.
> >
>
> It is referred to in the link I posted, it's issue 28:
> https://github.com/whatwg/notifications/issues/28
>
> I think we can treat resolving issue 28 as an incremental improvement. It
> affects things other than action icons as well.

Incremental improvement sgtm. Sorry for missing the link!

-- Mounir

[Philip Jägenstedt]

I agree that this sounds like a useful incremental improvement. SVG support would be great, but judging by the SVG favicon bug it looks uncertain how much work this would be or if there's anyone prepared to take it on right now.

If SVG support is left for later, would there any way to feature detect support once it is added?

Philip

[Mounir Lamouri]

On Tue, 16 Feb 2016, at 17:40, Philip Jägenstedt wrote:
> On Thu, Feb 11, 2016 at 9:16 AM, Mounir Lamouri <mou...@lamouri.fr>
> wrote:
> > On Tue, 9 Feb 2016, at 13:33, Michael van Ouwerkerk wrote:
> >> On Mon, Feb 8, 2016 at 11:35 PM, Mounir Lamouri <mou...@lamouri.fr>
> >> wrote:
> >>
> >> > What's the plan with regards to icon sizes? I can't see this being
> >> > discussed in the link you posted.
> >> >
> >>
> >> It is referred to in the link I posted, it's issue 28:
> >> https://github.com/whatwg/notifications/issues/28
> >>
> >> I think we can treat resolving issue 28 as an incremental improvement. It
> >> affects things other than action icons as well.
> >
> > Incremental improvement sgtm. Sorry for missing the link!
>
> I agree that this sounds like a useful incremental improvement. SVG
> support
> would be great, but judging by the SVG favicon bug

> <https://code.google.com/p/chromium/issues/detail?id=294179#c26> it looks

> uncertain how much work this would be or if there's anyone prepared to
> take
> it on right now.
>
> If SVG support is left for later, would there any way to feature detect
> support once it is added?

FWIW, by incremental improvement, I did not mean SVG but a way to
specify multiple icons by re-using the format the Manifest file created
[1]. Marcos Caceres and I did some research when we designed the
Manifest format and vectorial images is unfortunately not the right
solution for pixel perfect icons, especially for small sized icons.

[1] https://w3c.github.io/manifest/#icons-member

-- Mounir

[Chris Harrelson]

LGTM1

[Dimitri Glazkov]

LGTM2.

Domenic, the problem of rendering SVG favicons and action icons seems pretty hard, and something that needs to be spec'd more generally (not in the scope of Notifications). What would be a good place to file a spec bug for this?

:DG<

[Philip Jägenstedt]

LGTM3

I think the problem can be characterized as "URLs to images to be used in UI outside the control of the page" which can and does mean a different process. In this category we have favicons, notifications, and we will also have the same problem for Media Session once artwork is supported.

Support for SVG and a way to detect that support would be great, but it doesn't seem reasonable to block anything on it.

[Domenic Denicola]

From: dgla...@google.com [mailto:dgla...@google.com] On Behalf Of Dimitri Glazkov

> Domenic, the problem of rendering SVG favicons and action icons seems pretty hard, and something that needs to be spec'd more generally (not in the scope of Notifications). What would be a good place to file a spec bug for this?

Hmm, it would depend on what you mean exactly. My understanding is that specs like HTML and Notifications don't generally require UAs to support any particular image (or video, or audio) codecs. Are you thinking we should change that?

[Dimitri Glazkov]

Well.. SVG is not an image codec. It's a language, which has a whole bunch of platform and security implications. Right?

:DG<

 

[Fredrik Söderquist]

If speccing if needed, then maybe as part of the integration spec: https://svgwg.org/specs/integration/ ?

/fs

[Dimitri Glazkov]

This seems \o/

:DG<

[Domenic Denicola]

From: dgla...@google.com [mailto:dgla...@google.com] On Behalf Of Dimitri Glazkov
>

> On Tue, Feb 16, 2016 at 2:08 PM, Fredrik Söderquist <mailto:f...@opera.com> wrote:
>>
>> If speccing if needed, then maybe as part of the integration spec: https://svgwg.org/specs/integration/ ?
>
> This seems \o/

Agreed, this is perfect. I had spent ten minutes investigating various related things ("does <img> execute script?" etc.) when this document came in to show people had done it all before:).

Filed https://github.com/whatwg/html/issues/702 to track having HTML reference that appropriately.

[Philip Jägenstedt]

This intent has its LGTMs, but I have another question. We focused a lot on SVG and agreed that shouldn't block, but SVG supports wouldn't actually be a replacement for multiple image definitions, as not every icon is vector graphics and some icons will inevitable be tweaked to pixel perfection.

Is the notifications team (if that's a thing) also planning to take on that problem? One could survive for a long time without it, but the obvious risk is that people would either use images that are way bigger than necessary, or do some silly platform sniffing to guess how big is big enough.

[Michael van Ouwerkerk]

On Wed, Feb 17, 2016 at 10:22 AM, Philip Jägenstedt <phi...@opera.com> wrote:

This intent has its LGTMs, but I have another question. We focused a lot on SVG and agreed that shouldn't block, but SVG supports wouldn't actually be a replacement for multiple image definitions, as not every icon is vector graphics and some icons will inevitable be tweaked to pixel perfection.

Is the notifications team (if that's a thing) also planning to take on that problem? One could survive for a long time without it, but the obvious risk is that people would either use images that are way bigger than necessary, or do some silly platform sniffing to guess how big is big enough.

The push notifications team does want to address this issue, and has been looking at this from before. Might be something for the next milestone.

Regards,

Michael

[Michael van Ouwerkerk]

I think there will be no need to feature detect svg support, one just provides an svg icon, and the proposed solution will handle this gracefully. The proposal for multiple image definitions in issue 28 [1] would allow for a size [2] of "any" which is defined [3] as "The any keyword represents that the resource contains a scalable icon, e.g. as provided by an SVG image."

If the browser supports svg icons, it may use that icon definition, if it is considered the most appropriate one.

[1] https://github.com/whatwg/notifications/issues/28

[2] https://w3c.github.io/manifest/#sizes-member

[3] https://html.spec.whatwg.org/#attr-link-sizes-any

 

Philip

[Philip Jägenstedt]

On Wed, Feb 17, 2016 at 5:41 PM, Michael van Ouwerkerk <mvanou...@chromium.org> wrote:

On Wed, Feb 17, 2016 at 10:22 AM, Philip Jägenstedt <phi...@opera.com> wrote:

This intent has its LGTMs, but I have another question. We focused a lot on SVG and agreed that shouldn't block, but SVG supports wouldn't actually be a replacement for multiple image definitions, as not every icon is vector graphics and some icons will inevitable be tweaked to pixel perfection.

Is the notifications team (if that's a thing) also planning to take on that problem? One could survive for a long time without it, but the obvious risk is that people would either use images that are way bigger than necessary, or do some silly platform sniffing to guess how big is big enough.

The push notifications team does want to address this issue, and has been looking at this from before. Might be something for the next milestone.

Sounds good, looking forward to that!

(Media Session will hopefully also be able to make use of this mechanism, and there the difference in size between the maximum and minimum size required across platforms is likely even bigger, and so the potential bandwidth savings greater.)

Philip 

[Philip Jägenstedt]

On Wed, Feb 17, 2016 at 5:52 PM, Michael van Ouwerkerk <mvanou...@google.com> wrote:

On Tue, Feb 16, 2016 at 5:40 PM, Philip Jägenstedt <phi...@opera.com> wrote:

On Thu, Feb 11, 2016 at 9:16 AM, Mounir Lamouri <mou...@lamouri.fr> wrote:
> On Tue, 9 Feb 2016, at 13:33, Michael van Ouwerkerk wrote:
>> On Mon, Feb 8, 2016 at 11:35 PM, Mounir Lamouri <mou...@lamouri.fr>
>> wrote:
>>
>> > What's the plan with regards to icon sizes? I can't see this being
>> > discussed in the link you posted.
>> >
>>
>> It is referred to in the link I posted, it's issue 28:
>> https://github.com/whatwg/notifications/issues/28
>>
>> I think we can treat resolving issue 28 as an incremental improvement. It
>> affects things other than action icons as well.
>
> Incremental improvement sgtm. Sorry for missing the link!

I agree that this sounds like a useful incremental improvement. SVG support would be great, but judging by the SVG favicon bug it looks uncertain how much work this would be or if there's anyone prepared to take it on right now.

If SVG support is left for later, would there any way to feature detect support once it is added?

I think there will be no need to feature detect svg support, one just provides an svg icon, and the proposed solution will handle this gracefully. The proposal for multiple image definitions in issue 28 [1] would allow for a size [2] of "any" which is defined [3] as "The any keyword represents that the resource contains a scalable icon, e.g. as provided by an SVG image."

If the browser supports svg icons, it may use that icon definition, if it is considered the most appropriate one.

[1] https://github.com/whatwg/notifications/issues/28

[2] https://w3c.github.io/manifest/#sizes-member

[3] https://html.spec.whatwg.org/#attr-link-sizes-any

Ah, something like this?

"icons": [{
        "src": "icon.svg",
        "sizes": "any",
        "type": "image/svg+xml"
}, ...]

That makes sense, for the cases where SVG will be appropriate.

Philip

[Michael van Ouwerkerk]

Yep, that's the idea :-) I would recommend always specifying a bitmap icon of some sort as fallback.

/m

 

Philip