- From: Jeffrey Yasskin <notifications@github.com>
- Date: Thu, 06 Apr 2017 11:52:27 -0700
- To: whatwg/dom <dom@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <whatwg/dom/pull/434/review/31369521@github.com>
jyasskin commented on this pull request.
> +
+ ...
+
+ controller.cancel();
+ </pre>
+
+ APIs that require more granular control could extend both {{CancellationController}} and
+ {{CancellationSignal}} according to their needs.
+</div>
+
+<h3 id=interface-cancellationcontroller>Interface {{CancellationController}}</h3>
+
+<pre class="idl">
+[Constructor(), Exposed=(Window,Worker)]
+interface CancellationController {
+ readonly attribute CancellationSignal signal;
[SameObject], right?
> +[Exposed=(Window,Worker)]
+interface CancellationSignal : EventTarget {
+ readonly attribute boolean cancelled;
+
+ attribute EventHandler oncancel;
+};
+</pre>
+<dl class=domintro>
+ <dt><code><var>signal</var> . </code>{{CancellationSignal/cancelled}}
+ <dd>Returns true if this {{CancellationSignal}} has been cancelled, and false otherwise.
+</dl>
+
+Each {{CancellationSignal}} has an <dfn for=CancellationSignal>cancelled flag</dfn> which is
+unset unless otherwise specified.
+
+Each {{CancellationSignal}} has an <dfn for=CancellationSignal>cancellation steps</dfn> algorithm
This might need to be passed in through the creation of the CancelattionController. We'll see what works in prose once FetchController is specified using this.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/dom/pull/434#pullrequestreview-31369521
Received on Thursday, 6 April 2017 18:53:05 UTC