- From: Anne van Kesteren <annevk@annevk.nl>
- Date: Thu, 25 Sep 2014 12:02:31 +0200
- To: Jonas Sicking <jonas@sicking.cc>
- Cc: WHATWG <whatwg@whatwg.org>, Jake Archibald <jaffathecake@gmail.com>, Peter Beverloo <beverloo@google.com>
On Thu, Sep 25, 2014 at 2:28 AM, Jonas Sicking <jonas@sicking.cc> wrote: > On Wed, Sep 24, 2014 at 4:28 AM, Anne van Kesteren <annevk@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/
Received on Thursday, 25 September 2014 10:02:57 UTC