<!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',&nbsp;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.&nbsp; More work is 
  certainly necessary beyond that (code which I am also writing for 
  Chromium).&nbsp; 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 &amp; 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.&nbsp; 
  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?&nbsp; 
  Again, I'm talking about a notifications API which is independent of the 
  "installed web app" idea also being discussed in this thread.&nbsp; 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>&nbsp;</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&nbsp;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&nbsp;renderer or JS engine&nbsp;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).&nbsp; I would think queuing based on 
  available space is a reasonable start.&nbsp; Handling potential abuse is 
  exactly why a permissions model is part of the 
  proposal.<BR><BR>&nbsp;-John</FONT></DIV></DIV></BLOCKQUOTE>
<DIV><FONT size=2 face=Arial></FONT>&nbsp;</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>&nbsp;</DIV>
<DIV><FONT size=2 face=Arial>I only briefly touched on the idea of 3rd-party 
apps like feed-readers, because I'm&nbsp;really not enamored with the idea. My 
main&nbsp;thought was that the browser itself would have a 
notifications&nbsp;process that would be subscribed to, and then the tabs could 
post messages to it. The browser would police that. (It could&nbsp;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>&nbsp;</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&nbsp;discussion)&nbsp;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&nbsp;the Browser version&nbsp;having a 
themeable-but-consistent notification UI that would simply serve to inform the 
user of&nbsp;(and, by default, onClick set focus to) a tab with new 
data.</FONT></DIV>
<DIV><FONT size=2 face=Arial></FONT>&nbsp;</DIV>
<DIV><FONT size=2 face=Arial>Most of&nbsp;the last paragraph&nbsp;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>