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

Re: [whatwg] Notifications and service workers

From: Anne van Kesteren <annevk@annevk.nl>
Date: Wed, 24 Sep 2014 13:28:45 +0200
Message-ID: <CADnb78gd637S59-7THcEWDJvAtiqxJ4XybP93f4JchNCVWUGOw@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 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

> * 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.

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