Re: Notifications

I'm not entirely certain I understand this suggestion - is this just a
change to the spec language, or does it impact the actual API (i.e. would
webapps still do the following):

if ('createHTMLNotifications' in window.notifications) {
    ...html notifications exist...
}

Or are you proposing something else?

Since these APIs are available in Chrome currently (as the experimental
window.webkitNotifications API), there's no reason for us to debate the
utility of HTML notifications in the abstract when we can get feedback from
application developers with real use cases. I've been running into some of
the limitations of the text + icon notifications in my recent work (one
example: the lack of an onclick event) which I'll try to write up sometime
in the near future.

-atw

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.)
>
>
>
> --
> Anne van Kesteren
> http://annevankesteren.nl/
>