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

Re: [whatwg] Notifications and service workers

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Tue, 23 Sep 2014 17:32:39 -0700
Message-ID: <CAAWBYDDVoHt=rNKbTpWbkiQkzqLSA2XU0oUgdc_ddhr_ePJi-A@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 Tue, Sep 23, 2014 at 5:21 PM, Jonas Sicking <jonas@sicking.cc> wrote:
> After having talked to our web developers, and having talked to Olli,
> I've come to the following conclusions:
>
> * We should consider the case of persistent notifications separate
> from notifications that automatically close when a page goes away.
> * Notifications that close when a page goes away does not seem useful
> on mobile, but could be useful on desktop to enable minimized
> applications, or applications whose window is covered by other
> windows, call attention to themselves.

Can you provide an example use-case for a persistent notification that
goes away when the page does?  I can think of transient notifications,
and persistent ones that stick around until dismissal, but I can't
come up with this in-between case with a few minutes thought.

> * Persistent vs. non-persistent doesn't seem like a platform
> difference, but rather two different types of notifications that
> content could want to create.

Yes.  Pandora temporarily spawning a notification showing the song
title/artist that's playing whenever a new song starts seems useful as
a non-persistent notification on any platform.  I definitely wouldn't
want that sort of thing to stack up on a mobile device.

> * For persistent notifications, in cases where the application cares
> about the user clicking on the notification (as opposed to
> fire-and-forget notifications), we should always send a notification
> to the service worker. In this scenario it never seems useful to fire
> an event on the Notification instance since that will just mean
> multiple codepaths trying to handle the same click. At best that would
> be wasted performance, at worst it could mean broken UI or application
> logic.
> * Same applies to "close" in addition to "click".
> * For non-persistent notifications, it seems good to not require that
> a service worker is used.

I'm not sure persistent vs non-persistent is quite the line to draw
this on.  Fire-and-forget vs responsive seems more correct.  Most
(all?) persistent notifications are responsive, yes, but transient
notifications might or might not be.  I think it's appropriate and
useful for a fire-and-forget notification to be fireable from a normal
page, without a service worker.

> * I'm uncertain about if non-persistent notifications are important
> enough to target at this point. But I'm heavily biased from having
> worked mainly on mobile web lately.
> * 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.

Yes, seems useful.

> * Alternatively, maybe we could simply get rid of the "close" event
> entirely. Does it have a use-case?

I'm also not sure, on first thought, how an app would respond to a
close event.  I don't think that apps on Android currently care if you
close a notification?  At least, nothing that I use seems to do
anything about it; IRCCloud, for example, doesn't mark mentions as
already read if I close the mention notification.  Some use-cases
would be useful.

~TJ
Received on Wednesday, 24 September 2014 00:35:40 UTC

This archive was generated by hypermail 2.3.1 : Monday, 13 April 2015 23:09:30 UTC