On Fri, 05 Feb 2010 19:19:24 +0100, Drew Wilson <atwil...@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/
