Add principles for task sources

index.bs

@@ -2327,6 +2327,32 @@ See also:
 
 * [Command–query separation on Wikipedia](https://en.wikipedia.org/wiki/Command–query_separation)
 
+<h3 id="prefer-existing-task-sources">Prefer existing task sources; mint new ones only for clear, spec-driven reasons</h3>
+Specs use [=task sources=] to group related work (or "[=tasks=]") so UAs can schedule them sensibly.
+A task is queued on a task source,
+and each task source is associated with a task queue for an [=event loop=].
+Order is guaranteed within a source, while the UA chooses which queue to service next.
+
+Use the generic or preexisting task sources whenever possible.
+HTML defines [[html#generic-task-sources|generic task sources]] meant for broad reuse across specs.
+This includes, but is not limited to:
+the [=DOM manipulation task source=],
+the [=user interaction task source=],
+and the [=networking task source=].
+If your feature matches one of these categories,
+queue on that source rather than creating a new one.
+Doing so improves interoperability, predictability, and performance scheduling across the platform.
+
+Only mint a new task source when you have a concrete, testable need.
+For example, when the feature's timing/execution model must be isolated
+from the generic task sources
+(e.g., media elements get their own media element event task source to align with decoder/timeline semantics).
+
+When writing a spec, prefer HTML's wrapper algorithms
+([=queue a global task=], [=queue an element task=])
+and avoid relying on a particular [=event loop=].
+And only be explicit about the event loop when appropriate (see [[#event-design]]).
+
 <h2 id="event-design">Event Design</h2>
 
 <h3 id="one-time-events">Use promises for one time events</h3>