Notifications API

[johnmellor]

https://notifications.spec.whatwg.org

Shipping in various stages in different browsers:

• Chrome ships most of the spec, except some newer features like action buttons (there is an Intent to Ship for those).
• Firefox ships most of the spec except the Service Worker API, for which it has an Intent to Ship.
• Safari ships the older W3C version.
• It is Under Consideration by Edge.

[torgo]

Discussed on call 11-November - assigned to 25th of November

[triblondon]

Brief notes transcribed from Alex:

constructor is in docs, showNotification method in background context. Event mode works in SW but not in documents? Growing set of notification types? Icons and action buttons? Multi res images/formats, notifications for ringing - more aggressive, need perms? Large image formats? List of items? Line up Requireinteraction flag and background task API - overlap?

[beverloo]

That's very brief indeed. Will there be a more detailed version? cc @slightlyoff

constructor is in docs, showNotification method in background context.

Correct. The constructor relies on events on the object, the lifetime of which cannot be guaranteed in a Service Worker. (Consider that notifications are able to to outlive the user agent.)

Event mode works in SW but not in documents?

What is "event mode"?

Growing set of notification types?
Large image formats?
List of items?

Yes, providing high fidelity integration with operating systems is a goal, especially when multiple OSes are able to provide a feature.

Large images: whatwg/notifications#79
List of items: whatwg/notifications#21
Progress bars: whatwg/notifications#17
Inline replies: whatwg/notifications#68

Icons and action buttons?

Supported.

Multi res images/formats

whatwg/notifications#28

notifications for ringing - more aggressive, need perms?

I recall this being mentioned somewhere, but can't find it. This indeed isn't addressed by the current spec (it'd be an immediate/high-priority mode). Two thoughts:

1. It's not uncommon for apps to focus their own window for such events, as opposed to showing a notification. This would definitely need a permission, but is likely out of scope for notifications.
2. The Android-like "peek-on-top" notifications are an application of priority. However, their presentation is a heuristic and it's not clear what sort of cross-platform support we'd be dealing with.

Line up Requireinteraction flag and background task API - overlap?

Unrelated I think? requireInteraction indicates that a toast should remain on-screen until the user interacts with it, in cases where that is significant (for example a calendar reminder).

[triblondon]

Peter, apologies, that was transcribing a 40 second conversation between
Alex and I when I offered to take over the spec review. A proper review
will be posted when I get the chance to do it, hopefully this week.
On Tue, 2 Aug 2016 at 01:23, Peter Beverloo notifications@github.com
wrote:

That's very brief indeed. Will there be a more detailed version? cc
@slightlyoff https://github.com/slightlyoff

constructor is in docs, showNotification method in background context.

Correct. The constructor relies on events on the object, the lifetime of
which cannot be guaranteed in a Service Worker. (Consider that
notifications are able to to outlive the user agent.)

Event mode works in SW but not in documents?

What is "event mode"?

Growing set of notification types?
Large image formats?
List of items?

Yes, providing high fidelity integration with operating systems is a goal,
especially when multiple OSes are able to provide a feature.

Large images: whatwg/notifications#79
whatwg/notifications#79
List of items: whatwg/notifications#21
whatwg/notifications#21
Progress bars: whatwg/notifications#17
whatwg/notifications#17
Inline replies: whatwg/notifications#68
whatwg/notifications#68

Icons and action buttons?

Supported.
https://notifications.spec.whatwg.org/#dictdef-notificationaction

Multi res images/formats

whatwg/notifications#28
whatwg/notifications#28

notifications for ringing - more aggressive, need perms?

I recall this being mentioned somewhere, but can't find it. This indeed
isn't addressed by the current spec (it'd be an immediate/high-priority
mode). Two thoughts:

1. It's not uncommon for apps to focus their own window for such
   events, as opposed to showing a notification. This would definitely need a
   permission, but is likely out of scope for notifications.
2. The Android-like "peek-on-top" notifications are an application of
   priority. However, their presentation is a heuristic and it's not clear
   what sort of cross-platform support we'd be dealing with.

Line up Requireinteraction flag and background task API - overlap?

Unrelated I think? requireInteraction indicates that a toast should
remain on-screen until the user interacts with it, in cases where that is
significant (for example a calendar reminder).

—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHub
#94 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABp63wUBTU45b9vAVmHn28KPELsGtJ4oks5qbh11gaJpZM4GcnSJ
.

[triblondon]

OK, here's my review. Do bear in mind that I'm a web developer, not a spec author, so may need some hand holding in places, sorry.

2.1

a couple of seconds

I'm unsure whether this is intended to be a required duration of exactly 2 seconds, or a recommendation of an approximate time, the exact duration to be left to the UA implementor.

This section uses should where it might be better to use must?

2.2

"default"
This is equivalent to "denied", but the user has made no explicit choice thus far.

Is it confusing to call these states equivalent? There is a difference in terms of whether the notification will succeed, isn't there?

2.5

Then, in parallel:

The steps in this algo do not seem to be parallelisable to me, but I'm new to reading algorithm specs, so I may not understand the subtleties, apologies.

2.7

Is it necessary to have this much difference between the behaviour of persistent and non-persistent notifications? For example, could the event name be notificationclick in both cases?

On a non-persistent notification, does the click event bubble?

Throughout the web platform "activate" is intentionally misnamed as "click".

Isn't this a bit revisionist? If not, why is the misnaming intentional?!

2.8

Can you clarify if/why it doesn't make sense for the closure of a non-persistent notification to trigger an event?

3.2

Could we make it possible to use the constructor within a service worker? It seems like unnecessary work to make developers learn two different ways to use notifications. Or conversely use showNotification in a document context?

I was surprised that simply constructing the notification shows it. That seems inconsistent with things like CustomEvent, which is created and then triggered.

3.5.1

Since Notification implements EventTarget would not.addEventListener be a better pattern to show here?

3.5.2

Really clear and practical example here, thanks!

3.5.3

Is there a timeout or lifetime on tags? What if I issue a second notification with the same tag after the first notification has been closed? Would a new notification appear?

Considering Alex's points:

• Different construct methods in different contexts: I agree, and included that point in my review above.
• Event mode works in SW but not in documents?: I may not have captured this point properly. I couldn't find any problems with the availability of events other than the lack of a close event for non-persistent notifications.
• Growing set of notification types? Icons and action buttons? Multi res images/formats, Large image formats? List of items?: I believe Alex is concerned about scope creep here. I would have been concerned if each of these represented a fundamentally different notification, but if it is possible to use all these properties together as required, that just adds flexibility to the notification content, which sounds good to me.
• notifications for ringing - more aggressive, need perms?: As Peter noted above, not currently captured - a way to handle real time, urgent state notifications with short (and potentially unpredictable) timeouts for action.
• Line up Requireinteraction flag and background task API - overlap?: I failed to remember what this point was, apologies. Alex may want to follow up here.

[marcoscaceres]

Growing set of notification types? Icons and action buttons? Multi res images/formats, Large image formats? List of items?: I believe Alex is concerned about scope creep here. I would have been concerned if each of these represented a fundamentally different notification, but if it is possible to use all these properties together as required, that just adds flexibility to the notification content, which sounds good to me.

This should consider the design and use cases of responsive images - that is, the selection algorithm (and the ability to discriminate on image type, density, etc.) should be supported, as per HTML's picture element (or a slightly simpler model). Otherwise, developers have to send unnecessarily large icons to their users.

[triblondon]

@beverloo do you have any other follow-up on this review?

(taken up at Tokyo F2F)

[triblondon]

Sounds like we're all done here then.