HTML: The Living Standard

Developer's Edition — Last Updated 17 June 2021

1. 8 Web application APIs
   1. 8.1 Scripting
      1. 8.1.1 Introduction
      2. 8.1.2 Agents and agent clusters
         1. 8.1.2.1 Integration with the JavaScript agent formalism
         2. 8.1.2.2 Integration with the JavaScript agent cluster formalism
      3. 8.1.3 Script processing model
         1. 8.1.3.1 Runtime script errors
         2. 8.1.3.2 Unhandled promise rejections
         3. 8.1.3.3 Job-related host hooks
            1. 8.1.3.3.1 HostCallJobCallback(callback, V, argumentsList)
            2. 8.1.3.3.2 HostEnqueueFinalizationRegistryCleanupJob(finalizationRegistry)
            3. 8.1.3.3.3 HostEnqueuePromiseJob(job, realm)
            4. 8.1.3.3.4 HostMakeJobCallback(callable)
         4. 8.1.3.4 Module-related host hooks
      4. 8.1.4 Event loops
      5. 8.1.5 Events
         1. 8.1.5.1 Event handlers
         2. 8.1.5.2 Event handlers on elements, Document objects, and Window objects
   2. 8.2 The WindowOrWorkerGlobalScope mixin
   3. 8.3 Base64 utility methods

8 Web application APIs

8.1 Scripting

8.1.1 Introduction

Various mechanisms can cause author-provided executable code to run in the context of a document. These mechanisms include, but are probably not limited to:

• Processing of script elements.
• Navigating to javascript: URLs.
• Event handlers, whether registered through the DOM using addEventListener(), by explicit event handler content attributes, by event handler IDL attributes, or otherwise.
• Processing of technologies like SVG that have their own scripting features.

8.1.2 Agents and agent clusters

8.1.2.1 Integration with the JavaScript agent formalism

JavaScript defines the concept of an agent. This section gives the mapping of that language-level concept on to the web platform.

The following types of agents exist on the web platform:

Similar-origin window agent

Contains various Window objects which can potentially reach each other, either directly or by using document.domain.

If the encompassing agent cluster's is origin-keyed is true, then all the Window objects will be same origin, can reach each other directly, and document.domain will no-op.

Two Window objects that are same origin can be in different similar-origin window agents, for instance if they are each in their own browsing context group.

Dedicated worker agent

Contains a single DedicatedWorkerGlobalScope.

Shared worker agent

Contains a single SharedWorkerGlobalScope.

Service worker agent

Contains a single ServiceWorkerGlobalScope.

Worklet agent

Contains a single WorkletGlobalScope object.

Although a given worklet can have multiple realms, each such realm needs its own agent, as each realm can be executing code independently and at the same time as the others.

Only shared and dedicated worker agents allow the use of JavaScript Atomics APIs to potentially block.

8.1.2.2 Integration with the JavaScript agent cluster formalism

JavaScript also defines the concept of an agent cluster, which this standard maps to the web platform by placing agents appropriately when they are created.

The agent cluster concept is crucial for defining the JavaScript memory model, and in particular among which agents the backing data of SharedArrayBuffer objects can be shared.

Conceptually, the agent cluster concept is an architecture-independent, idealized "process boundary" that groups together multiple "threads" (agents). The agent clusters defined by the specification are generally more restrictive than the actual process boundaries implemented in user agents. By enforcing these idealized divisions at the specification level, we ensure that web developers see interoperable behavior with regard to shared memory, even in the face of varying and changing user agent process models.

8.1.3 Script processing model

8.1.3.1 Runtime script errors

In various scenarios, the user agent can report an exception by firing an error event at the Window. If this event is not canceled, then the error is considered not handled, and can be reported to the developer console.

8.1.3.2 Unhandled promise rejections

In addition to synchronous runtime script errors, scripts may experience asynchronous promise rejections, tracked via the unhandledrejection and rejectionhandled events.

8.1.3.3 Job-related host hooks

The JavaScript specification defines Jobs to be scheduled and run later by the host, as well as JobCallback Records which encapsulate JavaScript functions that are called as part of jobs. The JavaScript specification contains a number of implementation-defined abstract operations that lets the host define how jobs are scheduled and how JobCallbacks are handled. HTML uses these abstract operations to track the incumbent settings object in promises and FinalizationRegistry callbacks by saving and restoring the incumbent settings object and a JavaScript execution context for the active script in JobCallbacks. This section defines them for user agent hosts.

8.1.3.3.1 HostCallJobCallback(callback, V, argumentsList)

