Skip to content

Commit

Permalink
[e] (0) Remove the commented-out notification API.
Browse files Browse the repository at this point in the history
git-svn-id: http://svn.whatwg.org/webapps@2896 340c8d12-0b0e-0410-8428-c7bf67bfef74
  • Loading branch information
Hixie committed Mar 24, 2009
1 parent 56b5ab5 commit 49c7b42
Show file tree
Hide file tree
Showing 2 changed files with 4 additions and 430 deletions.
213 changes: 2 additions & 211 deletions index
Expand Up @@ -39,7 +39,7 @@
<div class=head>
<p><a class=logo href=http://www.whatwg.org/ rel=home><img alt=WHATWG src=/images/logo></a></p>
<h1>HTML 5</h1>
<h2 class="no-num no-toc" id=draft-recommendation-&mdash;-date:-01-jan-1901>Draft Recommendation &mdash; 23 March 2009</h2>
<h2 class="no-num no-toc" id=draft-recommendation-&mdash;-date:-01-jan-1901>Draft Recommendation &mdash; 24 March 2009</h2>
<p>You can take part in this work. <a href=http://www.whatwg.org/mailing-list>Join the working group's discussion list.</a></p>
<p><strong>Web designers!</strong> We have a <a href=http://blog.whatwg.org/faq/>FAQ</a>, a <a href=http://forums.whatwg.org/>forum</a>, and a <a href=http://www.whatwg.org/mailing-list#help>help mailing list</a> for you!</p>
<dl><dt>Multiple-page version:</dt>
Expand Down Expand Up @@ -17829,18 +17829,6 @@ href="?audio"&gt;audio&lt;/a&gt; test instead.)&lt;/p&gt;</pre>

</dd>

<!-- XXX-NOTIFY
<dt>The <dfn>sandboxed annoyances browsing context flag</dfn></dt>

<dd>

<p>This flag prevents content from <a
href="#sandboxNotifications">showing notifications</a> outside of
the <span>nested browsing context</span>.</p>

</dd>
-->


