W3C home > Mailing lists > Public > public-web-notification@w3.org > October 2010

Re: Some comments on the API

From: John Gregg <johnnyg@google.com>
Date: Fri, 15 Oct 2010 16:04:09 -0700
Message-ID: <AANLkTind1pxTVBjha+DJM0isxQoLuDcu=BR3We_n0HEL@mail.gmail.com>
To: James Graham <jgraham@opera.com>
Cc: Web Notification WG <public-web-notification@w3.org>
On Fri, Oct 15, 2010 at 4:09 AM, James Graham <jgraham@opera.com> wrote:
> I wonder what the reason for the NotificationCenter design is. Does having a
> createNotification factory function buy us anything over just having a
> constructor so we can do something like
> var notification = new Notification(iconUrl, title, body)
> It seems to me that this design would be more consistent with XHR, which
> seems closer in function to the notifications API than createElement and
> friends from DOM Core.

The original motivation for the notifications (NotificationCenter)
object was to group the notifications methods with the
notifications-permissions methods in a logical place.  With
permissions moving out, I would be fine converting it to a constructor
style if others are in agreement.  But there would indeed be namespace
implications to consider.

> Having a function would make sense if the API instead queued the
> notification to be shown as soon as possible (note, I am not actually
> advocating this) however it is hard to see a reasonable design that would
> allow event handlers to be attached in such a design unless one did
> something like:
> showNotification(iconUrl, title, body, handlers)
> Where handlers was an object like {onclick:function(){}} and so on. But this
> kind of design is without precedent in the DOM.

I prefer the current style of creating the object, adding the events,
and then showing it (which is consistent with XHR, ignoring the
constructor style).

> On a somewhat unrelated note, it is not really clear to me what the use case
> of the cancel method is. I suspect that there are use cases, but the example
> in the draft of displaying a notification for at most 15s (I assume
> platforms can hide the notification at any time they like) doesn't seem that
> well motivated. If we expect that specific case to be common we should
> consider adding an explicit timeout to the API. Otherwise a different
> example might be helpful.

There are several use cases for this. One, for example, is an email
application which notifies of new emails in the inbox. If the user
returns to the inbox directly and sees the new emails (without
interacting with the notifications), the application would cancel the
notifications since they are no longer necessary.

I can add a more complete example like that.

> Speaking of examples, there is a createWebNotification example in section 7
> of the "Web Notifications" document. This should be changed to a
> createNotification example or moved to the other document.

Thanks for catching that, I will fix the spec.

Received on Friday, 15 October 2010 23:04:39 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 19:53:13 UTC