Re: Notifications

On Fri, Feb 5, 2010 at 6:52 AM, Anne van Kesteren <annevk@opera.com> wrote:

> On Thu, 04 Feb 2010 00:36:26 +0100, John Gregg <johnnyg@google.com> wrote:
>
>> I'm familiar with that version of the proposal (in fact my WHATWG proposal
>> from March '09 had the same language: untrusted notifications displayed
>> in-browser), but considering it more I think it is too limiting.
>> Considering widgets, mobile browsers, browser extensions, workers (already
>> in the spec), etc., which all might want to use this API, it's potentially
>> many different forms of UI for untrusted notifications---where do they go,
>> how is it clear where they came from?  Compare that to a single place
>> outside the browser, with a clear source displayed, once trust is
>> established.  I prefer the
>> latter.
>>
>
> You probably need different permission UI regardless. E.g. on mobile
> browsers you might not show the notification in-tab but would only something
> if the user did something in response to a dialog.
>
>
> 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.



>
>  In the case the first notification from an application is an important
>> one,
>> that app should be able to request permission for out-of-tab notifications
>> beforehand;
>>
>
> Aren't notifications by nature somewhat non-important? In any event, we
> could expose to the application whether or not it was displayed and if it
> was not the application could pick an alternative route to convey the
> information.
>
>
I'd say exactly the opposite - that's why we proactively display them to the
user rather than leave them passively within the page waiting for the user
to go look at them.


>
>
>  for that reason I'm convinced requestPermission() is desirable.
>> However beyond that, perhaps the spec should be flexible; if a UA wants to
>> treat PERMISSION_UNKNOWN as "show in-tab" rather than "throw exception", the
>> spec could allow it -- but I don't think it should require it.  Would that
>> be acceptable?
>>
>
> 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"). 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.


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