On Thu, Jul 10, 2014 at 5:44 AM, Jonas Sicking <jonas@sicking.cc> wrote:
> I think the most low hanging fruit would be to add the following as
> data that can be displayed in a notification:
>
> * Progress bar
Tracked here: https://github.com/whatwg/notifications/issues/17
> * Lists of title/body pairs
What exactly is this for?
> * Date (for things like "event will happen in 10 minutes")
Should this be part of a generic alarm API?
There's also a request for transient/toast notifications:
https://github.com/whatwg/notifications/issues/11
> Second, we really need to figure out the story around handling user
> clicking notifications after the user has closed the original page.
There's a proposal for that in a separate thread:
http://lists.w3.org/Archives/Public/public-whatwg-archive/2014Jul/0204.html
> We need to change the GC behavior. Right now it seems like if a
> Notification object is created, but no event listeners are attached,
> because the page is expecting to use the SW event to listen for
> clicks, the notification won't be kept alive and so the SW can't get
> to any of its data.
Notification objects can go away, but the notification concept cannot be GC'd.
> We also need to keep state on the Notification object if the user has
> clicked the notification or not.
Why is that?
> We should also consider enabling passing a URL to the Notification
> constructor which is opened when the user clicks the notification.
> Probably this should attempt to reuse an existing tab with said URL if
> one is open.
That might be an interesting way to let service workers spawn a new window.
> Third, we should look at enabling minimal user input through the
> Notification. It's very common for notifications to support having one
> or more buttons that the user can click. It would also be good to
> enable putting a simple text-input in the notification. This area is
> definitely more complex though so happy to put this last.
--
http://annevankesteren.nl/