Contact emails
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
Link to entry on the feature dashboard
https://www.chromestatus.com/features/5687043120168960
Requesting approval to ship?
Yes
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?
What's the plan with regards to icon sizes? I can't see this being
discussed in the link you posted.
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.
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/28I think we can treat resolving issue 28 as an incremental improvement. It affects things other than action icons as well.
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/28I 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.
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.
Philip
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.
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.
Philip