diff --git a/index.bs b/index.bs
index ebcf1fb3..d11768f9 100644
--- a/index.bs
+++ b/index.bs
@@ -1068,6 +1068,8 @@ Consider adding such features only in cases when the overall user experience is
A canonical example of this is blocking rendering in order to download and process a stylesheet.
The alternative user experience is a flash of unstyled content, which is undesirable.
+See also [[#worker-only]].
+
Keep attributes in sync
New content attributes
@@ -2680,21 +2682,59 @@ offers guidance that should be considered in the development of new features, no
* [[#feature-detect]]
* Polyfill development should be encouraged
-Where possible APIs should be made available in DedicatedWorker
+Where possible APIs should be made available to dedicated workers
When exposing a feature, please consider whether it makes sense to expose the feature
-to DedicatedWorker as well.
+to dedicated workers (via the {{DedicatedWorkerGlobalScope}} interface).
-Many features could work out of the box on a DedicatedWorker and not enabling the feature
-there could limit the ability for users to run their code in a non blocking manner.
+Many features could work out of the box on dedicated workers and not enabling the feature
+there could limit the ability for users to run their code in a non-blocking manner.
-Certain challenges can exist when trying to enable a feature on DedicatedWorker,
+Certain challenges can exist when trying to expose a feature to dedicated workers,
especially if the feature requires user input by asking for permission,
or showing a picker or selector.
-Even though this might discourage spec authors to support workers,
-we still recommend designing the feature with DedicatedWorker support in mind,
+Even though this might discourage spec authors to support dedicated workers,
+we still recommend designing the feature with dedicated worker support in mind,
in order to not add assumptions that will later make it unnecessarily hard to expose
-these APIs to DedicatedWorker.
+these APIs to dedicated workers.
+
+Some APIs should only be exposed to dedicated workers
+
+
+Developers prefer simple code to complex code.
+They are more likely
+to use an API
+in the simplest way the API allows.
+
+It’s important to avoid adding features that block rendering. [[#avoid-render-blocking]]
+
+If the easiest way to use an API
+is likely to result in render blocking or “[jank](https://developer.mozilla.org/en-US/docs/Glossary/Jank),”
+the user experience will suffer.
+(This problem is even more pronounced on low-powered devices,
+which are more likely to be used by disadvantaged or marginalized users.
+Remember,
+[the web is for all people](https://www.w3.org/2001/tag/doc/ethical-web-principles/#allpeople).)
+
+Therefore,
+APIs which would often block the main thread if used as intended
+should not be exposed on the {{Window}} interface.
+By restricting such APIs to the {{DedicatedWorkerGlobalScope}} interface,
+the “easy” path for web developers
+is the path with the best experience for users.
+
+
+{{ScriptProcessorNode}}s were replaced by {{AudioWorklet}}s
+in the Web Audio API
+because use of {{ScriptProcessorNode}} from the main thread
+frequently resulted in a poor user experience. [[WebAudio]]
+