Re: [Notifications] feedback requested on new Editor's Draft

This looks good. One thing which I suggested previously but which didn't
make it into the spec is the ability for the UA to eliminate duplicate
notifications. Since I've been using the existing experimental notifications
API in Chrome, I've found that duplicate notifications are very common and
quite irritating to the user, and there's no good way for applications to do
duplicate elimination themselves (they could route notifications through a
SharedWorker, but there's no good way for the SharedWorker to route click
events back to the parent windows in such a way that they appear to be user
gestures, so you wouldn't be able to satisfy the "Go To Inbox" use case
described in the spec).

A few notes on the spec itself:

Section 4:

   - The definition of the onclose attribute is incorrect, and should read
   "An event listener function corresponding to the event type '*close*'",
   not 'error'.


Section 5:

   - (parroting Anne's comment): It's somewhat ambiguous how the iconUrl
   parameter in createNotification() is processed - I'm wondering about how UAs
   should handle cases like HTTP auth while trying to access that resource
   (should they display the notification without an icon? fail the
   notification?). Likewise, I'm curious about how a UA should treat a
   non-secure iconUrl being generated from script within a secure page,
   although perhaps that's outside the bounds of the spec.
   - I'm wondering if the documentation for requestPermission() should read:
   "If the current permission level is permission_denied, the user agent *must*
   take no action..." (rather than "may take no action").
   - Is the intent of the spec that an Exception is thrown if the user calls
   requestPermission() when the permission is already PERMISSION_ALLOWED?

Section 6:

   - I don't understand the need for the optional mime parameter to
   createWebNotification(). What use case is it satisfying, that the normal
   resource fetching/mime-type inference mechanisms don't satisfy (i.e. +1 to
   Anne's comment)

Section 8:

   - Should passing an unsupported type of web content to
   createWebNotification() generate an error event?
   - The "display" event is generated when the notification is passed along
   to the underlying notification platform - technically, since the underlying
   platform can also do its own queueing, it's possible that the display event
   is generated before the notification itself is displayed. Should this be
   mentioned in the spec?

Section 9:

   - Is there any use case where an application needs to know that the
   system has closed the notification without user input? Currently a close
   event is only generated if the user explicitly dismisses a notification.

-atw

On Tue, Mar 23, 2010 at 3:54 AM, Robin Berjon <robin@berjon.com> wrote:

> On Mar 23, 2010, at 11:33 , Anne van Kesteren wrote:
> > Currently there are no processing requirements for the mime argument of
> createWebNotification(), do we really need it?
>
> Do we have use cases for content other than HTML or SVG? Presumably those
> can "just work".
>
> > Should we really put another interface on the global object? Can we not
> put these on window.navigator like other APIs that integrate with the system
> layer?
>
> +1, navigator is the new window :)
>
> --
> Robin Berjon - http://berjon.com/
>
>
>
>
>