W3C home > Mailing lists > Public > public-web-notification@w3.org > March 2012

Re: Feedback from Safari on Web Notifications

From: Edward O'Connor <eoconnor@apple.com>
Date: Tue, 13 Mar 2012 10:51:12 -0700
To: Jon Lee <jonlee@apple.com>
Cc: Anne van Kesteren <annevk@opera.com>, James Graham <jgraham@opera.com>, Ojan Vafai <ojan@chromium.org>, John Gregg <johnnyg@google.com>, Maciej Stachowiak <mjs@apple.com>, public-web-notification@w3.org
Message-id: <m2aa3kxucv.fsf@eoconnor.apple.com>
Jon Lee wrote:

> On Mar 13, 2012, at 1:44 AM, Anne van Kesteren wrote:
>
>> On Tue, 13 Mar 2012 01:32:18 +0100, Jon Lee <jonlee@apple.com> wrote:
>>> So by having the event listeners as part of the options dictionary,
>>> would it make sense, then, to remove the assignable attributes?
>>> Therefore, the only way to modify the listeners is through
>>> add/removeEventListener()?
>> 
>> If we make the constructor queue a task, you could still assign event
>> listeners in the same task that created the constructor.
> I don't quite understand what this means.

What Anne means is, if the constructor doesn't directly show but instead
queues a task to show, the task that called the constructor will run to
completion before the show task happens. So listeners attached with
addEventListener will work. For instance,

var n = new Notification("title", "body");
n.addEventListener("show", function(whatever) { blah; });

Both of these lines of code happen in one task, and showing the
notification happens in another task (after this run of the event loop
completes).

> If the constructor creates the Notification and also queues/presents
> the notification, then why would anyone want to re-assign listeners?

It's not reassignment, it's the initial assignment.

> The code already has an opportunity to set all the listeners in the
> options dictionary.

My impression from this thread is that people don't like that, and would
rather the Notifications object behave like a normal EventTarget.

> By the time the constructor is finished, the notification is already
> shown, so trying to change onshow doesn't do anything useful.

This is what Anne was disagreeing with. Hopefully my explanation above
makes it more clear.


Ted
Received on Tuesday, 13 March 2012 17:55:01 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 1 July 2021 16:05:28 UTC