JavaScript contains an implementation-defined HostCallJobCallback(callback, V, argumentsList) abstract operation to let hosts restore state when invoking JavaScript callbacks from inside tasks. User agents must use the following implementation: [JAVASCRIPT]

1. Let incumbent settings be callback.[[HostDefined]].[[IncumbentSettings]].

2. Let script execution context be callback.[[HostDefined]].[[ActiveScriptContext]].

3. Prepare to run a callback with incumbent settings.

   This affects the incumbent concept while the callback runs.

4. If script execution context is not null, then push script execution context onto the JavaScript execution context stack.

   This affects the active script while the callback runs.

5. Let result be Call(callback.[[Callback]], V, argumentsList).

6. If script execution context is not null, then pop script execution context from the JavaScript execution context stack.

7. Clean up after running a callback with incumbent settings.

8. Return result.

8.1.3.3.2 HostEnqueueFinalizationRegistryCleanupJob(finalizationRegistry)

JavaScript has the ability to register objects with FinalizationRegistry objects, in order to schedule a cleanup action if they are found to be garbage collected. The JavaScript specification contains an implementation-defined HostEnqueueFinalizationRegistryCleanupJob(finalizationRegistry) abstract operation to schedule the cleanup action.

The timing and occurrence of cleanup work is implementation-defined in the JavaScript specification. User agents might differ in when and whether an object is garbage collected, affecting both whether the return value of the WeakRef.prototype.deref() method is undefined, and whether FinalizationRegistry cleanup callbacks occur. There are well-known cases in popular web browsers where objects are not accessible to JavaScript, but they remain retained by the garbage collector indefinitely. HTML clears kept-alive WeakRef objects in the perform a microtask checkpoint algorithm. Authors would be best off not depending on the timing details of garbage collection implementations.

Cleanup actions do not take place interspersed with synchronous JavaScript execution, but rather happen in queued tasks. User agents must use the following implementation: [JAVASCRIPT]

1. Let global be finalizationRegistry.[[Realm]]'s global object.

2. Queue a global task on the JavaScript engine task source given global to perform the following steps:

   1. Let entry be finalizationRegistry.[[CleanupCallback]].[[Callback]].[[Realm]]'s environment settings object.

   2. Check if we can run script with entry. If this returns "do not run", then return.

   3. Prepare to run script with entry.

      This affects the entry concept while the cleanup callback runs.

   4. Let result be the result of performing CleanupFinalizationRegistry(finalizationRegistry).

   5. Clean up after running script with entry.

   6. If result is an abrupt completion, then report the exception given by result.[[Value]].

8.1.3.3.3 HostEnqueuePromiseJob(job, realm)

JavaScript contains an implementation-defined HostEnqueuePromiseJob(job, realm) abstract operation to schedule Promise-related operations. HTML schedules these operations in the microtask queue. User agents must use the following implementation: [JAVASCRIPT]

1. If realm is not null, then let job settings be the settings object for realm. Otherwise, let job settings be null.

   If realm is not null, it is the Realm of the author code that will run. When job is returned by NewPromiseReactionJob, it is the realm of the promise's handler function. When job is returned by NewPromiseResolveThenableJob, it is the realm of the then function.

   If realm is null, either no author code will run or author code is guaranteed to throw. For the former, the author may not have passed in code to run, such as in promise.then(null, null). For the latter, it is because a revoked Proxy was passed. In both cases, all the steps below that would otherwise use job settings get skipped.

2. Queue a microtask on the surrounding agent's event loop to perform the following steps:

   1. If job settings is not null, then check if we can run script with job settings. If this returns "do not run" then return.

   2. If job settings is not null, then prepare to run script with job settings.

      This affects the entry concept while the job runs.

   3. Let result be job().

      job is an abstract closure returned by NewPromiseReactionJob or NewPromiseResolveThenableJob. The promise's handler function when job is returned by NewPromiseReactionJob, and the then function when job is returned by NewPromiseResolveThenableJob, are wrapped in JobCallback Records. HTML saves the incumbent settings object and a JavaScript execution context for to the active script in HostMakeJobCallback and restores them in HostCallJobCallback.

   4. If job settings is not null, then clean up after running script with job settings.

   5. If result is an abrupt completion, then report the exception given by result.[[Value]].

8.1.3.3.4 HostMakeJobCallback(callable)

JavaScript contains an implementation-defined HostMakeJobCallback(callable) abstract operation to let hosts attach state to JavaScript callbacks that are called from inside tasks. User agents must use the following implementation: [JAVASCRIPT]

1. Let incumbent settings be the incumbent settings object.

