[whatwg] Notification API

[John Gregg]

The Webapps WG is working on a spec for a Web Notification API.  You can see
the current draft at http://dev.w3.org/2006/webapi/WebNotifications/publish/,
and I would suggest sending comments to the public-webapps mailing list.

That spec attempts to address the icon+title+text use case, and allows a
user agent to use a third party presentation system as long as that system
can notify of notifications being acknowledged, but also allows HTML as an
option if the device supports it.

I disagree with the claim that HTML notifications are overkill as long as
they can be done securely, it opens up a lot of benefit to have dynamic &
interactive notifications.  Even for the simple case of Calendar reminders
which might have multiple forms of acknowledgement: snooze for N minutes (a
<select> would be nice), or dismiss.

Thanks,
 -John

On Wed, Feb 3, 2010 at 3:55 AM, Henri Sivonen <hsivonen at iki.fi> wrote:

> I noticed that there's a Chromium-specific API for notifications:
>
> http://dev.chromium.org/developers/design-documents/desktop-notifications/api-specification
>
> Opera has an Opera Widgets-specific API:
>
> http://dev.opera.com/articles/view/opera-widgets-specification-fourth-ed/#wo_showNotification
>
> What's the right mailing list for discussing notification APIs?
>
> Since the right people are likely reading this list:
>
> It seems to me that it would be desirable to have an API that authorized
> Web apps can use to post notifications to Growl (Mac) or NotifyOSD (Ubuntu).
> HTML notifications look like an overkill to me.
>
> It seems to me that Growl and NotifyOSD notifications have these things in
> common:
>  1) Title
>  2) Description
>  3) Icon
>  4) Ability to find out if the user clicked the notification. (Not yet in
> Karmic?)
>
> To map that to a really simply Web API, a single method with four arguments
> could be added to the navigator object. The arguments would be:
>  1) DOMString title (required)
>  2) DOMString description (optional, LF means rendered line break)
>  3) DOMString iconURL (optional, defaults to the favicon of the root
> browsing context of the script invoking the API)
>  4) function acknowledgement (optional, callback that is called if the user
> clicks the notification; clicking should always bring the window/tab of the
> page that invoked the notification to front)
>
> Does Chromium have use cases for HTML notifications that wouldn't be
> addressed by the simpler API outlined above? Does Opera have a reason for
> not allowing an icon and two distinct strings in notifications?
>
> --
> Henri Sivonen
> hsivonen at iki.fi
> http://hsivonen.iki.fi/
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100203/08a7ca44/attachment-0002.htm>