Re: Feedback from Safari on Web Notifications

On Tue, Mar 13, 2012 at 1:54 PM, Navarr Barnier <navarr@gtaero.net> wrote:

> 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.
>
Note also that there are other non-DOM objects (like XMLHttpRequest) that
also support addEventListener() - given this precedent, I think it's
entirely appropriate to support events and as Navarr points out it provides
a nice framework to support future expansion.

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