Michael Kozakewich wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div style="padding-left: 10px; padding-right: 10px; padding-top: 15px;" name="Compose message area">
<div><font face="Arial" size="2">Are notifications really a renderer problem, as opposed to a
browser-UI problem? (e.g. 'Safari' or 'Chromium', rather than
'Webkit')</font></div>
<div><font face="Arial" size="2">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><font face="Arial" size="2"></font></div></div></blockquote><div><br>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>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div style="padding-left: 10px; padding-right: 10px; padding-top: 15px;" name="Compose message area">
<div><font face="Arial" size="2">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 face="Arial" size="2">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><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>
<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div style="padding-left: 10px; padding-right: 10px; padding-top: 15px;" name="Compose message area">
<div><font face="Arial" size="2"></font></div>
<div><font face="Arial" size="2">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>
<div><font face="Arial" size="2">(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></div><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<br>