Re: Notifications

On Wed, Feb 3, 2010 at 1:22 PM, Anne van Kesteren <annevk@opera.com> wrote:

> On Wed, 03 Feb 2010 18:55:32 +0100, Olli Pettay <Olli.Pettay@helsinki.fi>
> wrote:
>
>> some random comments about
>> http://dev.w3.org/2006/webapi/WebNotifications/publish/
>> (I didn't know that the draft existed until the link was mentioned
>>  in an email to @whatwg mailing list :/ )
>>
>
> Some other thoughts on this API:
>
> * It would be nice if we could avoid the exception somehow. Maybe just have
> an error callback?
>
>
I thought that in practice the exception was reasonable, specifically
because the exception is entirely avoidable because you can check permission
before calling any protected APIs. I would rather have an explicit failure
in case of bugs (and calling createNotification() without getting permission
first is a bug) rather than a silent failure. Perhaps I'm misunderstanding
what you are suggesting - are you talking about the exception thrown from
requestPermission() or the exception thrown from createNotification()?


> * I'm not a big fan of introducing two new ways to load resources as
> proposed in this API. We are not doing that elsewhere either (consider e.g.
> drawImage()). Passing a Document and HTMLImageElement (potentially
> HTMLCanvasElement and HTMLVideoElement too I suppose) would make more sense.
> This does create some additional burden on the developer but it does keep
> security-sensitive operations more limited and also gives the ability for
> greater control and information. (E.g. with XMLHttpRequest you get to know
> how fast the resource is being fetched, etc.) Libraries could provide the
> higher-level API.


I see createHTMLNotification() as akin to window.open() - it doesn't really
increase the attack surface. I'm not sure I completely understand the
suggestion of passing in a Document object - what would that API look like?

Since an HTML notification is (effectively) a separate window, it just seems
like tracking progress for the loading of resources is a solved problem for
app developers - Gmail displays a loading bar while its window loads. I
suspect I'm not understanding your use case entirely though.


> * If we keep checkPermission() it should not be a method. But I'm not sure
> it is needed if there is an error callback.


I think that we need some way to get the current permission but I agree that
an attribute would be better than an API call. I'm not sure that an error
callback from createNotification() is sufficient as you generally want to
initiate the permission grant *in advance* of displaying notifications. As
an example, allow me to describe the following use case:

A web mail program would like to display desktop notifications when new mail
arrives. Because UAs require calls to requestPermission() to be in the
context of a user gesture, I need to display some UI along the lines of
"click here to enable desktop notifications for new mail", which, when
clicked upon, results in the web app calling requestPermission() to initiate
the permission grant from the UA. I only want to display this UI if the user
has not already been granted/denied permission (once he's responded to the
permission grant dialog, I no longer want to display this UI in future loads
of the program). Without a checkPermission()-type API (or "permission"
attribute) there's no way for me to achieve this user flow.


>
>
>
> --
> Anne van Kesteren
> http://annevankesteren.nl/
>
>