- From: Anne van Kesteren <annevk@annevk.nl>
- Date: Thu, 25 Sep 2014 21:30:17 +0200
- To: Jake Archibald <jaffathecake@gmail.com>
- Cc: WHATWG <whatwg@whatwg.org>, Jonas Sicking <jonas@sicking.cc>, Peter Beverloo <beverloo@google.com>
On Thu, Sep 25, 2014 at 12:25 PM, Jake Archibald <jaffathecake@gmail.com> wrote: > Totally agree, I didn't realise this was possible in the original proposal. > The option that makes it a persistent notification should retarget all > events to the serviceworker. If the serviceworker is invalid, I guess we > throw? Yup. > eventTarget: serviceWorkerRegistration > > persistWith: serviceWorkerRegistration Hmm, serviceWorker still seems best. > The ServiceWorker default would be persistent though right? Creating a > non-persistant notification in a ServiceWorker is likely to go wrong as you > lose your event handers when the worker terminates. Yeah, for service workers the default would be a persistent one. I was thinking we could allow an explicit serviceWorker: null to override that, but I'm not sure it buys us much. The lifetime of non-persistent notifications would be the lifetime of the global they are created in (or presumably lifetime of the active document in case of a document environment). > I don't have a use-case for "show" right now, but I think we need to keep > "close" for the use-case above. An events property could take an array to > restrict the events a notification will fire (defaulting to all). That would work too. Not sure I have a good sense of what would be best here. -- https://annevankesteren.nl/
Received on Thursday, 25 September 2014 19:30:46 UTC