- 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