Re: Feedback from Safari on Web Notifications

On Wed, Mar 7, 2012 at 1:54 PM, Ojan Vafai <ojan@chromium.org> wrote:

> On Wed, Mar 7, 2012 at 10:15 AM, John Gregg <johnnyg@google.com> wrote:
>
>> On Tue, Mar 6, 2012 at 4:48 PM, Maciej Stachowiak <mjs@apple.com> 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:
>
> Notification<http://dev.w3.org/2006/webapi/WebNotifications/publish/Notifications.html#dfn-notification>(DOMString
> title, DOMString body, NotificationOptions optionsDict);
>
> NotificationsOptions can contain iconURL, onclick, dir, replaceId, etc.
>
> What's the use-case for creating a Notification and then setting these
> parameters?
>

I was mostly concerned with the possibility of a gnarly constructor API,
but the NotificationsOptions dictionary solution is nice and removes my
concern (thanks Ojan for spelling that out).  The only other reason not to
bundle show() with construction would be if an author wants to create and
stow away a notification for future showing, but I don't think there is
really such a use case.  Unless there are other objections, it sounds like
we have consensus so I'll make this change to the spec.

 -John