- From: Anne van Kesteren <annevk@annevk.nl>
- Date: Sun, 31 Mar 2013 15:33:01 +0100
- To: WHATWG <whatwg@whatwg.org>
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. Problems: 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. Potential solution: 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. -- http://annevankesteren.nl/
Received on Sunday, 31 March 2013 14:33:30 UTC