2. Let active script be the active script.

3. Let script execution context be null.

4. If active script is not null, set script execution context to a new JavaScript execution context, with its Function field set to null, its Realm field set to active script's settings object's Realm, and its ScriptOrModule set to active script's record.

   As seen below, this is used in order to propagate the current active script forward to the time when the job callback is invoked.

   A case where active script is non-null, and saving it in this way is useful, is the following:

   Promise.resolve('import(`./example.mjs`)').then(eval);

   Without this step (and the steps that use it in HostCallJobCallback), there would be no active script when the import() expression is evaluated, since eval() is a built-in function that does not originate from any particular script.

   With this step in place, the active script is propagated from the above code into the job, allowing import() to use the original script's base URL appropriately.

   active script can be null if the user clicks on the following button:

   <button onclick="Promise.resolve('import(`./example.mjs`)').then(eval)">Click me</button>

   In this case, the JavaScript function for the event handler will be created by the get the current value of the event handler algorithm, which creates a function with null [[ScriptOrModule]] value. Thus, when the promise machinery calls HostMakeJobCallback, there will be no active script to pass along.

   As a consequence, this means that when the import() expression is evaluated, there will still be no active script. Fortunately that is handled by our implementations of HostResolveImportedModule and HostImportModuleDynamically, by falling back to using the current settings object's API base URL.

5. Return the JobCallback Record { [[Callback]]: callable, [[HostDefined]]: { [[IncumbentSettings]]: incumbent settings, [[ActiveScriptContext]]: script execution context } }.

8.1.3.4 Module-related host hooks

The JavaScript specification defines a syntax for modules, as well as some host-agnostic parts of their processing model. This specification defines the rest of their processing model: how the module system is bootstrapped, via the script element with type attribute set to "module", and how modules are fetched, resolved, and executed. [JAVASCRIPT]

Although the JavaScript specification speaks in terms of "scripts" versus "modules", in general this specification speaks in terms of classic scripts versus module scripts, since both of them use the script element.

modulePromise = import(specifier)

Returns a promise for the module namespace object for the module script identified by specifier. This allows dynamic importing of module scripts at runtime, instead of statically using the import statement form. The specifier will be resolved relative to the active script's base URL.

The returned promise will be rejected if an invalid specifier is given, or if a failure is encountered while fetching or evaluating the resulting module graph.

This syntax can be used inside both classic and module scripts. It thus provides a bridge into the module-script world, from the classic-script world.

url = import . meta . url

Returns the active module script's base URL.

This syntax can only be used inside module scripts.

Module maps are used to ensure that imported JavaScript modules are only fetched, parsed, and evaluated once per Document or worker.

import "https://example.com/module.mjs";
import "https://example.com/module.mjs#map-buster";
import "https://example.com/module.mjs?debug=true";

import "https://example.com/module2.mjs";
import "https:example.com/module2.mjs";
import "https://///example.com\\module2.mjs";
import "https://example.com/foo/../module2.mjs";

8.1.4 Event loops

To coordinate events, user interaction, scripts, rendering, networking, and so forth, user agents must use event loops as described in this section. Each agent has an associated event loop, which is unique to that agent.

The event loop of a similar-origin window agent is known as a window event loop. The event loop of a dedicated worker agent, shared worker agent, or service worker agent is known as a worker event loop. And the event loop of a worklet agent is known as a worklet event loop.

8.1.5 Events

8.1.5.1 Event handlers

Many objects can have event handlers specified. These act as non-capture event listeners for the object on which they are specified. [DOM]

Event handlers are exposed in two ways.

The first way, common to all event handlers, is as an event handler IDL attribute.

The second way is as an event handler content attribute. Event handlers on HTML elements and some of the event handlers on Window objects are exposed in this way.

For both of these two ways, the event handler is exposed through a name, which is a string that always starts with "on" and is followed by the name of the event for which the handler is intended.

Most of the time, the object that exposes an event handler is the same as the object on which the corresponding event listener is added. However, the body and frameset elements expose several event handlers that act upon the element's Window object, if one exists. In either case, we call the object an event handler acts upon the target of that event handler.

An event handler IDL attribute is an IDL attribute for a specific event handler. The name of the IDL attribute is the same as the name of the event handler.

An event handler content attribute is a content attribute for a specific event handler. The name of the content attribute is the same as the name of the event handler.

Event handler content attributes, when specified, must contain valid JavaScript code which, when parsed, would match the FunctionBody production after automatic semicolon insertion.

