Re: Starting up...

Konnichiwa Minna-san,

I'm Navarr Barnier.  I've been playing with Desktop Notifications since they
were first released into the dev chrome builds.

I look forward to them being standardized and implemented.

I have no formal qualifications for contribution, but I believe that I may
have some unique insight into different uses of the notification API.

Regarding that, I'd like to bring up a few things:

# Web Notifications

In reference to Web Notifications (where you load a URL instead of static
content), it may be important to add a new type of listening event to the
document being loaded.  I believe at the current onload="" triggers when the
page is loaded, but not shown, which is only problematic when we consider
that if there are multiple notifications, some being hidden, the onload
(which may trigger a timeout for self.close()) will be called before the
notification is shown.

I realize that there is an event for notifications ondisplay during the
creation of the notification from within the originating document, but the
notification itself (which may contain dynamic data) has no way of
interacting with events called from this without some possible hackery
involving window.opener, which is not yet used in any browser (to my
knowledge).

# Notification Priority

While reading through the past discussions on this list, the case of giving
notifications priority arose, and two cases were considered: One where
priority was set by the website, and one where priority was set by the user
based on the website.

What came up in discussion was that every web site may have a different view
of what has higher priority, but it did not appear to be considered that an
ample solution, allowing the prioritization of notifications to exist would
be to only prioritize notifications against notifications that also
originated from that website.

As previously discussed, a good example for a use case would be GMail and
Google Calendar:  Lets say that a user received five emails, an event, and
an IM at the same time.  If this specific UA implements it so that only five
notifications can ever be shown at any given time, the IM (which is in real
time) will be pushed to the end of the stack.  If, instead, emails were
prioritized as low and IMs as high, the UA would then show the IM, the Event
(which is launched from a different site), and three of the emails.

This seems like a decent implementation of a very useful feature, without
one site tripping over another in its usage.

# Propagation

In the current Chrome implementation (and unaddressed in the spec),
event.stopPropagation() on Web Notification content does not prevent the Web
Notification Object's onclick method.

Should it?  Would a developer expect it to?

-----
Navarr T. Barnier
Bowling Green State University (Student)
http://tech.gtaero.net/