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

Re: Some comments on the API

From: Drew Wilson <atwilson@google.com>
Date: Mon, 18 Oct 2010 10:34:08 -0700
Message-ID: <AANLkTik_fMZfPp-j_AecJssX42-evoofaS+2S5Wc03_C@mail.gmail.com>
To: James Graham <jgraham@opera.com>
Cc: Doug Turner <dougt@dougt.org>, Anne van Kesteren <annevk@opera.com>, Web Notification WG <public-web-notification@w3.org>
On Mon, Oct 18, 2010 at 1:46 AM, James Graham <jgraham@opera.com> wrote:
>
>
> As well as the technical point about the interface object existing on
> Window anyway, as explained by Jonas, it is unclear to me that notifications
> are conceptually part of the overall browser rather than tied to a specific
> DOM window. If I attach any event listeners to a particular notification,
> they will be bound to a particular window. After a window is closed or
> navigated it no longer makes any sense to display notifications from that
> window. Indeed, the draft should specify exactly what happens when a window
> with visible or pending notifications is unloaded, by hooking into the
> "unloading document cleanup steps" [1]. I imagine this should say that all
> such notifications should be canceled without firing any events.
>
>
I'd be curious about whether there are any use cases where the user would
want notifications to stay on-screen after a page is reloaded/navigated. I
know that I take steps in gmail to ensure that notifications go away when
gmail exits/reloads, but that's because gmail notifications are tied closely
to specific UI elements (chat sessions) that don't persist across page
reloads, or are temporary anyway (email notifications which self-cancel
after 6 seconds). So I think the proposed behavior (close on document
cleanup) would work for my case, but I'm not sure whether there are other
cases we're not considering.

-atw
Received on Monday, 18 October 2010 17:34:38 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 17 December 2012 14:48:27 GMT