From 28b2c8c405cb6d8e02950594a9dda99823c3ffee Mon Sep 17 00:00:00 2001 From: Dmitry Guketlev Date: Fri, 12 Apr 2019 21:59:09 +0300 Subject: [PATCH] Add closeTrigger to Notifications API --- IDL.md | 4 +++- README.md | 13 ++++++++----- 2 files changed, 11 insertions(+), 6 deletions(-) diff --git a/IDL.md b/IDL.md index 26a6e7c..ac57b4d 100644 --- a/IDL.md +++ b/IDL.md @@ -16,6 +16,7 @@ interface TimestampTrigger : Trigger { ## Additions to the Notification API ```webidl partial dictionary NotificationOptions { + Trigger closeTrigger = null; Trigger showTrigger = null; }; @@ -24,8 +25,9 @@ partial dictionary GetNotificationOptions { }; partial interface Notification { + [SameObject] readonly attribute Trigger closeTrigger; [SameObject] readonly attribute Trigger showTrigger; } ``` -The [create a notification](https://notifications.spec.whatwg.org/#create-a-notification) algorithm will be amended to throw a `TypeError` exception when a `showTrigger` has been provided, but not a `serviceWorkerRegistration`. This removes the ability to use _notification triggers_ for non-persistent notifications, which inherently are tied to the lifetime of the document. +The [create a notification](https://notifications.spec.whatwg.org/#create-a-notification) algorithm will be amended to throw a `TypeError` exception when a `showTrigger` or `closeTrigger` has been provided, but not a `serviceWorkerRegistration`. This removes the ability to use _notification triggers_ for non-persistent notifications, which inherently are tied to the lifetime of the document. diff --git a/README.md b/README.md index 32827f7..978274d 100644 --- a/README.md +++ b/README.md @@ -1,21 +1,23 @@ # Notification Triggers **Written**: 2019-01-28
-**Updated**: 2019-02-11 +**Updated**: 2019-04-12 Web developers have the ability to display notifications using the [Notifications API](https://notifications.spec.whatwg.org/). This ability is often used in collaboration with the [Push API](https://w3c.github.io/push-api/) to inform the user of time-sensitive information, such as a breaking news article or a received message. Notifications are then shown by allowing JavaScript code to run on the user's device. -**Notification Triggers** are a mechanism for preparing notifications that are to be shown when certain conditions are met. The _trigger_ could be time-based, location-based or otherwise—for this explainer, we'll focus on time-based triggers. +**Notification Triggers** are a mechanism for preparing notifications that are to be shown or closed when certain conditions are met. The _trigger_ could be time-based, location-based or otherwise—for this explainer, we'll focus on time-based triggers. -This makes it possible to prepare notifications to be displayed at a particular time without involving the server, and also improves reliability by removing the dependency on network connectivity. This can be essential for the user experience of certain types of web applications, for example calendars. +This makes it possible to prepare notifications to be displayed and then closed at a particular time without involving the server, and also improves reliability by removing the dependency on network connectivity. This can be essential for the user experience of certain types of web applications, for example calendars. ## Why do we care? * The Push API is not reliable for triggering notifications which must be shown at a particular time. The ability to receive messages depends on the device's connectivity, and features such as _deep sleep_ may further delay delivery. An example where this is important are notifications reminding you of a 5 AM departure time to the airport. * Unlike usage of the Push API, having notifications be prepared in advance helps browsers to avoid the cost of starting a Service Worker. Particularly on mobile devices, the impact of this can be significant. * Not starting the Service Worker for prepared notifications has a privacy-preserving effect: the user's IP address won't be shared with the server by removing the need for network requests, reducing IP-to-location tracking. +* In some cases shown notifications can become irrelevant, and can be closed based on time-based or other kind of trigger. An example where this us usefull are notifications reminding you of meeting after it has already ended. ## Goals * Make it possible to prepare notifications that should be shown in the future by introducing time-based triggers. +* Make it possible to show notifications that are usefull for limited period of time using time-based triggers. * Create a mechanism for _defining a trigger_ that works for the Notifications API, but can be extended to other APIs. ## Non-goals @@ -26,13 +28,14 @@ Please see [this separate document](IDL.md) for the proposed WebIDL additions. ## Scheduling a reminder ten minutes before an appointment ```javascript -async function createAppointment(tag, title, timestamp) { +async function createAppointment(tag, title, timestamp, duration) { // .. create the appointment in application-level code .. // Schedule a reminder to be shown to the user: await swRegistration.showNotification(title, { tag, body: 'Your appointment is due in ten minutes!', - showTrigger: new TimestampTrigger(timestamp - TEN_MINUTES) + showTrigger: new TimestampTrigger(timestamp - TEN_MINUTES), + closeTrigger: new TimestampTrigger(timestamp + duration) }); } ```