Re: Feedback from Safari on Web Notifications

It would, however, be nice if events did bubble up through HTML
notifications, which I believe have been placed on the backburner, despite
the fact that they're very popular among current implementations.

An event structure is nice since it is more widely used and html
notifications may use the dom. Providing events allows for future additions
and a common interaction.

Sent via mobile
On Mar 13, 2012 4:39 PM, "Ojan Vafai" <ojan@chromium.org> wrote:

> Why do we use events here at all? Can we just make them regular callbacks
> that take the Notification as their first argument? Events seem like
> overkill since these aren't actually part of the DOM (e.g. there's no
> meaningful capture/bubble phase).
>
> On Tue, Mar 13, 2012 at 1:26 PM, John Gregg <johnnyg@google.com> wrote:
>
>>
>>
>> On Tue, Mar 13, 2012 at 1:21 PM, Jon Lee <jonlee@apple.com> wrote:
>>
>>>
>>> On Mar 13, 2012, at 10:51 AM, Edward O'Connor <eoconnor@apple.com>
>>> wrote:
>>>
>>> > 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).
>>>
>>> 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.
>>
>>
>