I circulated a proposal several weeks ago which specified a notifications API for workers (desktop toasts), and the feedback was that (a) persistent workers are still far away, (b) is a notifications api necessary given it&#39;s basically a new window?, and (c) have we thought through the security issues? (<a href="https://bugs.webkit.org/show_bug.cgi?id=25463" target="_blank">https://bugs.webkit.org/show_bug.cgi?id=25463</a>)   I&#39;ve tried to answer these questions but some points have remained sticky, so I&#39;m reaching out again in search of consensus.<br>

<br>As far as workers go, I&#39;ve modified the proposal (and patch) to attach the notifications object to DOMWindow as well as WorkerContext, so that both regular pages can access it as well and this is not worker-specific.<br>
<br>On the security question, a substantial amount of thought has gone into how to prevent unwanted popups (and in general how to control access to HTML5 application features).  We think user opt-in on an origin-basis is the best policy and it&#39;s what we plan to do in Chromium; the WebKit interfaces are structured so that the policy is up to the user agent via a NotificationProvider interface.<br>

<br>The API &amp; use case question seems to be the big one remaining open.  On the use case front, there are several Google products interested in using it (Calendar reminders, Gmail alerts, etc.)  We also see Mozilla Jetpack demoing an API very similar to the one I&#39;ve proposed in their recent release.  So I think there is plenty of reason to believe this feature would be used to greatly enhance applications.<br>

<br>Last, if the feature is included should the interface be <i>window.notifications.create</i>() -- my proposal (also Jetpack&#39;s API) -- or <i>window.open</i>(&quot;style=notification&quot;), the alternate suggestion?  Here are my thoughts supporting the former:<br>
<ul><li>Notifications will evolve: the first generation is text+icon only, the second generation is small HTML bubbles, maybe something else later.  While small HTML bubbles might align well with window.open, text+icon toasts don&#39;t.  For some platforms we can get both, for some only the simple form.  Logically what an app developer will do is check what notification options are available on the platform, then use the most full-featured option available.  This check should be easy to do, and the result shouldn&#39;t send them to different existing APIs to find the closest match, if we can help it.  I think providing a notifications object to encapsulate the feature makes more sense.  </li>
<li>Opening a new window for an HTML notification is only one possible implementation.  In the future (or now) a user agent may want to toast up the HTML block on the taskbar, or in a corner of an existing tab, or append it to a stream in a dedicated notification panel.  Semantically the service provided to the app developer is &quot;alert the user using the HTML at this URL&quot;, and defining the interface to match gives us the most flexibility to implement in the future without being tied to a particular existing notion.<br>
</li></ul>Other thoughts?  <br><br>Thanks, <br>-John<br><br><br>