W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2010

Re: Notifications

From: Anne van Kesteren <annevk@opera.com>
Date: Fri, 05 Feb 2010 19:36:40 +0100
To: "Drew Wilson" <atwilson@google.com>
Cc: "John Gregg" <johnnyg@google.com>, Olli@pettay.fi, public-webapps <public-webapps@w3.org>
Message-ID: <op.u7n3beaw64w2qv@annevk-t60>
On Fri, 05 Feb 2010 19:19:24 +0100, Drew Wilson <atwilson@google.com>  
wrote:
> I've thought about this some more, and I'm not at all convinced that  
> in-tab notification support is the right way to go. It seems that in-tab
> notifications are a solved problem already (in a few lines of code an app
> can create a floating div with whatever content it desires) with the
> advantage that the web app can display that notification in a way that is
> consistent with the UI in the site (set the notification so as not to
> interfere with site content, appropriately style the notification so it  
> fits in with the look of the site, etc). I don't quite understand what
> browser-provided in-tab notifications would provide that would be an
> improvement over existing functionality.

Allowing them to be displayed there and not having an active permission  
dialog would make it totally opaque to the application whether or not it  
can do system-wide notifications. This seems better for privacy and I also  
think it makes it less likely the user opts into something the user does  
not want.


>> I'm not convinced we need a permission API and would therefore rather  
>> leave it out to see if we can do without. We do not have an API like  
>> this anymore else.
>
> We do have permissions UI in other parts of HTML5 (geolocation, for
> example). The difference here is that applications generally would like  
> the user to make a permission grant *before* they actually want to  
> display a
> notification - actually waiting until it's time to display a calendar
> reminder before the user is prompted for permission means that the user  
> is likely to miss that first calendar event.
>
> One possible alternative to an explicit requestPermission() API would be  
> to instead just have the browser display permissions UI the first time  
> the user calls createNotification(). An application that wants to get  
> permission in advance could just call createNotification(), but then  
> never actually call show() (or, perhaps they could just display a  
> confirmation notification like "Desktop notifications are now enabled  
> for FooMail").

This sounds somewhat better to me.


> As someone who has
> integrated notifications into a web app, I have to say that I found the
> explicit API useful, but I'm not currently using the callback for
> requestPermission() so an alternate API could work so long as there was  
> some way to initiate a permission grant without actually displaying a
> notification.

I'm still a little bit afraid of what's going to happen when we get many  
of these APIs that need some kind of user permission. It's going to be too  
confusing I think.


-- 
Anne van Kesteren
http://annevankesteren.nl/
Received on Friday, 5 February 2010 18:37:27 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:36 GMT