Re: Notifications

On Wed, Feb 3, 2010 at 11:41 AM, Anne van Kesteren <annevk@opera.com> wrote:

> On Wed, 03 Feb 2010 19:54:44 +0100, Drew Wilson <atwilson@google.com>
> wrote:
>
>> Following up on breaking out createHTMLNotification() and
>> createNotification() vs combining them into one large API - I believe the
>> intent is that a given user agent may not support all types of
>> notifications
>> (for example, a mobile phone application may only support text + icon
>> notifications, not HTML notifications). Having these APIs broken out
>> separately allows the UA to communicate whether it supports one or the
>> other
>> to the web app (a UA that does not support HTML notifications would leave
>> createHTMLNotification() undefined).
>>
>
> If that is the idea createHTMLNotification() should be on a separate
> supplemental interface that user agents on platforms that support HTML
> notifications can implement to make it clear it might not be available and
> that is somewhat separate. (Not sure whether I agree we need HTML
> notifications though, especially for v1.)
>
>
I'd be okay with using a separate interface if it is the more clear way make
something optional in the spec, provided the actual invocation doesn't
become too cumbersome.  (window.notifications.html.createNotification(url)
vs window.notifications.createNotification(icon,text) maybe?)

I tried to indicate in the descriptive parts of the spec that
createHTMLNotification could be left undefined if unsupported, so the goal
is the same as what you propose.

As to whether HTML notifications are needed, I think there are many use
cases, even simple ones, in which there is a lot of a benefit to dynamic
behavior.  I'm repeating myself from whatwg list, but even a calendar
reminder with a <select> for snooze delay is very useful.

 -John