Re: Notifications

On Wed, Feb 3, 2010 at 3:09 PM, Drew Wilson <atwilson@google.com> wrote:
>
> On Wed, Feb 3, 2010 at 2:50 PM, Anne van Kesteren <annevk@opera.com>wrote:
>
>> On Wed, 03 Feb 2010 23:40:23 +0100, John Gregg <johnnyg@google.com>
>> wrote:
>>
>>> Yes, this makes sense; I am changing the draft spec to have a
>>> permissionLevel attribute.  I think having access to the permission level
>>> is important for the same reasons as Drew gave: the site should know whether
>>> to display permissions UI in advance of having a notification to show.
>>>
>>
>> The design Hixie once made for notifications was much nicer I thought.
>> Initially you would get tab-scoped in-browser notifications but the user
>> could opt-in (maybe when the first of such notifications was shown) into
>> system-wide notifications. The application would not have to know either way
>> and the user is not forced to click through permission dialog in order to
>> see something.
>>
>> It's still available in one of the older copies of HTML5:
>> http://www.w3.org/TR/2008/WD-html5-20080610/web-browsers.html#notifications
>>
>>
> That's an interesting option (fallback to in-tab display if the parent
> context does not have permission). BTW, I'd note that supporting this would
> not preclude continuing to provide a way for an app to explicitly request a
> permission grant, as a way for guiding users to setup the app as a trusted
> notification source. The alternative would be for applications to have
> UA-specific directions directing the user to click on specific items in the
> UA chrome ("If you want new mail notifications to appear on your desktop,
> click on the smiley face in the notification titlebar") which is a more
> clunky user flow.
>
>
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.

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; 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?

 -John