Re: Feedback from Safari on Web Notifications

On Mar 7, 2012, at 3:13 PM, John Gregg wrote:

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

One downside to the options dictionary approach is that you can't feature-test which optional features are supported, so it's a little more awkward if we want to add additional parameters in the future. One way to avoid that is to make NotificationOptions a real interface instead of just using a generic Object-as-dictionary, so you can feature test. Not sure if that is worthwhile. Either way, showing implicitly seems to have benefits that outweigh the costs, IMO.

Regards,
Maciej