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

Re: [whatwg] Notifications and service workers

From: Anne van Kesteren <annevk@annevk.nl>
Date: Wed, 1 Oct 2014 13:31:44 +0200
Message-ID: <CADnb78jOdDmXacGJM0OKD=cSPg+kS2J8U6xseB1-9m3khnMmnQ@mail.gmail.com>
To: Peter Beverloo <beverloo@google.com>
Cc: WHATWG <whatwg@whatwg.org>, "Tab Atkins Jr." <jackalmage@gmail.com>, Jake Archibald <jaffathecake@gmail.com>, Jonas Sicking <jonas@sicking.cc>, Andrew Wilson <atwilson@google.com>
On Fri, Sep 26, 2014 at 4:36 PM, Peter Beverloo <beverloo@google.com> wrote:
> * Life-time of existing notifications.
> Chrome currently treats Web Notifications as "persistent" ones. When the
> page goes away, the notification stays. Interaction with the notification is
> not going to trigger anything anymore. While I'm in favor of changing this,
> we have to be very cautious to not break user expectations of existing users
> of the Web Notification API, for example in calendar applications.

I think from the perspective of the specification this does not change
anything. If a platform wants to log all notifications that is fine.
What we want to start calling "persistent" notifications are those for
which a service worker will get notified and which can be retrieved
using Notification.get(). Hopefully browsers and platforms evolve over
time to distinguish the two more clearly.

> * Dropping the close event.
> Synchronizing closing of the notification on all the user's devices is an
> interesting one, but opt-in would be sufficient for this.

Yeah, it seems like we need to keep this. Through opt-in works.

> * Not using the constructor for persistent notifications.
> I have no strong feelings here either, and think it's fine to continue using
> the constructor with the serviceWorker property set. Both would still use
> the Notification statics. Having a promise would clean up the error handling
> a bit, which may occur in the no-permission case.

It seems nicer to have the association with the registration be
implicit by having a method on that object (reg.createNotification()).
However, it's very much the factory pattern which is somewhat frowned
upon. But hopefully it's not too bad here.

Combined with dropping the open event, I think I have enough to rework
the current Notifications API. Is there anything I'm missing?

Received on Wednesday, 1 October 2014 11:32:09 UTC

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