- From: Anne van Kesteren <annevk@annevk.nl>
- Date: Wed, 24 Sep 2014 13:28:45 +0200
- To: Jonas Sicking <jonas@sicking.cc>
- Cc: WHATWG <whatwg@whatwg.org>, Jake Archibald <jaffathecake@gmail.com>, Peter Beverloo <beverloo@google.com>
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/
Received on Wednesday, 24 September 2014 11:29:12 UTC