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

Re: [whatwg] Notifications and service workers

From: Jonas Sicking <jonas@sicking.cc>
Date: Thu, 25 Sep 2014 17:07:19 -0700
Message-ID: <CA+c2ei_Ehsvqj6EJvyaRoHHtnB7d=bb4BiOcL3ZO=BEzSEq3eQ@mail.gmail.com>
To: "Tab Atkins Jr." <jackalmage@gmail.com>
Cc: WHATWG <whatwg@whatwg.org>, Jake Archibald <jaffathecake@gmail.com>, Peter Beverloo <beverloo@google.com>
On Thu, Sep 25, 2014 at 4:42 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
> The one example I can think of that's kinda like this is the Google
> Maps Navigation "Notification".  It actively resists being closed, for
> one thing, but it does have a Dismiss button on itself (because it's a
> Rich Notification or whatever), which when pressed also cancels
> navigation in the app.  This seems like a specialized function of the
> app itself, using some future form of rich notifications, though, and
> not something we can or should generalize to other apps.  It's
> definitely not an example we should generalize to generic "clearing
> out all my notifications" behaviors, because it explicitly resists
> such things and requires an affirmative and purposeful action on the
> part of the user to dismiss it.

FWIW, I think there is a need for "extra persistent" notifications.
Which I think mainly mean that they don't get removed if the user
presses the "clear all" button in a notification tray. Or that the
notification wouldn't go away when simply clicked.

This type of notification can be useful for ongoing activities. Such
as navigational apps, or download progress.

API-wise this could be supported by simply adding an additional flag
to NotificationOptions, like "resistClear: true" or "noclear: true".
This flag would be ignored for non-persistent notifications.

It might still be good for UAs to allow removing this type of
notification, but I think if and how to enable that is a UA decision.

/ Jonas
Received on Friday, 26 September 2014 00:08:17 UTC

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