Notifications API #94
Shipping in various stages in different browsers:
modified the milestones:
Feb 15, 2016
Brief notes transcribed from Alex:
That's very brief indeed. Will there be a more detailed version? cc @slightlyoff
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.)
What is "event mode"?
Yes, providing high fidelity integration with operating systems is a goal, especially when multiple OSes are able to provide a feature.
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:
Unrelated I think?
Peter, apologies, that was transcribing a 40 second conversation between
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.
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?
Is it confusing to call these states equivalent? There is a difference in terms of whether the notification will succeed, isn't there?
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.
Is it necessary to have this much difference between the behaviour of persistent and non-persistent notifications? For example, could the event name be
On a non-persistent notification, does the
Isn't this a bit revisionist? If not, why is the misnaming intentional?!
Can you clarify if/why it doesn't make sense for the closure of a non-persistent notification to trigger an event?
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
Really clear and practical example here, thanks!
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:
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.