W3C home > Mailing lists > Public > whatwg@whatwg.org > September 2014

Re: [whatwg] Notifications and service workers

From: Anne van Kesteren <annevk@annevk.nl>
Date: Thu, 25 Sep 2014 12:02:31 +0200
Message-ID: <CADnb78hQSWL4hwLSLNJouRjxfBD-9w7SV97KSLwLVYQ4a8mAxA@mail.gmail.com>
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.

Received on Thursday, 25 September 2014 10:02:57 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 17:00:23 UTC