Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add closeTrigger to Notifications API #3

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open

Add closeTrigger to Notifications API #3

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 3 additions & 1 deletion IDL.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -16,6 +16,7 @@ interface TimestampTrigger : Trigger {
## Additions to the Notification API
```webidl
partial dictionary NotificationOptions {
Trigger closeTrigger = null;
Trigger showTrigger = null;
};

Expand All @@ -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.
13 changes: 8 additions & 5 deletions README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,21 +1,23 @@
# Notification Triggers

**Written**: 2019-01-28<br/>
**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
Expand All @@ -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)
});
}
```
Expand Down