Global scope clarifications in response to TC53 feedback

Author: andreubotella

index.bs

@@ -183,21 +183,21 @@ All of the following methods and properties shall be exposed on the global objec
 * `globalThis.`{{WebAssembly}}.{{WebAssembly/JSTag}} [[!WASM-JS-API-2]]
 * `globalThis.`{{WebAssembly}}.{{WebAssembly/validate()}} [[!WASM-JS-API-2]]
 
-If a web-interoperable runtime supports workers, it shall also expose {{WorkerGlobalScope/onerror}},
+This Standard does not require runtimes to support workers. However, if a runtime has global scopes that map to {{WorkerGlobalScope}} (see [[#global-scope]]), then the global object shall also expose {{WorkerGlobalScope/onerror}},
 {{WorkerGlobalScope/onunhandledrejection}}, {{WorkerGlobalScope/onrejectionhandled}} and
-{{WorkerGlobalScope/self}} on the worker's `globalThis`,
+{{WorkerGlobalScope/self}},
 except as specified in [[#global-scope]]. [[!HTML]]
 
 The Global Scope {#global-scope}
 ================================
 
-The exact type of the global scope (`globalThis`) can vary across runtimes. Most Web Platform APIs are defined in terms that assume Web Browser environments that specifically expose types like {{Window}}, {{WorkerGlobalScope}}, and so forth. To simplify conformance, all interfaces, methods, and properties defined by this Standard shall be exposed on the runtime's relevant global scope (e.g., `globalThis.crypto`, `globalThis.ReadableStream`, etc).
+The exact type of the global scope (`globalThis`) can vary across runtimes. Most Web Platform APIs are defined in terms that assume Web Browser environments that specifically expose types like {{Window}}, {{WorkerGlobalScope}}, and so forth. To simply conformance, this Standard does not require such global scope interfaces to be supported, but each global scope in a relevant runtime must map to a global scope interface defined in web specifications. All interfaces, methods, and properties defined by this Standard which are required by web specifications to be exposed in a global scope interface shall be exposed on all of the runtime's corresponding global scopes (e.g., `globalThis.crypto`, `globalThis.ReadableStream`, etc).
 
 With many runtimes, adding a new global-scoped property can introduce breaking changes when the new global conflicts with existing application code. Many Web Platform APIs define global properties using [=read only|the `readonly` attribute=]. [[!WEBIDL]] To avoid introducing breaking changes, runtimes conforming to this Standard may omit the `readonly` attribute for properties being added to the global scope. This allows users of these runtimes to delete or overwrite these properties if they conflict with existing application code.
 
-The global object on {{Window}}-like and worker environments should always be an instance of {{EventTarget}}. Web-interoperable runtimes should follow the <a>report an exception</a> algorithm, and the JavaScript <a href="https://tc39.es/ecma262/#sec-host-promise-rejection-tracker">HostPromiseRejectionTracker</a> host hook, as defined in [[!HTML]]. This includes firing the {{Window/error}}, {{Window/unhandledrejection}} and {{Window/rejectionhandled}} events on the global object.
+Whenever the global object corresponds to the {{Window}} or {{WorkerGlobalScope}} global interfaces, it should be an instance of {{EventTarget}}. Web-interoperable runtimes should follow the <a>report an exception</a> algorithm, and the JavaScript <a href="https://tc39.es/ecma262/#sec-host-promise-rejection-tracker">HostPromiseRejectionTracker</a> host hook, as defined in [[!HTML]]. This includes firing the {{Window/error}}, {{Window/unhandledrejection}} and {{Window/rejectionhandled}} events on the global object.
 
-In cases where it is not possible to have the global object be an instance of {{EventTarget}} due to legacy reasons, the relevant events shall still be fired through a suitable alternative mechanism available at the global scope. This mechanism shall provide at least the same information that is provided by the relevant event interfaces if the global object were to be an {{EventTarget}}. Such runtimes shall not support the {{GlobalEventHandlers/onerror}}, {{WindowEventHandlers/onunhandledrejection}} and {{WindowEventHandlers/onrejectionhandled}} global properties. Such runtimes are not required to implement the {{ErrorEvent}} and {{PromiseRejectionEvent}} interfaces.
+In cases where it is not possible to have such global objects be an instance of {{EventTarget}} due to legacy reasons, the relevant events shall still be fired through a suitable alternative mechanism available at the global scope. This mechanism shall provide at least the same information that is provided by the relevant event interfaces if the global object were to be an {{EventTarget}}. Such runtimes shall not support the {{GlobalEventHandlers/onerror}}, {{WindowEventHandlers/onunhandledrejection}} and {{WindowEventHandlers/onrejectionhandled}} global properties. Such runtimes are not required to implement the {{ErrorEvent}} and {{PromiseRejectionEvent}} interfaces.
 
 Note: For example, in Node.js the global object does not implement {{EventTarget}}, and the relevant events are fired on the `globalThis.process` object with the names `uncaughtException`, `unhandledRejection` and `rejectionHandled`, respectively.