- From: Robert Bindar <robertbindar@gmail.com>
- Date: Wed, 13 Aug 2014 14:12:23 -0700
- To: whatwg@whatwg.org
- Cc: James Burke <jburke@mozilla.com>, julienw@mozilla.com, Michael Henretty <mhenretty@mozilla.com>
Concerning web notifications, it would be very helpful for content and web apps to have a way of specifying the behavior their notifications should have. For instance, a chat client may not always want to play a sound when sending a notification pertaining to a new message. Or in the mobile web, an app may want to avoid waking the screen on every notification to save battery life. Web content could have a way to "suggest" these behaviors to the user agent. Android and iOS each have their own approaches for specifying notification behavior. Android has a flags field in the Notification.Builder class that can specify to the device what behaviors that notification should have via some constants: FLAG_SHOW_LIGHTS - turn the led on, FLAG_INSISTENT - play sound till the user cancel the notification, FLAG_NO_CLEAR - the notification should not be cancelled when the user clicks ClearAll button). iOS has some properties on the UILocalNotification class for customizing the notification: soundName - the alert sound or default "nil"(disabled), hasAction - "NO" means the action button is hidden and there is no way to launch the application from the alert. fireDate - schedule the notification's fire date ("nil" means an immediate delivering) James Burke mentioned this, among some other suggestions, in an earlier email to the mailing list [1]. I'd like to open this discussion again strictly pertaining to notification behaviors. What I propose is something like this: new Notification('title', { tag: 'tag', behavior: { vibration: true, silent: true, lights: false, list: true, noclear: true, squash: true, } }); * vibration - vibrate the device * silent - "true" means do not play a sound when firing the notification(the sound is enabled by default in firefox for OSX, not available in Linux and Windows) * lights - turn the screen on * list - add a new entry to the notification list * noclear - this notification shouldn't be closed when pressing the ClearAll button * squash - every time you'll find a notification with the same tag, do not disrupt the user, just update the existing notification Again, the `behaviors` object is just a package of suggestions for how a notification should behave, but it is up to the user-agent to determine whether it wants to honor these behaviors (based on platform support, user settings, or even general user experience). I'd appreciate any feedback on this, name suggestions or new useful options. [1] lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2013-September/252648.html Thanks, Robert
Received on Wednesday, 13 August 2014 21:12:56 UTC