From: John Gregg
Sent: Monday, August 10, 2009 2:34 PM
Michael Kozakewich wrote:
Are notifications really a renderer problem, as opposed to a browser-UI
problem? (e.g. 'Safari' or 'Chromium', rather than 'Webkit')
Also, I don't know of any notifications (Outlook, Messenger, AVG,
TweetDeck, etc.) that require permissions, so I'd argue that requiring
permissions for notification would be arguably confusing. It doesn't interrupt
flow like alert() does.
It's not a renderer 'problem'; the code that would go in WebKit is just to
define the API and some basic logic about events flowing back and forth. More
work is certainly necessary beyond that (code which I am also writing for
Chromium). The idea is that there be a standard notification API which apps
can write to and expect the intuitive thing to happen according to the user
agent & platform: on Mac these may go to Growl, on Linux to libnotify, on
Windows to toasts on the screen, on Mobile to something specific for the
device, etc.
I think there's a big difference in expectations for an installed native app
like those in your list versus a web page. The user grants broad permission
when they install an app like that, but when they visit a web page the
expectation is very different. The fact that it's not modal like an alert could
even make it more necessary to secure: do you want an evil site to spam your
desktop with an unbounded # of toasts? Again, I'm talking about a
notifications API which is independent of the "installed web app" idea also
being discussed in this thread. It certainly might make sense that if there is
a way to install a web app in some form with a permissions step, notifications
could piggyback on that to avoid confusing prompts.
Just in case I need to be set straight, here, I've got a couple questions:
If vendors implemented this, they would have to work on their browsers, right?
Is it easier for them to work on the rendering engine or on the application, or
is there no difference? Do they prefer to add functionality to their rendering
engine or to their application, or do they not care? (For these, I'm working
from the assumption that it doesn't noticeably affect the UI, such as a new
button or bar would.)
And last: do they try not to touch the browsers, or do they prefer to
delegate upgrades based on where they would be most suitable?
I'm not sure I follow the question, but I think it depends on the
architecture of the particular browser. Based on what I've proposed, a browser
maker would need to build all the pieces necessary to go from script executing
"notification.show()" to getting something on the screen.
I think answering those questions would help me the most, because at this
point I don't know why they'd alter the renderer or JS engine to handle popup
JavaScript instead of altering the browser to support what seems like a simple
UI addition of pop-ups, but I do feel as though they wouldn't like to change
the browser process.
(As a final point, it's been mentioned that such a feature would become
very popular, so many sites would implement it. It begs the question of which
option is best for handling the volume of notifications and potentially abused
notifications.)
Handling the volume falls on the browser or on the presenter of notifications
that the browser may might choose to delegate to (like Growl). I would think
queuing based on available space is a reasonable start. Handling potential
abuse is exactly why a permissions model is part of the proposal.
-John
For some reason, I seemed to forget that the call would be made through
JavaScript in either case.
I only briefly touched on the idea of 3rd-party apps like feed-readers, because
I'm really not enamored with the idea. My main thought was that the browser
itself would have a notifications process that would be subscribed to, and then
the tabs could post messages to it. The browser would police that. (It could
automatically register the tab as the first post method was sent, and
unregister when that tab was closed). I don't believe such a process would have
inherent security concerns, if the process was thought out (all it needs is
presentation/layout). In this way, you wouldn't need to install the app to use
notifications. I just wonder about policing (give a little notification, like
when pop-ups are blocked, with option allowing notifications for the whole
site? +Whitelisting?)
I admit I worded the browser/renderer questions horribly. I meant the
difference of using JavaScript to pop up an HTML message, with a bit of help
from the browser; as compared to posting to the browser with JavaScript and
having the browser pop up a message with its own (themeable) UI, like what one
might expect from an extension. Both need everything to work together, but they
have different focuses.
I'd imagine (from other WHATWG discussion) the HTML version would have
scripting, as if it were another page, and it would be designed with images and
CSS. It could have links and such, too. Not secure.
I'd imagine the Browser version having a themeable-but-consistent notification
UI that would simply serve to inform the user of (and, by default, onClick set
focus to) a tab with new data.
Most of the last paragraph of my previous email can just be ignored. I think I
had completely forgotten about the API, or how code ties into the structure of
the browser.
