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
This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 17:00:23 UTC