<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=text/html;charset=iso-8859-1 http-equiv=Content-Type>
<META name=GENERATOR content="MSHTML 8.00.6001.18812"></HEAD>
<BODY style="PADDING-LEFT: 10px; PADDING-RIGHT: 10px; PADDING-TOP: 15px"
id=MailContainerBody leftMargin=0 topMargin=0 CanvasTabStop="true"
name="Compose message area">
<DIV><B>From:</B> <A title=johnnyg@google.com
href="mailto:johnnyg@google.com">John Gregg</A> </DIV>
<DIV style="FONT: 10pt Tahoma">
<DIV style="BACKGROUND: #f5f5f5">
<DIV><B>Sent:</B> Monday, August 10, 2009 2:34 PM<BR></DIV></DIV></DIV>
<DIV class=gmail_quote>
<BLOCKQUOTE
style="BORDER-LEFT: rgb(204,204,204) 1px solid; MARGIN: 0pt 0pt 0pt 0.8ex; PADDING-LEFT: 1ex"
class=gmail_quote>
<DIV style="PADDING-LEFT: 10px; PADDING-RIGHT: 10px; PADDING-TOP: 15px"
name="Compose message area">Michael Kozakewich wrote:<FONT size=2 face=Arial>
<BLOCKQUOTE
style="BORDER-LEFT: rgb(204,204,204) 1px solid; MARGIN: 0pt 0pt 0pt 0.8ex; PADDING-LEFT: 1ex"
class=gmail_quote>
<DIV style="PADDING-LEFT: 10px; PADDING-RIGHT: 10px; PADDING-TOP: 15px"
name="Compose message area"><FONT size=2 face=Arial>Are notifications really
a renderer problem, as opposed to a browser-UI problem? (e.g. 'Safari' or
'Chromium', rather than 'Webkit')</FONT>
<DIV><FONT size=2 face=Arial>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.</FONT></DIV></DIV></BLOCKQUOTE>
<DIV><BR></DIV></FONT>
<DIV><FONT size=2 face=Arial><FONT size=3 face="Times New Roman">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.<BR><BR>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.<BR> </FONT>
<BLOCKQUOTE
style="BORDER-LEFT: rgb(204,204,204) 1px solid; MARGIN: 0pt 0pt 0pt 0.8ex; PADDING-LEFT: 1ex"
class=gmail_quote>
<DIV style="PADDING-LEFT: 10px; PADDING-RIGHT: 10px; PADDING-TOP: 15px"
name="Compose message area">
<DIV><FONT size=2 face=Arial>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.)</FONT></DIV>
<DIV><FONT size=2 face=Arial>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?</FONT></DIV></DIV></BLOCKQUOTE>
<DIV><FONT size=2 face=Arial></FONT><FONT size=2 face=Arial></FONT><BR>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.<BR></DIV>
<BLOCKQUOTE
style="BORDER-LEFT: rgb(204,204,204) 1px solid; MARGIN: 0pt 0pt 0pt 0.8ex; PADDING-LEFT: 1ex"
class=gmail_quote>
<DIV style="PADDING-LEFT: 10px; PADDING-RIGHT: 10px; PADDING-TOP: 15px"
name="Compose message area"><FONT size=2 face=Arial>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.</FONT>
<DIV><FONT size=2 face=Arial>(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.)</FONT></DIV></DIV></BLOCKQUOTE><BR>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.<BR><BR> -John</FONT></DIV></DIV></BLOCKQUOTE>
<DIV><FONT size=2 face=Arial></FONT> </DIV>
<DIV><FONT size=2 face=Arial>For some reason, I seemed to forget that the call
would be made through JavaScript in either case.</FONT></DIV>
<DIV><FONT size=2 face=Arial></FONT> </DIV>
<DIV><FONT size=2 face=Arial>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?)
</FONT></DIV>
<DIV><FONT size=2 face=Arial></FONT> </DIV>
<DIV><FONT size=2 face=Arial>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.</FONT></DIV>
<DIV><FONT size=2 face=Arial>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.</FONT></DIV>
<DIV><FONT size=2 face=Arial>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.</FONT></DIV>
<DIV><FONT size=2 face=Arial></FONT> </DIV>
<DIV><FONT size=2 face=Arial>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.</FONT></DIV></DIV></BODY></HTML>