<button id="test">Start Demo</button>
<script>
 var button = document.getElementById('test');
 button.addEventListener('click', function () { alert('ONE') }, false);
 button.setAttribute('onclick', "alert('NOT CALLED')"); // event handler listener is registered here
 button.addEventListener('click', function () { alert('THREE') }, false);
 button.onclick = function () { alert('TWO'); };
 button.addEventListener('click', function () { alert('FOUR') }, false);
</script>

<button id="test">Start Demo</button>
<script>
 var button = document.getElementById('test');
 button.addEventListener('click', function () { alert('ONE') }, false);
 button.setAttribute('onclick', "alert('NOT CALLED')"); // event handler is activated here
 button.addEventListener('click', function () { alert('TWO') }, false);
 button.onclick = null;                                 // but deactivated here
 button.addEventListener('click', function () { alert('THREE') }, false);
 button.onclick = function () { alert('FOUR'); };       // and re-activated here
 button.addEventListener('click', function () { alert('FIVE') }, false);
</script>

The EventHandler callback function type represents a callback used for event handlers.

In JavaScript, any Function object implements this interface.

<body onload="alert(this)" onclick="alert(this)">

For historical reasons, the onerror handler has different arguments:

window.onerror = (message, source, lineno, colno, error) => { … };

Similarly, the onbeforeunload handler has a different return value: it will be cast to a string.

8.1.5.2 Event handlers on elements, Document objects, and Window objects

The following are the event handlers (and their corresponding event handler event types) supported by all HTML elements, as both event handler content attributes and event handler IDL attributes; and supported by all Document and Window objects, as event handler IDL attributes:

The following are the event handlers (and their corresponding event handler event types) supported by all HTML elements other than body and frameset elements, as both event handler content attributes and event handler IDL attributes; supported by all Document objects, as event handler IDL attributes; and supported by all Window objects, as event handler IDL attributes on the Window objects themselves, and with corresponding event handler content attributes and event handler IDL attributes exposed on all body and frameset elements that are owned by that Window object's associated Document:

We call the set of the names of the event handlers listed in the first column of this table the Window-reflecting body element event handler set.

The following are the event handlers (and their corresponding event handler event types) supported by Window objects, as event handler IDL attributes on the Window objects themselves, and with corresponding event handler content attributes and event handler IDL attributes exposed on all body and frameset elements that are owned by that Window object's associated Document:

The following are the event handlers (and their corresponding event handler event types) supported by all HTML elements, as both event handler content attributes and event handler IDL attributes; and supported by all Document objects, as event handler IDL attributes:

The following are the event handlers (and their corresponding event handler event types) supported on Document objects as event handler IDL attributes:

8.2 The WindowOrWorkerGlobalScope mixin

The WindowOrWorkerGlobalScope mixin is for use of APIs that are to be exposed on Window and WorkerGlobalScope objects.

Other standards are encouraged to further extend it using partial interface mixin WindowOrWorkerGlobalScope { … }; along with an appropriate reference.

self . isSecureContext

Returns whether or not this global object represents a secure context. [SECURE-CONTEXTS]

self . origin

Returns the global object's origin, serialized as string.

self . crossOriginIsolated

Returns whether scripts running in this global are allowed to use APIs that require cross-origin isolation. This depends on the `Cross-Origin-Opener-Policy` and `Cross-Origin-Embedder-Policy` HTTP response headers and the "cross-origin-isolated" feature.

var frame = document.createElement("iframe")
frame.onload = function() {
  var frameWin = frame.contentWindow
  console.log(frameWin.location.origin) // "null"
  console.log(frameWin.origin) // "https://stargate.example"
}
document.body.appendChild(frame)

8.3 Base64 utility methods

The atob() and btoa() methods allow developers to transform content to and from the base64 encoding.

In these APIs, for mnemonic purposes, the "b" can be considered to stand for "binary", and the "a" for "ASCII". In practice, though, for primarily historical reasons, both the input and output of these functions are Unicode strings.

result = self . btoa( data )

Takes the input data, in the form of a Unicode string containing only characters in the range U+0000 to U+00FF, each representing a binary byte with values 0x00 to 0xFF respectively, and converts it to its base64 representation, which it returns.

Throws an "InvalidCharacterError" DOMException exception if the input string contains any out-of-range characters.

result = self . atob( data )

Takes the input data, in the form of a Unicode string containing base64-encoded binary data, decodes it, and returns a string consisting of characters in the range U+0000 to U+00FF, each representing a binary byte with values 0x00 to 0xFF respectively, corresponding to that binary data.

Throws an "InvalidCharacterError" DOMException if the input string is not valid base64 data.