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. TedReceived 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