On Thu, Sep 25, 2014 at 2:28 AM, Jonas Sicking <jo...@sicking.cc> wrote: > On Wed, Sep 24, 2014 at 4:28 AM, Anne van Kesteren <ann...@annevk.nl> wrote: >> Strawman: We classify existing notifications as non-persistent >> notifications. Only notifications associated with a service worker are >> persistent. > > This is a little bit implicit for my taste. But I don't feel very strongly.
I think it makes a lot of sense if we require service workers for persistent notifications. I figured we could rename the field from serviceWorker to something more explicit, but I can't really think of a good name. That means we should tie normal non-persistent notifications to the lifetime of the global. I take it we still want to allow those within workers, right? > But maybe they are rare enough that by default we only fire "click" > events. For persistent notifications we fire them at the SW, for > non-persistent at the Notification object. > > If we in the future find actual use cases for "close"/"show" we can > add ways to opt in to receiving those. And if we find use cases for > *not* receiving "click" (in particular to SW) we can add ways to opt > out of those. This strategy makes sense to me. If Jake and Peter (and everyone else who feels inclined :-)) could comment on this revised proposal that'd be great. -- https://annevankesteren.nl/