Re: [whatwg] Notifications and service workers

On Wed, Sep 24, 2014 at 2:21 AM, Jonas Sicking <jonas@sicking.cc> wrote:
> * We should consider the case of persistent notifications separate
> from notifications that automatically close when a page goes away.

Strawman: We classify existing notifications as non-persistent
notifications. Only notifications associated with a service worker are
persistent. That would also allow us to remove the complexity of
exposing a single non-persistent notification as multiple Notification
objects.


> * Right now the spec requires that whenever a user interacts with a
> persistent notification, the application that created the notification
> is immediately started so that we can send the appropriate
> click/close/future-button-press event to it's service worker. This can
> be quite expensive. At the very least applications need to be able to
> indicate that they don't need to be told about the "close" event.
> * Even better would likely be content could indicate which events they
> want fired at the service worker when creating a Notification. Other
> events would be dropped. This list vary by-notification, not by-app.
> * Alternatively, maybe we could simply get rid of the "close" event
> entirely. Does it have a use-case?

Is this only about the close event? We could opt not to support for
persistent notifications as a start if we follow my strawman above.
I'm not a 100% sure why it's there either at this point. I suspect not
supporting it would not necessarily break anything. Probably mostly
there for symmetry with the close() method.


-- 
https://annevankesteren.nl/