On Thu, 04 Feb 2010 00:36:26 +0100, John Gregg <john...@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.
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.
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.
--
Anne van Kesteren
http://annevankesteren.nl/
