Re: Feedback from Safari on Web Notifications

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()?


On Mar 7, 2012, at 2:53 PM, James Graham <> wrote:

> On Wed, 7 Mar 2012, Ojan Vafai wrote:
>> On Wed, Mar 7, 2012 at 10:15 AM, John Gregg <> wrote:
>>      On Tue, Mar 6, 2012 at 4:48 PM, Maciej Stachowiak <> wrote:
>>            4. Improve show() behavior.
>> We think show() can only be used once per notification. Subsequent invocations should call onerror().
>> Agreed that show() is only meant to be used once.  Ian Hickson has made the related suggestion that show() should not exist as a method, but rather that show() be implicit in the constructor.
>>  I don't prefer that because it requires that all possible optional parameters of the notification be provided in the constructor, which makes the interface harder to use.  I prefer using
>> onerror to deal with multiple attempts to show, but this should be resolved by the WG.
>> I second Ian's suggestion . This is the direction we're taking many other things in the platform and it's been a clear improvement. For example, we're removing all the init*Event methods for custom
>> events and just using the constructors. The way we've been dealing with extra arguments is by passing in a dictionary for the optional arguments. So the API would be:
> Yes, I think the constructor approach is nicer and more in line with contemporary platform features.

Received on Tuesday, 13 March 2012 00:31:40 UTC