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.

Received on Monday, 18 October 2010 17:34:38 UTC

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