<dt>The <dfn id=sandboxed-origin-browsing-context-flag>sandboxed origin browsing context flag</dfn>, unless
the <code title=attr-iframe-sandbox><a href=#attr-iframe-sandbox>sandbox</a></code> attribute's
Expand Down Expand Up @@ -38838,8 +38826,7 @@ interface <dfn id=window>Window</dfn> {
boolean <a href=#dom-confirm title=dom-confirm>confirm</a>(in DOMString message);
DOMString <a href=#dom-prompt title=dom-prompt>prompt</a>(in DOMString message, [Optional] in DOMString default);
void <a href=#dom-print title=dom-print>print</a>();
any <a href=#dom-showmodaldialog title=dom-showModalDialog>showModalDialog</a>(in DOMString url, [Optional] in any argument<!--, [Optional] in DOMString features-->);<!-- XXX-NOTIFY
void <span title="dom-showNotification">showNotification</span>(in DOMString title, in DOMString subtitle, in DOMString description, [Optional] in VoidCallback onclick);-->
any <a href=#dom-showmodaldialog title=dom-showModalDialog>showModalDialog</a>(in DOMString url, [Optional] in any argument<!--, [Optional] in DOMString features-->);

// <a href=#crossDocumentMessages>cross-document messaging</a>
void <a href=#dom-window-postmessage-2 title=dom-window-postMessage-2>postMessage</a>(in any message, in DOMString targetOrigin);
Expand Down Expand Up @@ -41374,202 +41361,6 @@ interface <dfn id=function>Function</dfn> {
close the browsing context.</p>


<!-- XXX-NOTIFY
<h4>Notifications</h4>

<!- - v2 feature requests:

- ability to snooze a notification so it comes again later
- shouldn't be on all messages, only those for which it makes
sense
- possibly just provide a new argument that takes an array of
(label, callback) tuples so that sites can implement this
themselves
- full HTML notifications

- ->

<p>Notifications are short, transient messages that bring the user's
attention to new information, or remind the user of scheduled
events.</p>

<p>Since notifications can be annoying if abused, this specification
defines a mechanism that scopes notifications to a site's existing
rendering area unless the user explicitly indicates that the site
can be trusted.</p>

<p>To this end, each <span>origin</span> can be flagged as being a
<dfn>trusted notification source</dfn>. By default origins should
not be flagged as such, but user agents may allow users to whitelist
origins or groups of origins as being <span title="trusted
notification source">trusted notification sources</span>. Only
origins flagged as trusted in this way are allowed to show
notification UI outside of their tab.</p>

<p class="example">For example, a user agent could allow a user to
mark all subdomains and ports of example.org as trusted
notification sources. Then, mail.example.org and
calendar.example.org would both be able to show notifications,
without the user having to flag them individually.</p>

<p>The <dfn title="dom-showNotification"><code>showNotification(<var
title="">title</var>, <var title="">subtitle</var>, <var
title="">description</var>, <var
title="">onclick</var>)</code></dfn> method, when invoked, must
cause the user agent to show a notification.</p>

<p id="sandboxNotifications">If the method was invoked from a <span
title="concept-script">script</span> whose <span title="script's
browsing context">browsing context</span> has the <span>sandboxed
annoyances browsing context flag</span> set, then the notification
must be shown within that <span>browsing context</span>. The
notification is said to be a <dfn>sandboxed notification</dfn>.</p>

<p>Otherwise, if the <span>origin</span> of the <span
title="script's browsing context">browsing context</span> of the
<span title="concept-script">script</span> that invoked the method
is <em>not</em> flagged as being a <span>trusted notification
source</span>, then the notification should be rendered within the
<span>top-level browsing context</span> of the <span>script's
browsing context</span>. The notification is said to be a
<dfn>normal notification</dfn>. User agents should provide a way to
set the origin's <span>trusted notification source</span> flag from
the notification, so that the user can benefit from notifications
even when the user agent is not the active application.</p>

<p>Otherwise, the <span>origin</span> is flagged as a <span>trusted
notification source</span>, and the notification should be shown
using the platform conventions for system-wide notifications. The
notification is said to be a <dfn>trusted notification</dfn>. User
agents may provide a way to unset the origin's <span>trusted
notification source</span> flag from within the notification, so as
to allow users to easily disable notifications from sites that abuse
the privilege.</p>

<div class="example">

<p>For example, if a site contains a gadget of a mail application
in a sandboxed <code>iframe</code> and that frame triggers a
notification upon the receipt of a new e-mail message, that
notification would be displayed on top of the gadget only.</p>

<p>However, if the user then goes to the main site of that mail
application, the notification would be displayed over the entire
rendering area of the tab for the site.</p>

<p>The notification, in this case, would have a button on it to let
the user indicate that he trusts the site. If the user clicked this
button, the next notification would use the system-wide
notification system, appearing even if the tab for the mail
application was buried deep inside a minimised window.</p>

</div>

<div class="example">

<p>The style of notifications varies from platform to platform. On
some, it is typically displayed as a "toast" window that slides in
from the bottom right corner. In others, notifications are shown as
semi-transparent white-on-grey overlays centered over the
screen. Other schemes could include simulated ticker tapes, and
speech-synthesis playback.</p>

</div>

<p>When a <span>normal notification</span> (but not a
<span>sandboxed notification</span>) is shown, the user agent may
bring the user's attention to the <span>top-level browsing
context</span> of the <span title="script's browsing
context">browsing context</span> of the <span
title="concept-script">script</span> that invoked the method, if
that would be useful; but user agents should not use system-wide
notification mechanisms to do so.</p>

<p>When a <span>trusted notification</span> is shown, the user agent
should bring the user's attention to the notification and the <span
title="script's browsing context">browsing context</span> of the
<span title="concept-script">script</span> that invoked the method,
as per the platform conventions for attracting the user's attention
to applications.</p>

<div class="example">

<p>In the case of <span title="normal notification">normal
notifications</span>, typically the only attention-grabbing device
that would be employed would be something like flashing the tab's
caption, or making it bold, or some such.</p>

<p>In addition, in the case of a <span>trusted notification</span>,
the entire window could flash, or the browser's application icon
could bounce or flash briefly, or a short sound effect could be
played.</p>

</div>

<p>Notifications should include the following content:</p>

<ul>

<li>The <var title="">title</var>, <var title="">subtitle</var>,
and <var title="">description</var> strings passed to the
method. They may be truncated or abbreviated if necessary.</li>

<li>The <span title="meta-application-name">application
name</span>, if available, or else the <span
title="dom-document-title">document title</span>, of the
<span>active document</span> of the <span title="script's browsing
context">browsing context</span> of the <span
title="concept-script">script</span> that invoked the method.</li>

<li>An icon chosen from the <span title="external resource
link">external resource links</span> of type <code
title="rel-icon">icon</code>, if any are available.</li>

</ul>

<p>If a new notification from one <span>browsing context</span> has
<var title="">title</var>, <var title="">subtitle</var>, and <var
title="">description</var> strings that are identical to the <var
title="">title</var>, <var title="">subtitle</var>, and <var
title="">description</var> strings of an already-active notification
from the same <span>browsing context</span> or another <span
title="browsing context">browsing context</span> with the same
<span>origin</span>, the user agent should not display the new
notification, but should instead add an indicator to the
already-active notification that another identical notification
would otherwise have been shown.</p>

<div class="example">

<p>For instance, if a user has his mail application open in three
windows, and thus the same "New Mail" notification is fired three
times each time a mail is received, instead of displaying three
identical notifications each time, the user agent could just show
one, with the title "New Mail x3".</p>

</div>

<p>Notifications should have a lifetime based on the platform
conventions for notifications. However, the lifetime of a
notification should not begin until the user has had the opportunity
to see it, so if a notification is spawned for a <span>browsing
context</span> that is hidden, it should be shown for its complete
lifetime once the user brings that <span>browsing context</span>
into view.</p>

<p>User agents should support multiple notifications at once.</p>

<p>User agents should support user interaction with notifications,
if and as appropriate given the platform conventions. If a user
activates a notification, and the <var title="">onclick</var>
callback argument was present and is not null, then the <span
title="script's browsing context">browsing context</span> of the
<span title="concept-script">script</span> of the function given by
<var title="">onclick</var> should be brought to the user's
attention, and the <var title="">onclick</var> callback should then
be invoked.</p>

-->


<h3 id=system-state-and-capabilities><span class=secno>5.7 </span>System state and capabilities</h3>
Expand Down

0 comments on commit 49c7b42

Please sign in to comment.