cr: clelland

spec/controlling-tasks.md

@@ -2,7 +2,7 @@
 
 Tasks scheduled through the {{Scheduler}} interface can be controlled with a {{TaskController}} by
 passing the {{TaskSignal}} provided by {{AbortController/signal|controller.signal}} as the
-{{SchedulerPostTaskOptions/signal|option}} when calling {{Scheduler/postTask()}}.  The
+{{SchedulerPostTaskOptions/signal|option}} when calling {{Scheduler/postTask()}}. The
 {{TaskController}} interface supports aborting and changing the priority of a task or group of
 tasks.
 

spec/patches.md

@@ -29,7 +29,7 @@ associated with a specific [=task queue=].
 Add the following steps to the event loop processing steps, before step 1:
 
   1. Let |queues| be the [=set=] of the [=event loop=]'s [=task queues=] that contain at least one
-     <a for="task">runnable</a> <a for="/">task</a>.
+     [=task/runnable=] [=task=].
   1. Let |schedulers| be the [=set=] of all {{Scheduler}} objects whose [=relevant agent's=]
      [=agent/event loop=] is this event loop and that [=have a runnable task=].
   1. If |schedulers| and |queues| are both [=list/empty=], skip to the <code>microtasks</code> step
@@ -47,4 +47,4 @@ Modify step 1 to read:
 Issue: The |taskQueue| in this step will either be a [=set=] of [=tasks=] or a [=set=] of
 [=scheduler tasks=]. The steps that follow only [=set/remove=] an [=set/item=], so they are
 *roughly* compatible. Ideally, there would be a common task queue interface that supports a `pop()`
-method that would return a plain [=task=], but that would invlove a fair amount of refactoring.
+method that would return a plain [=task=], but that would involve a fair amount of refactoring.