- From: Drew Wilson <atwilson@google.com>
- Date: Wed, 3 Feb 2010 15:09:10 -0800
- To: Anne van Kesteren <annevk@opera.com>
- Cc: John Gregg <johnnyg@google.com>, Olli@pettay.fi, public-webapps <public-webapps@w3.org>
- Message-ID: <f965ae411002031509t67b5d830lc2375a86899de66@mail.gmail.com>
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. -atw
Received on Wednesday, 3 February 2010 23:09:41 UTC