[whatwg] Notifications: reviving Notification objects
Anne van Kesteren
annevk at annevk.nl
Sun Mar 31 07:33:01 PDT 2013
There are a couple of scenarios http://notifications.spec.whatwg.org/
does not address at the moment.
A) User navigates to chat site. Chat site creates a notification from
a chat with P while the user does something else. User closes chat
site and then navigates to chat site at a later point.
B) Instead of navigating to the chat site at a later point, the user
opens the notification center and clicks the notification.
C) User navigates to chat site at a later point, but with a view that
does not show the chat with P. User then opens the notification center
and clicks the notification.
A) No Notification object to close().
B) No Notification object to fire a click event to. Not clear which URL to open.
C) No Notification object to fire a click event to. Not clear if
further navigation is required.
1) Tie "the document's address" of when a Notification is created to
the Notification object to address B) and C). Maybe at some point
allow sites to define a URL to open.
2) Define a method on Navigator, getNotifications(), that returns a
Future which is resolved with an array of Notification objects. Once
the Future is resolved, a task is queued to fire a click event on the
appropriate Notification object in case of B) and C).
There are some further gotchas here. One is how Notifications objects
should be scoped (and thus what exactly getNotifications()'s Future is
resolved with). Origin-scoped would be extremely convenient, but it
seems we still have efforts that support further scoping for
applications based on the URL path.
The other is how much we need to expose on the Navigation object
itself so sites can identify it after reviving it. Currently almost
nothing is exposed, but maybe we should simply expose
dir/lang/title/body/tag/icon on it.
More information about the whatwg