You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There is a wide base of ECMAScript runtime environments being used beyond web browsers, specifically in web server and edge platforms. An major benefit to this approach is the ability to use a single programming language across multiple contexts, reducing specialization and allowing for reuse of code across the server and client side.
20
+
There is a wide base of ECMAScript runtime environments being used beyond web browsers, specifically in web server and edge platforms. A major benefit to this approach is the ability to use a single programming language across multiple contexts, reducing specialisation and allowing for reuse of code across the server and client side.
21
21
22
-
Since code running in web browsers makes up the vast majority of ECMAScript code, runtimes are incentivised to support the same APIs as web browsers. However without a specification of which web platform APIs to be implemented, the resulting landscape provides poor interoperability across such environments.
22
+
Since code running in web browsers makes up the vast majority of ECMAScript code, runtimes are incentivised to support the same APIs as web browsers. However, without a specification of which web platform APIs to be implemented, the resulting landscape provides poor interoperability across such environments.
23
23
24
24
As such, this Ecma Standard defines the Minimum common web API specification, which defines a subset of Web Platform APIs for server runtimes to implement for interoperability with the web. This is the first edition of the standard, corresponding to the 2025 snapshot. As the web platform and web server runtimes grow and evolve, the committee will aim to publish with an annual cadence.
25
25
@@ -79,123 +79,194 @@ Terms and definitions {#terminology}
79
79
80
80
For the purposes of this document, the terms and definitions given in ECMA-262, Compression Standard, Console Standard, DOM Standard, Encoding Standard, Fetch Standard, File API, High-Resolution Time, HTML Standard, Streams Standard, URL Standard, URL Pattern Standard, WebAssembly JavaScript Interface, WebAssembly Web API, W3C Web Cryptography Level 2, and the following apply. Externally-defined terms are mapped to source in Annex A.
ECMAScript-based runtime environment that implements this Standard
91
89
92
90
Note: Web Browsers are Web-interoperable Runtimes.<br>
93
91
The term "Web-interoperable Runtime" is intentionally broad. The primary focus of this Standard is web server runtimes.
94
92
95
-
Common API Index {#api-index}
96
-
=========================
93
+
Common API index {#api-index}
94
+
=============================
97
95
98
96
All <a>Web-interoperable Runtimes</a> conforming to this Standard shall implement each of the following <a>Web Platform</a> APIs. These should be implemented in accordance with their normative requirements except as specified in [[#global-scope]]. Where any runtime environment must diverge from a normative requirement for technical or structural reasons, clear documentation shall be provided. Documentation shall include both explanation and impact of deviation.
99
97
100
98
Note: For example, since web server runtimes do not have an [=origin=] concept, they must violate [[!FETCH]]'s requirement of appending an `Origin` header to network requests.
101
99
102
-
All of the following interfaces shall be exposed on the global object accessible through `globalThis`:
All of the following methods and properties shall be exposed on the global object accessible through `globalThis`, except as specified in [[#global-scope]]:
This Standard does not require runtimes to support [=web workers=]. However, if a runtime has global scopes that map to {{WorkerGlobalScope}} (see [[#global-scope]]), then the global object shall also expose {{WorkerGlobalScope/onerror}},
187
-
{{WorkerGlobalScope/onunhandledrejection}}, {{WorkerGlobalScope/onrejectionhandled}} and
188
-
{{WorkerGlobalScope/self}},
189
-
except as specified in [[#global-scope]]. [[!HTML]]
190
-
191
-
The Global Scope {#global-scope}
100
+
Common interfaces {#api-interfaces}
101
+
-----------------------------------
102
+
103
+
All of the following interfaces shall be exposed on the global object accessible through `globalThis`.
104
+
105
+
Interfaces defined in [[!DOM]]:
106
+
107
+
* {{AbortController}}
108
+
* {{AbortSignal}}
109
+
* {{Event}}
110
+
* {{EventTarget}}
111
+
112
+
Interfaces defined in [[!HTML]]:
113
+
114
+
* {{CustomEvent}}
115
+
* {{ErrorEvent}}
116
+
* {{MessageChannel}}
117
+
* {{MessageEvent}}
118
+
* {{MessagePort}}
119
+
* {{PromiseRejectionEvent}}
120
+
121
+
Interfaces defined in [[!WEBIDL]]:
122
+
123
+
* {{DOMException}}
124
+
125
+
Interfaces defined in [[!FETCH]]:
126
+
127
+
* {{Headers}}
128
+
* {{Request}}
129
+
* {{Response}}
130
+
131
+
Interfaces defined in [[!XHR]]:
132
+
133
+
* {{FormData}}
134
+
135
+
Note: The {{FormData}} constructor takes <i>optional</i> arguments of the types {{HTMLFormElement}} and {{HTMLElement}}, which are web API interfaces not included in the common API list in this Standard. Since both of these arguments are optional, the behavior when both are `undefined` or not given is always well-defined. The behavior in other cases for runtimes that do not implement such APIs is not well-defined by this Standard; future editions will provide greater clarity.
All of the following methods and properties shall be exposed on the global object accessible through `globalThis`, except as specified in [[#global-scope]].
This Standard does not require runtimes to support [=web workers=]. However, if a runtime has global scopes that map to {{WorkerGlobalScope}} (see [[#global-scope]]), then the global object shall also expose the following event handlers and attributes as defined in [[!HTML]],
255
+
except as specified in [[#global-scope]].
256
+
257
+
* {{WorkerGlobalScope/onerror}}
258
+
* {{WorkerGlobalScope/onunhandledrejection}}
259
+
* {{WorkerGlobalScope/onrejectionhandled}}
260
+
* {{WorkerGlobalScope/self}}
261
+
262
+
The global scope {#global-scope}
192
263
================================
193
264
194
265
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, this Standard does not require such global scope interfaces to be supported, but each global scope in a relevant runtime may be mapped 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).
195
266
196
-
Note: It is expected that a runtime's main global scope maps to {{Window}}, that web worker global scopes map to {{WorkerGlobalScope}}, etc. Global scopes that do not map to any global interface could only implement web APIs defined as {{Exposed|[Exposed=*]}}.
267
+
Note: A runtime's main global scope should map to {{Window}}, web worker global scope should map to {{WorkerGlobalScope}}, etc. Global scopes that do not map to a specifically defined global interface can only implement web APIs defined as {{Exposed|[Exposed=*]}}.
197
268
198
-
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.
269
+
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=]. 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.
199
270
200
271
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.
0 commit comments