Re: Feedback from Safari on Web Notifications

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