Re: [whatwg] Notifications and service workers

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?


-- 
https://annevankesteren.nl/

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