Re: Notifications

On Wed, Feb 3, 2010 at 9:55 AM, Olli Pettay <> wrote:

> Hi all,
> some random comments about
> (I didn't know that the draft existed until the link was mentioned
>  in an email to @whatwg mailing list :/ )

Hi Olli,

I was hoping to get some more work in on the draft before officially sending
it out for feedback, but since there is interest out there it's time to
start ramping it up.  Thanks for the comments!

> NotificationCenter is a bit strange. Why do we need
> a separate interface for this?
> I'd rather added createNotification to window object,
> or to .screen.

The idea was to have a common place to manage notification permissions as
well as create notifications.  That would end up with a lot of
notifications-specific items on the window object.

> createNotification and createHTMLNotification could be
> merged. Based on the parameters UA could create
> a bit different kinds of notifications.
> Or depending on what kind of resources get loaded.
> The naming should be better.

That sounds reasonable to me, I'll make that change.

> requestPermission talks about user gesture, but doesn't
> define what an user gesture actually is.
I thought the term was well known, but I will find a suitable reference.

> If createNotification would be in
> .screen or in window, then perhaps rename other methods to
> .requestNotificationPermission()
> and .checkNotificationPermission()
> those are a bit long ones, but still shorter than
> .notifications.requestPermission()

As mentioned above, I think it's a good trade of 2 extra characters to put
these things in a common place; it also makes it more easy for an author to
check "if (window.notifications === undefined)".

> Why the need for notifications in a worker?
> In which screen would the notification show up?
> I would leave that out of the draft.
> Worker can easily send some message to window to
> ask for a notification.

The thought is that a shared worker would be a good place to generate
notifications for a multi-tab application, while avoiding duplicate alerts.
 If we require it to find a window, it has to keep track of which windows
are open.  As that set may change, I don't think it's as easy as allowing
direct access to the API.

> How does create(HTML)Notification actually work.
> At which point does it load the external resources?
> At which point is "display" event dispatched?
> When showing the notification? But what if the external
> HTML file or icon file isn't loaded yet?

I will make this more specific in the draft: create[HTML]Notification should
not load the necessary resources until it is about to be displayed (in case
of a queue).  Once it is at the top of the queue, it should:

- load its resources as if opening a new window
- dispatch the display event
- show itself on the screen

> "The function provided in the callback parameter will be invoked when the
> user has responded to the permission request. "
> The IDL doesn't show any callback parameter.

Quite right -- will fix.

Received on Wednesday, 3 February 2010 18:33:44 UTC