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

Re: Feedback from Safari on Web Notifications

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

On Mar 13, 2012, at 1:26 PM, John Gregg <johnnyg@google.com> wrote:

> I see; I didn't understand the notion of task. Ojan's original proposal included "onclick". Anne, are you arguing that we shouldn't include the event listeners in the options, and only allow them to be set after the constructor?
> 
> Do others agree with this? Or is the fact that showing is a queued task somehow implied already elsewhere in the spec? I'm just beginning to familiarize myself with spec-ese terms.
> 
> Yes, it should be the case that show queues a task.  That would allow you to either set the listeners in the constructor or after the constructor in the current task. 
> 
> I had trouble with that way of thinking too, which is why I was convinced a separate show() method was better for the purpose of setting event listeners.  I still think it's more natural to pass them in the constructor so that the author doesn't really have to think about tasks while programming, but Notification should support the common EventTarget interface as well.
> 
Then does setting them in the constructor syntactic sugar for

n.onshow = showcallback;

or

n.addEventListener("show", showcallback, false);


Also, is there no other spec that includes callbacks in the options dictionary?

Jon
Received on Tuesday, 13 March 2012 20:35:32 GMT

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