# Web IDL

## Editor’s Draft, 1 January 1970

This version:
  https://heycam.github.io/webidl/
Feedback:
  public-script-coord@w3.org with subject line “`[WebIDL] … message topic …`” (archives)
  GitHub (new issue, open issues, legacy bug tracker)
Editor:
  Boris Zbarsky (Mozilla Corporation)
Former Editors:
  Cameron McCormack (Mozilla Corporation) cam@mcc.id.au
  Tobie Langel tobie@unlockopen.com

Copyright © 1970 W3C® (MIT, ERCIM, Keio, Beihang). W3C liability, trademark and permissive document license rules apply.

## Abstract

This document defines an interface definition language, Web IDL, that can be used to describe interfaces that are intended to be implemented in web browsers. Web IDL is an IDL variant with a number of features that allow the behavior of common script objects in the web platform to be specified more readily. How interfaces described with Web IDL correspond to constructs within ECMAScript execution environments is also detailed in this document. It is expected that this document acts as a guide to implementors of already-published specifications, and that newly published specifications reference this document to ensure conforming implementations of interfaces are interoperable.

## Status of this document

This is a public copy of the editors’ draft. It is provided for discussion only and may change at any moment. Its publication here does not imply endorsement of its contents by W3C. Don’t cite this document other than as work in progress.

Changes to this document may be tracked at https://github.com/heycam/webidl.

GitHub issues are preferred for discussion of this specification. There is also a historical mailing-list archive.

This document was produced by the Web Platform Working Group.

This document was produced by a group operating under the 5 February 2004 W3C Patent Policy. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.

This document is governed by the 1 March 2017 W3C Process Document.

## 1. Introduction

This section is informative.

Technical reports published by the W3C that include programming language interfaces have typically been described using the Object Management Group’s Interface Definition Language (IDL) [OMGIDL]. The IDL provides a means to describe these interfaces in a language independent manner. Usually, additional language binding appendices are included in such documents which detail how the interfaces described with the IDL correspond to constructs in the given language.

However, the bindings in these specifications for the language most commonly used on the web, ECMAScript, are consistently specified with low enough precision as to result in interoperability issues. In addition, each specification must describe the same basic information, such as DOM interfaces described in IDL corresponding to properties on the ECMAScript global object, or the `unsigned long` IDL type mapping to the Number type in ECMAScript.

This specification defines an IDL language similar to OMG IDL for use by specifications that define interfaces for Web APIs. A number of extensions are given to the IDL to support common functionality that previously must have been written in prose. In addition, precise language bindings for the ECMAScript language are given.

## 2. Interface definition language

This section describes a language, Web IDL, which can be used to define interfaces for APIs in the Web platform. A specification that defines Web APIs can include one or more IDL fragments that describe the interfaces (the state and behavior that objects can exhibit) for the APIs defined by that specification. An IDL fragment is a sequence of definitions that matches the Definitions grammar symbol. The set of IDL fragments that an implementation supports is not ordered. See IDL grammar for the complete grammar and an explanation of the notation used.

The different kinds of definitions that can appear in an IDL fragment are: interfaces, partial interface definitions, interface mixins, partial mixin definitions, callback functions, callback interfaces, namespaces, partial namespace definitions, dictionaries, partial dictionary definitions, typedefs and includes statements. These are all defined in the following sections.

Each definition (matching Definition) can be preceded by a list of extended attributes (matching ExtendedAttributeList), which can control how the definition will be handled in language bindings. The extended attributes defined by this specification that are language binding agnostic are discussed in § 2.14 Extended attributes, while those specific to the ECMAScript language binding are discussed in § 3.3 ECMAScript-specific extended attributes.

    [extended_attributes]
    interface identifier {
      /* interface_members... */
    };

    Definitions :
        ExtendedAttributeList Definition Definitions
        ε

    Definition :
        CallbackOrInterfaceOrMixin
        Namespace
        Partial
        Dictionary
        Enum
        Typedef
        IncludesStatement

The following is an example of an IDL fragment.

    [Exposed=Window]
    interface Paint { };

    [Exposed=Window]
    interface SolidColor : Paint {
      attribute double red;
      attribute double green;
      attribute double blue;
    };

    [Exposed=Window]
    interface Pattern : Paint {
      attribute DOMString imageURL;
    };

    [Exposed=Window]
    interface GraphicalWindow {
      constructor();
      readonly attribute unsigned long width;
      readonly attribute unsigned long height;

      attribute Paint currentPaint;

      void drawRectangle(double x, double y, double width, double height);

      void drawText(double x, double y, DOMString text);
    };

Here, four interfaces are being defined. The `GraphicalWindow` interface has two read only attributes, one writable attribute, and two operations defined on it. Objects that implement the `GraphicalWindow` interface will expose these attributes and operations in a manner appropriate to the particular language being used.

In ECMAScript, the attributes on the IDL interfaces will be exposed as accessor properties and the operations as data properties whose value is a built-in function object on a prototype object for all `GraphicalWindow` objects; each ECMAScript object that implements `GraphicalWindow` will have that prototype object in its prototype chain.

The constructor operation that appears on `GraphicalWindow` causes a constructor to exist in ECMAScript implementations, so that calling `new GraphicalWindow()` would return a new object that implemented the interface.

All interfaces have the [`Exposed`] extended attribute, which ensures the interfaces are only available in Realms whose global object is a `Window` object.

### 2.1. Names

Every interface, partial interface definition, namespace, partial namespace definition, dictionary, partial dictionary definition, enumeration, callback function, callback interface and typedef (together called named definitions) and every constant, attribute, and dictionary member has an identifier, as do some operations. The identifier is determined by an identifier token somewhere in the declaration:

- For named definitions, the identifier token that appears directly after the interface, namespace, dictionary, enum or callback keyword determines the identifier of that definition.

      interface interface_identifier { /* interface_members... */ };
      partial interface interface_identifier { /* interface_members... */ };
      namespace namespace_identifier { /* namespace_members... */ };
      partial namespace namespace_identifier { /* namespace_members... */ };
      dictionary dictionary_identifier { /* dictionary_members... */ };
      partial dictionary dictionary_identifier { /* dictionary_members... */ };
      enum enumeration_identifier { "enum", "values" /* , ... */ };
      callback callback_identifier = return_type (/* arguments... */);
      callback interface callback_interface_identifier { /* interface_members... */ };

- For attributes, typedefs and dictionary members, the final identifier token before the semicolon at the end of the declaration determines the identifier.

      [extended_attributes]
      interface identifier {
        attribute type attribute_identifier;
      };

      typedef type typedef_identifier;

      dictionary identifier {
        type dictionary_member_identifier;
      };

- For constants, the identifier token before the equals sign determines the identifier.

      const type constant_identifier = 42;

- For operations, the identifier token that appears after the return type but before the opening parenthesis (that is, one that is matched as part of the OptionalOperationName grammar symbol in an OperationRest) determines the identifier of the operation. If there is no such identifier token, then the operation does not have an identifier.

      interface interface_identifier {
        return_type operation_identifier(/* arguments... */);
      };

Note: Operations can have no identifier when they are being used to declare a special kind of operation, such as a getter or setter.

For all of these constructs, the identifier is the value of the identifier token with any leading U+005F LOW LINE ("_") character (underscore) removed.

Note: A leading "_" is used to escape an identifier from looking like a reserved word so that, for example, an interface named "`interface`" can be defined. The leading "_" is dropped to unescape the identifier.

Operation arguments can take a slightly wider set of identifiers. In an operation declaration, the identifier of an argument is specified immediately after its type and is given by either an identifier token or by one of the keywords that match the ArgumentNameKeyword symbol. If one of these keywords is used, it need not be escaped with a leading underscore.

    interface interface_identifier {
      return_type operation_identifier(argument_type argument_identifier /* , ... */);
    };

    ArgumentNameKeyword :
        "async"
        "attribute"
        "callback"
        "const"
        "constructor"
        "deleter"
        "dictionary"
        "enum"
        "getter"
        "includes"
        "inherit"
        "interface"
        "iterable"
        "maplike"
        "mixin"
        "namespace"
        "partial"
        "readonly"
        "required"
        "setlike"
        "setter"
        "static"
        "stringifier"
        "typedef"
        "unrestricted"

If an identifier token is used, then the identifier of the operation argument is the value of that token with any leading U+005F LOW LINE ("_") character (underscore) removed. If instead one of the ArgumentNameKeyword keyword token is used, then the identifier of the operation argument is simply that token.

The identifier of any of the abovementioned IDL constructs (except operation arguments) must not be "`constructor`", "`toString`", or begin with a U+005F LOW LINE ("_") character. These are known as reserved identifiers.

Although the "`toJSON`" identifier is not a reserved identifier, it must only be used for regular operations that convert objects to JSON types, as described in § 2.5.3.1 toJSON.

Note: Further restrictions on identifier names for particular constructs may be made in later sections.

Within the set of IDL fragments that a given implementation supports, the identifier of every interface, namespace, dictionary, enumeration, callback function, callback interface and typedef must not be the same as the identifier of any other interface, namespace, dictionary, enumeration, callback function, callback interface or typedef.

Within an IDL fragment, a reference to a definition need not appear after the declaration of the referenced definition. References can also be made across IDL fragments.

Therefore, the following IDL fragment is valid:

    [Exposed=Window]
    interface B : A {
      void f(SequenceOfLongs x);
    };

    [Exposed=Window]
    interface A {
    };

    typedef sequence<long> SequenceOfLongs;

The following IDL fragment demonstrates how identifiers are given to definitions and interface members.

    // Typedef identifier: "number"
    typedef double number;

    // Interface identifier: "System"
    [Exposed=Window]
    interface System {

      // Operation identifier:          "createObject"
      // Operation argument identifier: "interface"
      object createObject(DOMString _interface);

      // Operation argument identifier: "interface"
      sequence<object> getObjects(DOMString interface);

      // Operation has no identifier; it declares a getter.
      getter DOMString (DOMString keyName);
    };

    // Interface identifier: "TextField"
    [Exposed=Window]
    interface TextField {

      // Attribute identifier: "const"
      attribute boolean _const;

      // Attribute identifier: "value"
      attribute DOMString? _value;
    };

Note that while the second attribute on the `TextField` interface need not have been escaped with an underscore (because "`value`" is not a keyword in the IDL grammar), it is still unescaped to obtain the attribute’s identifier.

### 2.2. Interfaces

IDL fragments are used to describe object oriented systems. In such systems, objects are entities that have identity and which are encapsulations of state and behavior. An interface is a definition (matching interface InterfaceRest) that declares some state and behavior that an object implementing that interface will expose.

    [extended_attributes]
    interface identifier {
      /* interface_members... */
    };

An interface is a specification of a set of interface members (matching InterfaceMembers). These are the members that appear between the braces in the interface declaration.

Interfaces in Web IDL describe how objects that implement the interface behave. In bindings for object oriented languages, it is expected that an object that implements a particular IDL interface provides ways to inspect and modify the object’s state and to invoke the behavior described by the interface.

An interface can be defined to inherit from another interface. If the identifier of the interface is followed by a U+003A COLON (":") character and an identifier, then that identifier identifies the inherited interface. An object that implements an interface that inherits from another also implements that inherited interface. The object therefore will also have members that correspond to the interface members from the inherited interface.

    interface identifier : identifier_of_inherited_interface {
      /* interface_members... */
    };

The order that members appear in has significance for property enumeration in the ECMAScript binding.

Interfaces may specify an interface member that has the same name as one from an inherited interface. Objects that implement the derived interface will expose the member on the derived interface. It is language binding specific whether the overridden member can be accessed on the object.

Consider the following two interfaces.

    [Exposed=Window]
    interface A {
      void f();
      void g();
    };

    [Exposed=Window]
    interface B : A {
      void f();
      void g(DOMString x);
    };

In the ECMAScript language binding, an instance of `B` will have a prototype chain that looks like the following:

    [Object.prototype: the Object prototype object]
         ↑
    [A.prototype: interface prototype object for A]
         ↑
    [B.prototype: interface prototype object for B]
         ↑
    [instanceOfB]

Calling `instanceOfB.f()` in ECMAScript will invoke the f defined on `B`. However, the f from `A` can still be invoked on an object that implements `B` by calling `A.prototype.f.call(instanceOfB)`.

The inherited interfaces of a given interface A is the set of all interfaces that A inherits from, directly or indirectly. If A does not inherit from another interface, then the set is empty. Otherwise, the set includes the interface B that A inherits from and all of B’s inherited interfaces.

An interface must not be declared such that its inheritance hierarchy has a cycle. That is, an interface A cannot inherit from itself, nor can it inherit from another interface B that inherits from A, and so on.

The list of inclusive inherited interfaces of an interface I is defined as follows:

1. Let result be « ».

2. Let interface be I.

3. While interface is not null:

   1. Append interface to result.

   2. Set interface to the interface that I inherits from, if any, and null otherwise.

4. Return result.

Note that general multiple inheritance of interfaces is not supported, and objects also cannot implement arbitrary sets of interfaces. Objects can be defined to implement a single given interface A, which means that it also implements all of A’s inherited interfaces. In addition, an includes statement can be used to define that objects implementing an interface A will always also include the members of the interface mixins A includes.

Each interface member can be preceded by a list of extended attributes (matching ExtendedAttributeList), which can control how the interface member will be handled in language bindings.

    [extended_attributes]
    interface identifier {

      [extended_attributes]
      const type constant_identifier = 42;

      [extended_attributes]
      attribute type identifier;

      [extended_attributes]
      return_type identifier(/* arguments... */);
    };

The IDL for interfaces can be split into multiple parts by using partial interface definitions (matching partial interface PartialInterfaceRest). The identifier of a partial interface definition must be the same as the identifier of an interface definition. All of the members that appear on each of the partial interfaces are considered to be members of the interface itself.

    interface SomeInterface {
      /* interface_members... */
    };

    partial interface SomeInterface {
      /* interface_members... */
    };

Note: Partial interface definitions are intended for use as a specification editorial aide, allowing the definition of an interface to be separated over more than one section of the document, and sometimes multiple documents.

The order of appearance of an interface definition and any of its partial interface definitions does not matter.

Note: A partial interface definition cannot specify that the interface inherits from another interface. Inheritance must be specified on the original interface definition.

The relevant language binding determines how interfaces correspond to constructs in the language.

The following extended attributes are applicable to interfaces: [`Exposed`], [`Global`], [`LegacyWindowAlias`], [`NamedConstructor`], [`NoInterfaceObject`], [`OverrideBuiltins`], and [`SecureContext`].

The following extended attributes are applicable to partial interfaces: [`Exposed`], [`OverrideBuiltins`], and [`SecureContext`].

Interfaces which are not annotated with a [`NoInterfaceObject`] extended attribute must be annotated with an [`Exposed`] extended attribute.

The qualified name of an interface interface is defined as follows:

1. Let identifier be the identifier of interface.

2. If interface has a [`LegacyNamespace`] extended attribute, then:

   1. Let namespace be the identifier argument of the [`LegacyNamespace`] extended attribute.

   2. Return the concatenation of « namespace, identifier » with separator U+002E FULL STOP (".").

3. Return identifier.

    CallbackOrInterfaceOrMixin :
        "callback" CallbackRestOrInterface
        "interface" InterfaceOrMixin

    InterfaceOrMixin :
        InterfaceRest
        MixinRest

    InterfaceRest :
        identifier Inheritance "{" InterfaceMembers "}" ";"

    Partial :
        "partial" PartialDefinition

    PartialDefinition :
        "interface" PartialInterfaceOrPartialMixin
        PartialDictionary
        Namespace

    PartialInterfaceOrPartialMixin :
        PartialInterfaceRest
        MixinRest

    PartialInterfaceRest :
        identifier "{" PartialInterfaceMembers "}" ";"

    InterfaceMembers :
        ExtendedAttributeList InterfaceMember InterfaceMembers
        ε

    InterfaceMember :
        PartialInterfaceMember
        Constructor

    PartialInterfaceMembers :
        ExtendedAttributeList PartialInterfaceMember PartialInterfaceMembers
        ε

    PartialInterfaceMember :
        Const
        Operation
        Stringifier
        StaticMember
        Iterable
        AsyncIterable
        ReadOnlyMember
        ReadWriteAttribute
        ReadWriteMaplike
        ReadWriteSetlike

    Inheritance :
        ":" identifier
        ε

The following IDL fragment demonstrates the definition of two mutually referential interfaces. Both `Human` and `Dog` inherit from `Animal`. Objects that implement either of those two interfaces will thus have a `name` attribute.

    [Exposed=Window]
    interface Animal {
      attribute DOMString name;
    };

    [Exposed=Window]
    interface Human : Animal {
      attribute Dog? pet;
    };

    [Exposed=Window]
    interface Dog : Animal {
      attribute Human? owner;
    };

The following IDL fragment defines simplified versions of a DOM interfaces and a callback interface.

    [Exposed=Window]
    interface Node {
      readonly attribute DOMString nodeName;
      readonly attribute Node? parentNode;
      Node appendChild(Node newChild);
      void addEventListener(DOMString type, EventListener listener);
    };

    callback interface EventListener {
      void handleEvent(Event event);
    };

Plain objects can implement a callback interface like `EventListener`:

    var node = getNode();                                // Obtain an instance of Node.

    var listener = {
      handleEvent: function(event) {
        // ...
      }
    };
    node.addEventListener("click", listener);            // This works.

    node.addEventListener("click", function() { ... });  // As does this.

It is not possible for such an object to implement an interface like `Node`, however:

    var node = getNode();  // Obtain an instance of Node.

    var newNode = {
      nodeName: "span",
      parentNode: null,
      appendChild: function(newchild) {
        // ...
      },
      addEventListener: function(type, listener) {
        // ...
      }
    };
    node.appendChild(newNode);  // This will throw a TypeError exception.

### 2.3. Interface mixins

An interface mixin is a definition (matching interface MixinRest) that declares state and behavior that can be included by one or more interfaces, and that are exposed by objects that implement an interface that includes the interface mixin.

    interface mixin identifier {
      /* mixin_members... */
    };

Note: Interface mixins, much like partial interfaces, are intended for use as a specification editorial aide, allowing a coherent set of functionalities to be grouped together, and included in multiple interfaces, possibly across documents. They are not meant to be exposed through language bindings. Guidance on when to choose partial interfaces, interface mixins, or partial interface mixins can be found in § 2.3.1 Using mixins and partials.

An interface mixin is a specification of a set of interface mixin members (matching MixinMembers), which are the constants, regular operations, regular attributes, and stringifiers that appear between the braces in the interface mixin declaration.

These constants, regular operations, regular attributes, and stringifiers describe the behaviors that can be implemented by an object, as if they were specified on the interface that includes them.

Static attributes, static operations, special operations except for stringifiers, and iterable, asynchronously iterable, maplike, and setlike declarations cannot appear in interface mixin declarations.

As with interfaces, the IDL for interface mixins can be split into multiple parts by using partial interface mixin definitions (matching partial interface MixinRest). The identifier of a partial interface mixin definition must be the same as the identifier of an interface mixin definition. All of the members that appear on each of the partial interface mixin definitions are considered to be members of the interface mixin itself, and—by extension—of the interfaces that include the interface mixin.

    interface mixin SomeMixin {
      /* mixin_members... */
    };

    partial interface mixin SomeMixin {
      /* mixin_members... */
    };

The order that members appear in has significance for property enumeration in the ECMAScript binding.

Note that unlike interfaces or dictionaries, interface mixins do not create types.

Of the extended attributes defined in this specification, only the [`Exposed`] and [`SecureContext`] extended attributes are applicable to interface mixins.

An includes statement is a definition (matching IncludesStatement) used to declare that all objects implementing an interface I (identified by the first identifier) must additionally include the members of interface mixin M (identified by the second identifier). Interface I is said to include interface mixin M.

    interface_identifier includes mixin_indentifier;

The first identifier must reference a interface I. The second identifier must reference an interface mixin M.

Each member of M is considered to be a member of each interface I, J, K, … that includes M, as if a copy of each member had been made. So for a given member m of M, interface I is considered to have a member mI, interface J is considered to have a member mJ, interface K is considered to have a member mK, and so on. The host interfaces of mI, mJ, and mK, are I, J, and K respectively.

Note: In ECMAScript, this implies that each regular operation declared as a member of interface mixin M, and exposed as a data property with a built-in function object value, is a distinct built-in function object in each interface prototype object whose associated interface includes M. Similarly, for attributes, each copy of the accessor property has distinct built-in function objects for its getters and setters.

The order of appearance of includes statements affects the order in which interface mixin are included by their host interface.

Member order isn’t clearly specified, in particular when interface mixins are defined in separate documents. It is discussed in issue #432.

No extended attributes defined in this specification are applicable to includes statements.

The following IDL fragment defines an interface, `Entry`, and an interface mixin, `Observable`. The includes statement specifies that `Observable`’s members are always included on objects implementing `Entry`.

    interface Entry {
      readonly attribute unsigned short entryType;
      // ...
    };

    interface mixin Observable {
      void addEventListener(DOMString type,
                            EventListener listener,
                            boolean useCapture);
      // ...
    };

    Entry includes Observable;

An ECMAScript implementation would thus have an `addEventListener` property in the prototype chain of every `Entry`:

    var e = getEntry();          // Obtain an instance of Entry.
    typeof e.addEventListener;   // Evaluates to "function".

    MixinRest :
        "mixin" identifier "{" MixinMembers "}" ";"

    MixinMembers :
        ExtendedAttributeList MixinMember MixinMembers
        ε

    MixinMember :
        Const
        RegularOperation
        Stringifier
        ReadOnly AttributeRest

    IncludesStatement :
        identifier "includes" identifier ";"

#### 2.3.1. Using mixins and partials

This section is informative.

Interface mixins allow the sharing of attributes, constants, and operations across multiple interfaces. If you’re only planning to extend a single interface, you might consider using a partial interface instead.

For example, instead of:

    interface mixin WindowSessionStorage {
      readonly attribute Storage sessionStorage;
    };
    Window includes WindowSessionStorage;

do:

    partial interface Window {
      readonly attribute Storage sessionStorage;
    };

Additionally, you can rely on extending interface mixins exposed by other specifications to target common use cases, such as exposing a set of attributes, constants, or operations across both window and worker contexts.

For example, instead of the common but verbose:

    interface mixin GlobalCrypto {
      readonly attribute Crypto crypto;
    };

    Window includes GlobalCrypto;
    WorkerGlobalScope includes GlobalCrypto;

you can extend the `WindowOrWorkerGlobalScope` interface mixin using a partial interface mixin:

    partial interface mixin WindowOrWorkerGlobalScope {
      readonly attribute Crypto crypto;
    };

### 2.4. Callback interfaces

A callback interface is a definition matching callback interface InterfaceRest. It can be implemented by any object, as described in § 2.12 Objects implementing interfaces.

Note: A callback interface is not an interface. The name and syntax are left over from earlier versions of this standard, where these concepts had more in common.

A callback interface is a specification of a set of callback interface members (matching CallbackInterfaceMembers). These are the members that appear between the braces in the interface declaration.

    callback interface identifier {
      /* interface_members... */
    };

Note: See also the similarly named callback function definition.

Callback interfaces must define exactly one regular operation.

Specification authors should not define callback interfaces unless required to describe the requirements of existing APIs. Instead, a callback function should be used.

The definition of `EventListener` as a callback interface is an example of an existing API that needs to allow objects with a given property (in this case `handleEvent`) to be considered to implement the interface. For new APIs, and those for which there are no compatibility concerns, using a callback function will allow only a function object (in the ECMAScript language binding).

Callback interfaces which declare constants must be annotated with an [`Exposed`] extended attribute.

    CallbackRestOrInterface :
        CallbackRest
        "interface" identifier "{" CallbackInterfaceMembers "}" ";"

    CallbackInterfaceMembers :
        ExtendedAttributeList CallbackInterfaceMember CallbackInterfaceMembers
        ε

    CallbackInterfaceMember :
        Const
        RegularOperation

### 2.5. Members

Interfaces, interface mixins, and namespaces are specifications of a set of members (respectively matching InterfaceMembers, MixinMembers, and NamespaceMembers), which are the constants, attributes, operations, and other declarations that appear between the braces of their declarations. Attributes describe the state that an object implementing the interface, interface mixin, or namespace will expose, and operations describe the behaviors that can be invoked on the object. Constants declare named constant values that are exposed as a convenience to users of objects in the system.

When an interface includes an interface mixin, each member of the interface mixin is also considered a member of the interface. In contrast, inherited interface members are not considered members of the interface.

The algorithm steps for every regular operation, regular attribute getter, and regular attribute setter’s defined on an interface or interface mixin have access to a this value, which is an IDL value of the interface type that the member is declared on or that includes the interface mixin the member is declared on.

Attribute setter’s algorithm steps also have access to the given value, which is an IDL value of the type the attribute is declared as.

Interfaces, interface mixins, callback interfaces and namespaces each support a different set of members, which are specified in § 2.2 Interfaces, § 2.3 Interface mixins, § 2.4 Callback interfaces, and § 2.6 Namespaces, and summarized in the following informative table:

| Interfaces | Callback interfaces | Interface mixins | Namespaces
--- | --- | --- | --- | ---
Constants | ● | ● | ● |
Regular attributes | ● |  | ● | Only read only attributes
Static attributes | ● |  |  |
Regular Operations | ● | ● | ● | ●
Special Operations | ● |  | Only stringifiers |
Static Operations | ● |  |  |
Iterable declarations | ● |  |  |
Asynchronously iterable declarations | ● |  |  |
Maplike declarations | ● |  |  |
Setlike declarations | ● |  |  |

#### 2.5.1. Constants

A constant is a declaration (matching Const) used to bind a constant value to a name. Constants can appear on interfaces and callback interfaces.

Constants have in the past primarily been used to define named integer codes in the style of an enumeration. The Web platform is moving away from this design pattern in favor of the use of strings. Editors who wish to use this feature are strongly advised to discuss this by filing an issue before proceeding.

    const type constant_identifier = 42;

The identifier of a constant must not be the same as the identifier of another interface member or callback interface member defined on the same interface or callback interface. The identifier also must not be "`length`", "`name`" or "`prototype`".

Note: These three names are the names of properties that are defined on the interface object in the ECMAScript language binding.

The type of a constant (matching ConstType) must not be any type other than a primitive type. If an identifier is used, it must reference a typedef whose type is a primitive type.

The ConstValue part of a constant declaration gives the value of the constant, which can be one of the two boolean literal tokens (true and false), an integer token, a decimal token, or one of the three special floating point constant values (-Infinity, Infinity and NaN).

Note: These values – in addition to strings and the empty sequence – can also be used to specify the default value of a dictionary member or of an optional argument. Note that strings, the empty sequence [], and the default dictionary {} cannot be used as the value of a constant.

The value of the boolean literal tokens true and false are the IDL `boolean` values `true` and `false`.

The value of an integer token is an integer whose value is determined as follows:

1. Let S be the sequence of characters matched by the integer token.

2. Let sign be −1 if S begins with U+002D HYPHEN-MINUS ("-"), and 1 otherwise.

3. Let base be the base of the number based on the characters that follow the optional leading U+002D HYPHEN-MINUS ("-") character:

   U+0030 DIGIT ZERO ("0"), U+0058 LATIN CAPITAL LETTER X ("X")
   U+0030 DIGIT ZERO ("0"), U+0078 LATIN SMALL LETTER X ("x")

     The base is 16.

   U+0030 DIGIT ZERO ("0")

     The base is 8.

   Otherwise

     The base is 10.

4. Let number be the result of interpreting all remaining characters following the optional leading U+002D HYPHEN-MINUS ("-") character and any characters indicating the base as an integer specified in base base.

5. Return sign × number.

The type of an integer token is the same as the type of the constant, dictionary member or optional argument it is being used as the value of. The value of the integer token must not lie outside the valid range of values for its type, as given in § 2.13 Types.

The value of a decimal token is either an IEEE 754 single-precision floating point number or an IEEE 754 double-precision floating point number, depending on the type of the constant, dictionary member or optional argument it is being used as the value for, determined as follows:

1. Let S be the sequence of characters matched by the decimal token.

2. Let result be the Mathematical Value that would be obtained if S were parsed as an ECMAScript NumericLiteral.

3. If the decimal token is being used as the value for a `float` or `unrestricted float`, then the value of the decimal token is the IEEE 754 single-precision floating point number closest to result.

4. Otherwise, the decimal token is being used as the value for a `double` or `unrestricted double`, and the value of the decimal token is the IEEE 754 double-precision floating point number closest to result. [IEEE-754]

The value of a constant value specified as Infinity, -Infinity or NaN is either an IEEE 754 single-precision floating point number or an IEEE 754 double-precision floating point number, depending on the type of the constant, dictionary member or optional argument is is being used as the value for:

Type `unrestricted float`, constant value Infinity

  The value is the IEEE 754 single-precision positive infinity value.

Type `unrestricted double`, constant value Infinity

  The value is the IEEE 754 double-precision positive infinity value.

Type `unrestricted float`, constant value -Infinity

  The value is the IEEE 754 single-precision negative infinity value.

Type `unrestricted double`, constant value -Infinity

  The value is the IEEE 754 double-precision negative infinity value.

Type `unrestricted float`, constant value NaN

  The value is the IEEE 754 single-precision NaN value with the bit pattern 0x7fc00000.

Type `unrestricted double`, constant value NaN

  The value is the IEEE 754 double-precision NaN value with the bit pattern 0x7ff8000000000000.

The type of a decimal token is the same as the type of the constant, dictionary member or optional argument it is being used as the value of. The value of the decimal token must not lie outside the valid range of values for its type, as given in § 2.13 Types. Also, Infinity, -Infinity and NaN must not be used as the value of a `float` or `double`.

The value of the null token is the special null value that is a member of the nullable types. The type of the null token is the same as the type of the constant, dictionary member or optional argument it is being used as the value of.

If VT is the type of the value assigned to a constant, and DT is the type of the constant, dictionary member or optional argument itself, then these types must be compatible, which is the case if DT and VT are identical, or DT is a nullable type whose inner type is VT.

Constants are not associated with particular instances of the interface or callback interface on which they appear. It is language binding specific whether constants are exposed on instances.

The ECMAScript language binding does however allow constants to be accessed through objects implementing the IDL interfaces on which the constants are declared. For example, with the following IDL:

    [Exposed=Window]
    interface A {
      const short rambaldi = 47;
    };

the constant value can be accessed in ECMAScript either as `A.rambaldi` or `instanceOfA.rambaldi`.

The following extended attributes are applicable to constants: [`Exposed`], [`SecureContext`].

    Const :
        "const" ConstType identifier "=" ConstValue ";"

    ConstValue :
        BooleanLiteral
        FloatLiteral
        integer

    BooleanLiteral :
        "true"
        "false"

    FloatLiteral :
        decimal
        "-Infinity"
        "Infinity"
        "NaN"

    ConstType :
        PrimitiveType
        identifier

The following IDL fragment demonstrates how constants of the above types can be defined.

    [Exposed=Window]
    interface Util {
      const boolean DEBUG = false;
      const octet LF = 10;
      const unsigned long BIT_MASK = 0x0000fc00;
      const double AVOGADRO = 6.022e23;
    };

#### 2.5.2. Attributes

An attribute is an interface member or namespace member (matching inherit AttributeRest, static ReadOnly AttributeRest, stringifier ReadOnly AttributeRest, ReadOnly AttributeRest, or AttributeRest) that is used to declare data fields with a given type and identifier whose value can be retrieved and (in some cases) changed. There are two kinds of attributes:

1. regular attributes, which are those used to declare that objects implementing the interface will have a data field member with the given identifier

       interface interface_identifier {
         attribute type identifier;
       };

2. static attributes, which are used to declare attributes that are not associated with a particular object implementing the interface

       interface interface_identifier {
         static attribute type identifier;
       };

If an attribute has no static keyword, then it declares a regular attribute. Otherwise, it declares a static attribute. Note that in addition to being interface members, read only regular attributes can be namespace members as well.

To get the underlying value of an attribute attr given a value target, return the result of performing the actions listed in the description of attr that occur on getting, or those listed in the description of the inherited attribute, if attr is declared to inherit its getter, with target as this if it is not null.

The identifier of an attribute must not be the same as the identifier of another interface member defined on the same interface. The identifier of a static attribute must not be "`prototype`".

The type of the attribute is given by the type (matching Type) that appears after the attribute keyword. If the Type is an identifier or an identifier followed by ?, then the identifier must identify an interface, enumeration, callback function, callback interface or typedef.

The type of the attribute, after resolving typedefs, must not be a nullable or non-nullable version of any of the following types:

- a sequence type

- a dictionary type

- a record type

- a union type that has a nullable or non-nullable sequence type, dictionary, or record as one of its flattened member types

The attribute is read only if the readonly keyword is used before the attribute keyword. An object that implements the interface on which a read only attribute is defined will not allow assignment to that attribute. It is language binding specific whether assignment is simply disallowed by the language, ignored or an exception is thrown.

    interface interface_identifier {
      readonly attribute type identifier;
    };

Attributes whose type is a promise type must be read only. Additionally, they cannot have any of the extended attributes [`LenientSetter`], [`PutForwards`], [`Replaceable`], or [`SameObject`].

A regular attribute that is not read only can be declared to inherit its getter from an ancestor interface. This can be used to make a read only attribute in an ancestor interface be writable on a derived interface. An attribute inherits its getter if its declaration includes inherit in the declaration. The read only attribute from which the attribute inherits its getter is the attribute with the same identifier on the closest ancestor interface of the one on which the inheriting attribute is defined. The attribute whose getter is being inherited must be of the same type as the inheriting attribute.

Note: The grammar ensures that inherit does not appear on a read only attribute or a static attribute.

    [Exposed=Window]
    interface Ancestor {
      readonly attribute TheType theIdentifier;
    };

    [Exposed=Window]
    interface Derived : Ancestor {
      inherit attribute TheType theIdentifier;
    };

When the stringifier keyword is used in a regular attribute declaration, it indicates that objects implementing the interface will be stringified to the value of the attribute. See § 2.5.5.1 Stringifiers for details.

    interface interface_identifier {
      stringifier attribute DOMString identifier;
    };

The following extended attributes are applicable to regular and static attributes: [`Exposed`], [`SameObject`], [`SecureContext`].

The following extended attributes are applicable only to regular attributes: [`LenientSetter`], [`LenientThis`], [`PutForwards`], [`Replaceable`], [`Unforgeable`].

    ReadOnlyMember :
        "readonly" ReadOnlyMemberRest

    ReadOnlyMemberRest :
        AttributeRest
        MaplikeRest
        SetlikeRest

    ReadWriteAttribute :
        "inherit" AttributeRest
        AttributeRest

    AttributeRest :
        "attribute" TypeWithExtendedAttributes AttributeName ";"

    AttributeName :
        AttributeNameKeyword
        identifier

    AttributeNameKeyword :
        "async"
        "required"

    ReadOnly :
        "readonly"
        ε

The following IDL fragment demonstrates how attributes can be declared on an interface:

    [Exposed=Window]
    interface Animal {

      // A simple attribute that can be set to any string value.
      readonly attribute DOMString name;

      // An attribute whose value can be assigned to.
      attribute unsigned short age;
    };

    [Exposed=Window]
    interface Person : Animal {

      // An attribute whose getter behavior is inherited from Animal, and need not be
      // specified in the description of Person.
      inherit attribute DOMString name;
    };

#### 2.5.3. Operations

An operation is an interface member, callback interface member or namespace member (matching static RegularOperation, stringifier RegularOperation, RegularOperation or SpecialOperation) that defines a behavior that can be invoked on objects implementing the interface. There are three kinds of operation:

1. regular operations, which are those used to declare that objects implementing the interface will have a method with the given identifier

       interface interface_identifier {
         return_type identifier(/* arguments... */);
       };

2. special operations, which are used to declare special behavior on objects implementing the interface, such as object indexing and stringification

       interface interface_identifier {
         /* special_keyword */ return_type identifier(/* arguments... */);
         /* special_keyword */ return_type (/* arguments... */);
       };

3. static operations, which are used to declare operations that are not associated with a particular object implementing the interface

       interface interface_identifier {
         static return_type identifier(/* arguments... */);
       };

If an operation has an identifier but no static keyword, then it declares a regular operation. If the operation has a special keyword used in its declaration (that is, any keyword matching Special, or the stringifier keyword), then it declares a special operation. A single operation can declare both a regular operation and a special operation; see § 2.5.5 Special operations for details on special operations. Note that in addition to being interface members, regular operations can also be callback interface members and namespace members.

If an operation has no identifier, then it must be declared to be a special operation using one of the special keywords.

The identifier of a regular operation or static operation must not be the same as the identifier of a constant or attribute defined on the same interface, callback interface or namespace. The identifier of a static operation must not be "`prototype`".

Note: The identifier can be the same as that of another operation on the interface, however. This is how operation overloading is specified.

The identifier of a static operation also must not be the same as the identifier of a regular operation defined on the same interface.

The return type of the operation is given by the type (matching ReturnType) that appears before the operation’s optional identifier. A return type of `void` indicates that the operation returns no value. If the return type is an identifier followed by ?, then the identifier must identify an interface, dictionary, enumeration, callback function, callback interface or typedef.

An operation’s arguments (matching ArgumentList) are given between the parentheses in the declaration. Each individual argument is specified as a type (matching Type) followed by an identifier (matching ArgumentName).

Note: For expressiveness, the identifier of an operation argument can also be specified as one of the keywords matching the ArgumentNameKeyword symbol without needing to escape it.

If the Type of an operation argument is an identifier followed by ?, then the identifier must identify an interface, enumeration, callback function, callback interface, or typedef. If the operation argument type is an identifier not followed by ?, then the identifier must identify any one of those definitions or a dictionary.

If the operation argument type, after resolving typedefs, is a nullable type, its inner type must not be a dictionary type.

    interface interface_identifier {
      return_type identifier(type identifier, type identifier /* , ... */);
    };

The identifier of each argument must not be the same as the identifier of another argument in the same operation declaration.

Each argument can be preceded by a list of extended attributes (matching ExtendedAttributeList), which can control how a value passed as the argument will be handled in language bindings.

    interface interface_identifier {
      return_type identifier([extended_attributes] type identifier, [extended_attributes] type identifier /* , ... */);
    };

The following IDL fragment demonstrates how regular operations can be declared on an interface:

    [Exposed=Window]
    interface Dimensions {
      attribute unsigned long width;
      attribute unsigned long height;
    };

    [Exposed=Window]
    interface Button {

      // An operation that takes no arguments and returns a boolean.
      boolean isMouseOver();

      // Overloaded operations.
      void setDimensions(Dimensions size);
      void setDimensions(unsigned long width, unsigned long height);
    };

An operation or constructor operation is considered to be variadic if the final argument uses the ... token just after the argument type. Declaring an operation to be variadic indicates that the operation can be invoked with any number of arguments after that final argument. Those extra implied formal arguments are of the same type as the final explicit argument in the operation declaration. The final argument can also be omitted when invoking the operation. An argument must not be declared with the ... token unless it is the final argument in the operation’s argument list.

    interface interface_identifier {
      return_type identifier(type... identifier);
      return_type identifier(type identifier, type... identifier);
    };

Extended attributes that take an argument list ([`NamedConstructor`], of those defined in this specification) and callback functions are also considered to be variadic when the ... token is used in their argument lists.

The following IDL fragment defines an interface that has two variadic operations:

    [Exposed=Window]
    interface IntegerSet {
      readonly attribute unsigned long cardinality;

      void union(long... ints);
      void intersection(long... ints);
    };

In the ECMAScript binding, variadic operations are implemented by functions that can accept the subsequent arguments:

    var s = getIntegerSet();  // Obtain an instance of IntegerSet.

    s.union();                // Passing no arguments corresponding to 'ints'.
    s.union(1, 4, 7);         // Passing three arguments corresponding to 'ints'.

A binding for a language that does not support variadic functions might specify that an explicit array or list of integers be passed to such an operation.

An argument is considered to be an optional argument if it is declared with the optional keyword. The final argument of a variadic operation is also considered to be an optional argument. Declaring an argument to be optional indicates that the argument value can be omitted when the operation is invoked. The final argument in an operation must not explicitly be declared to be optional if the operation is variadic.

    interface interface_identifier {
      return_type identifier(type identifier, optional type identifier);
    };

Optional arguments can also have a default value specified. If the argument’s identifier is followed by a U+003D EQUALS SIGN ("=") and a value (matching DefaultValue), then that gives the optional argument its default value. The implicitly optional final argument of a variadic operation must not have a default value specified. The default value is the value to be assumed when the operation is called with the corresponding argument omitted.

    interface interface_identifier {
      return_type identifier(type identifier, optional type identifier = "value");
    };

It is strongly suggested not to use a default value of true for `boolean`-typed arguments, as this can be confusing for authors who might otherwise expect the default conversion of undefined to be used (i.e., false).

If the type of an argument is a dictionary type or a union type that has a dictionary type as one of its flattened member types, and that dictionary type and its ancestors have no required members, and the argument is either the final argument or is followed only by optional arguments, then the argument must be specified as optional and have a default value provided.

This is to encourage API designs that do not require authors to pass an empty dictionary value when they wish only to use the dictionary’s default values.

Usually the default value provided will be {}, but in the case of a union type that has a dictionary type as one of its flattened member types a default value could be provided that initializes some other member of the union.

When a boolean literal token (true or false), the null token, an integer token, a decimal token or one of the three special floating point literal values (Infinity, -Infinity or NaN) is used as the default value, it is interpreted in the same way as for a constant.

Optional argument default values can also be specified using a string token, whose value is a string type determined as follows:

1. Let S be the sequence of Unicode scalar values matched by the string token with its leading and trailing U+0022 QUOTATION MARK ('"') characters removed.

2. Depending on the type of the argument:

   `DOMString`
   an enumeration type

     The value of the string token is the sequence of 16 bit unsigned integer code units (hereafter referred to just as code units) corresponding to the UTF-16 encoding of S.

   `ByteString`

     The value of the string token is the sequence of 8 bit unsigned integer code units corresponding to the UTF-8 encoding of S.

   `USVString`

     The value of the string token is S.

If the type of the optional argument is an enumeration, then its default value if specified must be one of the enumeration’s values.

Optional argument default values can also be specified using the two token value [], which represents an empty sequence value. The type of this value is the same as the type of the optional argument it is being used as the default value of. That type must be a sequence type, a nullable type whose inner type is a sequence type or a union type or nullable union type that has a sequence type in its flattened member types.

Optional argument default values can also be specified using the two token value {}, which represents a default-initialized (as if from ES null or an object with no properties) dictionary value. The type of this value is the same as the type of the optional argument it is being used as the default value of. That type must be a dictionary type, or a union type that has a dictionary type in its flattened member types.

The following IDL fragment defines an interface with a single operation that can be invoked with two different argument list lengths:

    [Exposed=Window]
    interface ColorCreator {
      object createColor(double v1, double v2, double v3, optional double alpha);
    };

It is equivalent to an interface that has two overloaded operations:

    [Exposed=Window]
    interface ColorCreator {
      object createColor(double v1, double v2, double v3);
      object createColor(double v1, double v2, double v3, double alpha);
    };

The following IDL fragment defines an interface with an operation that takes a dictionary argument:

    dictionary LookupOptions {
      boolean caseSensitive = false;
    };

    [Exposed=Window]
    interface AddressBook {
      boolean hasAddressForName(USVString name, optional LookupOptions options = {});
    };

If `hasAddressForName` is called with only one argument, the second argument will be a default-initialized `LookupOptions` dictionary, which will cause `caseSensitive` to be set to false.

The following extended attributes are applicable to operations: [`Default`], [`Exposed`], [`NewObject`], [`SecureContext`], [`Unforgeable`].

    DefaultValue :
        ConstValue
        string
        "[" "]"
        "{" "}"
        "null"

    Operation :
        RegularOperation
        SpecialOperation

    RegularOperation :
        ReturnType OperationRest

    SpecialOperation :
        Special RegularOperation

    Special :
        "getter"
        "setter"
        "deleter"

    OperationRest :
        OptionalOperationName "(" ArgumentList ")" ";"

    OptionalOperationName :
        OperationName
        ε

    OperationName :
        OperationNameKeyword
        identifier

    OperationNameKeyword :
        "includes"

    ArgumentList :
        Argument Arguments
        ε

    Arguments :
        "," Argument Arguments
        ε

    Argument :
        ExtendedAttributeList ArgumentRest

    ArgumentRest :
        "optional" TypeWithExtendedAttributes ArgumentName Default
        Type Ellipsis ArgumentName

    ArgumentName :
        ArgumentNameKeyword
        identifier

    Ellipsis :
        "..."
        ε

    ReturnType :
        Type
        "void"

##### 2.5.3.1. toJSON

By declaring a `toJSON` regular operation, an interface specifies how to convert the objects that implement it to JSON types.

The `toJSON` regular operation is reserved for this usage. It must take zero arguments and return a JSON type.

The JSON types are:

- numeric types,

- `boolean`,

- string types,

- nullable types whose inner type is a JSON type,

- annotated types whose inner type is a JSON type,

- union types whose member types are JSON types,

- typedefs whose type being given a new name is a JSON type,

- sequence types whose parameterized type is a JSON type,

- frozen array types whose parameterized type is a JSON type,

- dictionary types where the types of all members declared on the dictionary and all its inherited dictionaries are JSON types,

- records where all of their values are JSON types,

- `object`,

- interface types that have a `toJSON` operation declared on themselves or one of their inherited interfaces.

How the `toJSON` regular operation is made available on an object in a language binding, and how exactly the JSON types are converted into a JSON string, is language binding specific.

Note: In the ECMAScript language binding, this is done by exposing a `toJSON` method which returns the JSON type converted into an ECMAScript value that can be turned into a JSON string by the `JSON.stringify()` function. Additionally, in the ECMAScript language binding, the `toJSON` operation can take a [`Default`] extended attribute, in which case the default toJSON operation is exposed instead.

The following IDL fragment defines an interface `Transaction` that has a `toJSON` method defined in prose:

    [Exposed=Window]
    interface Transaction {
      readonly attribute DOMString from;
      readonly attribute DOMString to;
      readonly attribute double amount;
      readonly attribute DOMString description;
      readonly attribute unsigned long number;
      TransactionJSON toJSON();
    };

    dictionary TransactionJSON {
      Account from;
      Account to;
      double amount;
      DOMString description;
    };

The `toJSON` regular operation of `Transaction` interface could be defined as follows:

To invoke the `toJSON()` operation of the `Transaction` interface, run the following steps:

1. Let json be a new `TransactionJSON` dictionary.

2. For each attribute identifier attr in « "from", "to", "amount", "description" »:

   1. Let value be result of getting the underlying value of the attribute identified by attr, given this.

   2. Set json[attr] to value.

3. Return json.

In the ECMAScript language binding, there would exist a `toJSON()` method on `Transaction` objects:

    // Get an instance of Transaction.
    var txn = getTransaction();

    // Evaluates to an object like this:
    // {
    //   from: "Bob",
    //   to: "Alice",
    //   amount: 50,
    //   description: "books"
    // }
    txn.toJSON();

    // Evaluates to a string like this:
    // '{"from":"Bob","to":"Alice","amount":50,"description":"books"}'
    JSON.stringify(txn);

#### 2.5.4. Constructor operations

If an interface has a constructor operation member (matching Constructor), it indicates that it is possible to create objects that implement the interface using a constructor.

Multiple constructor operations may appear on a given interface. For each constructor operation on the interface, there will be a way to attempt to construct an instance by passing the specified arguments.

The prose definition of a constructor operation must either initialize the value passed as this, or throw an exception.

See § 3.6.1 Interface object for details on how a constructor operation is to be implemented.

The following IDL defines two interfaces. The second has constructor operations, while the first does not.

    [Exposed=Window]
    interface NodeList {
      Node item(unsigned long index);
      readonly attribute unsigned long length;
    };

    [Exposed=Window]
    interface Circle {
      constructor();
      constructor(double radius);
      attribute double r;
      attribute double cx;
      attribute double cy;
      readonly attribute double circumference;
    };

An ECMAScript implementation supporting these interfaces would implement a [[Construct]] internal method on the `Circle` interface object which would return a new object that implements the interface. It would take either zero or one argument.

It is unclear whether the `NodeList` interface object would implement a [[Construct]] internal method. In any case, trying to use it as a constructor will cause a `TypeError` to be thrown. <https://github.com/heycam/webidl/issues/698>

    var x = new Circle();      // This uses the zero-argument constructor to create a
                               // reference to a platform object that implements the
                               // Circle interface.

    var y = new Circle(1.25);  // This also creates a Circle object, this time using
                               // the one-argument constructor.

    var z = new NodeList();    // This would throw a TypeError, since no
                               // constructor is declared.

    Constructor :
        "constructor" "(" ArgumentList ")" ";"

#### 2.5.5. Special operations

A special operation is a declaration of a certain kind of special behavior on objects implementing the interface on which the special operation declarations appear. Special operations are declared by using a special keyword in an operation declaration.

There are four kinds of special operations. The table below indicates for a given kind of special operation what special keyword is used to declare it and what the purpose of the special operation is:

Special operation | Keyword | Purpose
--- | --- | ---
Getters | getter | Defines behavior for when an object is indexed for property retrieval.
Setters | setter | Defines behavior for when an object is indexed for property assignment or creation.
Deleters | deleter | Defines behavior for when an object is indexed for property deletion.
Stringifiers | stringifier | Defines how an object is converted into a `DOMString`.

Not all language bindings support all of the four kinds of special object behavior. When special operations are declared using operations with no identifier, then in language bindings that do not support the particular kind of special operations there simply will not be such functionality.

The following IDL fragment defines an interface with a getter and a setter:

    [Exposed=Window]
    interface Dictionary {
      readonly attribute unsigned long propertyCount;

      getter double (DOMString propertyName);
      setter void (DOMString propertyName, double propertyValue);
    };

In language bindings that do not support property getters and setters, objects implementing Dictionary will not have that special behavior.

Defining a special operation with an identifier is equivalent to separating the special operation out into its own declaration without an identifier. This approach is allowed to simplify prose descriptions of an interface’s operations.

The following two interfaces are equivalent:

    [Exposed=Window]
    interface Dictionary {
      readonly attribute unsigned long propertyCount;

      getter double getProperty(DOMString propertyName);
      setter void setProperty(DOMString propertyName, double propertyValue);
    };

    [Exposed=Window]
    interface Dictionary {
      readonly attribute unsigned long propertyCount;

      double getProperty(DOMString propertyName);
      void setProperty(DOMString propertyName, double propertyValue);

      getter double (DOMString propertyName);
      setter void (DOMString propertyName, double propertyValue);
    };

A given special keyword must not appear twice on an operation.

Getters and setters come in two varieties: ones that take a `DOMString` as a property name, known as named property getters and named property setters, and ones that take an `unsigned long` as a property index, known as indexed property getters and indexed property setters. There is only one variety of deleter: named property deleters. See § 2.5.5.2 Indexed properties and § 2.5.5.3 Named properties for details.

On a given interface, there must exist at most one stringifier, at most one named property deleter, and at most one of each variety of getter and setter.

If an interface has a setter of a given variety, then it must also have a getter of that variety. If it has a named property deleter, then it must also have a named property getter.

Special operations declared using operations must not be variadic nor have any optional arguments.

If an object implements more than one interface that defines a given special operation, then it is undefined which (if any) special operation is invoked for that operation.

##### 2.5.5.1. Stringifiers

When an interface has a stringifier, it indicates that objects that implement the interface have a non-default conversion to a string. As mentioned above, stringifiers can be specified using an operation declared with the stringifier keyword.

    interface interface_identifier {
      stringifier DOMString identifier();
      stringifier DOMString ();
    };

If an operation used to declare a stringifier does not have an identifier, then prose accompanying the interface must define the stringification behavior of the interface. If the operation does have an identifier, then the object is converted to a string by invoking the operation to obtain the string.

Stringifiers declared with operations must be declared to take zero arguments and return a `DOMString`.

As a shorthand, if the stringifier keyword is declared using an operation with no identifier, then the operation’s return type and argument list can be omitted.

    interface interface_identifier {
      stringifier;
    };

The following two interfaces are equivalent:

    [Exposed=Window]
    interface A {
      stringifier DOMString ();
    };

    [Exposed=Window]
    interface A {
      stringifier;
    };

The stringifier keyword can also be placed on an attribute. In this case, the string to convert the object to is the value of the attribute. The stringifier keyword must not be placed on an attribute unless it is declared to be of type `DOMString` or `USVString`. It also must not be placed on a static attribute.

    interface interface_identifier {
      stringifier attribute DOMString identifier;
    };

    Stringifier :
        "stringifier" StringifierRest

    StringifierRest :
        ReadOnly AttributeRest
        RegularOperation
        ";"

The following IDL fragment defines an interface that will stringify to the value of its `name` attribute:

    [Exposed=Window]
    interface Student {
      constructor();
      attribute unsigned long id;
      stringifier attribute DOMString name;
    };

In the ECMAScript binding, using a `Student` object in a context where a string is expected will result in the value of the object’s `name` property being used:

    var s = new Student();
    s.id = 12345678;
    s.name = '周杰倫';

    var greeting = 'Hello, ' + s + '!';  // Now greeting == 'Hello, 周杰倫!'.

The following IDL fragment defines an interface that has custom stringification behavior that is not specified in the IDL itself.

    [Exposed=Window]
    interface Student {
      constructor();
      attribute unsigned long id;
      attribute DOMString? familyName;
      attribute DOMString givenName;

      stringifier DOMString ();
    };

Thus, prose is required to explain the stringification behavior, such as the following paragraph:

> Objects that implement the `Student` interface must stringify as follows. If the value of the `familyName` attribute is null, the stringification of the object is the value of the `givenName` attribute. Otherwise, if the value of the `familyName` attribute is not null, the stringification of the object is the concatenation of the value of the `givenName` attribute, a single space character, and the value of the `familyName` attribute.

An ECMAScript implementation of the IDL would behave as follows:

    var s = new Student();
    s.id = 12345679;
    s.familyName = 'Smithee';
    s.givenName = 'Alan';

    var greeting = 'Hi ' + s;  // Now greeting == 'Hi Alan Smithee'.

##### 2.5.5.2. Indexed properties

An interface that defines an indexed property getter is said to support indexed properties. By extension, a platform object is said to support indexed properties if it implements an interface that itself does.

If an interface supports indexed properties, then the interface definition must be accompanied by a description of what indices the object can be indexed with at any given time. These indices are called the supported property indices.

Interfaces that support indexed properties must define an integer-typed attribute named "`length`".

Indexed property getters must be declared to take a single `unsigned long` argument. Indexed property setters must be declared to take two arguments, where the first is an `unsigned long`.

    interface interface_identifier {
      getter type identifier(unsigned long identifier);
      setter type identifier(unsigned long identifier, type identifier);

      getter type (unsigned long identifier);
      setter type (unsigned long identifier, type identifier);
    };

The following requirements apply to the definitions of indexed property getters and setters:

- If an indexed property getter was specified using an operation with an identifier, then the value returned when indexing the object with a given supported property index is the value that would be returned by invoking the operation, passing the index as its only argument. If the operation used to declare the indexed property getter did not have an identifier, then the interface definition must be accompanied by a description of how to determine the value of an indexed property for a given index.

- If an indexed property setter was specified using an operation with an identifier, then the behavior that occurs when indexing the object for property assignment with a given supported property index and value is the same as if the operation is invoked, passing the index as the first argument and the value as the second argument. If the operation used to declare the indexed property setter did not have an identifier, then the interface definition must be accompanied by a description of how to set the value of an existing indexed property and how to set the value of a new indexed property for a given property index and value.

Note that if an indexed property getter or setter is specified using an operation with an identifier, then indexing an object with an integer that is not a supported property index does not necessarily elicit the same behavior as invoking the operation with that index. The actual behavior in this case is language binding specific.

In the ECMAScript language binding, a regular property lookup is done. For example, take the following IDL:

    [Exposed=Window]
    interface A {
      getter DOMString toWord(unsigned long index);
    };

Assume that an object implementing `A` has supported property indices in the range 0 ≤ index < 2. Also assume that toWord is defined to return its argument converted into an English word. The behavior when invoking the operation with an out of range index is different from indexing the object directly:

    var a = getA();

    a.toWord(0);  // Evalautes to "zero".
    a[0];         // Also evaluates to "zero".

    a.toWord(5);  // Evaluates to "five".
    a[5];         // Evaluates to undefined, since there is no property "5".

The following IDL fragment defines an interface `OrderedMap` which allows retrieving and setting values by name or by index number:

    [Exposed=Window]
    interface OrderedMap {
      readonly attribute unsigned long size;

      getter any getByIndex(unsigned long index);
      setter void setByIndex(unsigned long index, any value);

      getter any get(DOMString name);
      setter void set(DOMString name, any value);
    };

Since all of the special operations are declared using operations with identifiers, the only additional prose that is necessary is that which describes what keys those sets have. Assuming that the `get()` operation is defined to return null if an attempt is made to look up a non-existing entry in the `OrderedMap`, then the following two sentences would suffice:

> An object map implementing `OrderedMap` supports indexed properties with indices in the range 0 ≤ index < `map.size`.

> Such objects also support a named property for every name that, if passed to `get()`, would return a non-null value.

As described in § 3.8 Legacy platform objects, an ECMAScript implementation would create properties on a legacy platform object implementing `OrderedMap` that correspond to entries in both the named and indexed property sets. These properties can then be used to interact with the object in the same way as invoking the object’s methods, as demonstrated below:

    // Assume map is a legacy platform object implementing the OrderedMap interface.
    var map = getOrderedMap();
    var x, y;

    x = map[0];       // If map.length > 0, then this is equivalent to:
                      //
                      //   x = map.getByIndex(0)
                      //
                      // since a property named "0" will have been placed on map.
                      // Otherwise, x will be set to undefined, since there will be
                      // no property named "0" on map.

    map[1] = false;   // This will do the equivalent of:
                      //
                      //   map.setByIndex(1, false)

    y = map.apple;    // If there exists a named property named "apple", then this
                      // will be equivalent to:
                      //
                      //   y = map.get('apple')
                      //
                      // since a property named "apple" will have been placed on
                      // map.  Otherwise, y will be set to undefined, since there
                      // will be no property named "apple" on map.

    map.berry = 123;  // This will do the equivalent of:
                      //
                      //   map.set('berry', 123)

    delete map.cake;  // If a named property named "cake" exists, then the "cake"
                      // property will be deleted, and then the equivalent to the
                      // following will be performed:
                      //
                      //   map.remove("cake")

##### 2.5.5.3. Named properties

An interface that defines a named property getter is said to support named properties. By extension, a platform object is said to support named properties if it implements an interface that itself does.

If an interface supports named properties, then the interface definition must be accompanied by a description of the ordered set of names that can be used to index the object at any given time. These names are called the supported property names.

Named property getters and deleters must be declared to take a single `DOMString` argument. Named property setters must be declared to take two arguments, where the first is a `DOMString`.

    interface interface_identifier {
      getter type identifier(DOMString identifier);
      setter type identifier(DOMString identifier, type identifier);
      deleter type identifier(DOMString identifier);

      getter type (DOMString identifier);
      setter type (DOMString identifier, type identifier);
      deleter type (DOMString identifier);
    };

The following requirements apply to the definitions of named property getters, setters and deleters:

- If a named property getter was specified using an operation with an identifier, then the value returned when indexing the object with a given supported property name is the value that would be returned by invoking the operation, passing the name as its only argument. If the operation used to declare the named property getter did not have an identifier, then the interface definition must be accompanied by a description of how to determine the value of a named property for a given property name.

- If a named property setter was specified using an operation with an identifier, then the behavior that occurs when indexing the object for property assignment with a given supported property name and value is the same as if the operation is invoked, passing the name as the first argument and the value as the second argument. If the operation used to declare the named property setter did not have an identifier, then the interface definition must be accompanied by a description of how to set the value of an existing named property and how to set the value of a new named property for a given property name and value.

- If a named property deleter was specified using an operation with an identifier, then the behavior that occurs when indexing the object for property deletion with a given supported property name is the same as if the operation is invoked, passing the name as the only argument. If the operation used to declare the named property deleter did not have an identifier, then the interface definition must be accompanied by a description of how to delete an existing named property for a given property name.

Note: As with indexed properties, if an named property getter, setter or deleter is specified using an operation with an identifier, then indexing an object with a name that is not a supported property name does not necessarily elicit the same behavior as invoking the operation with that name; the behavior is language binding specific.

#### 2.5.6. Static attributes and operations

Static attributes and static operations are ones that are not associated with a particular instance of the interface on which it is declared, and is instead associated with the interface itself. Static attributes and operations are declared by using the static keyword in their declarations.

It is language binding specific whether it is possible to invoke a static operation or get or set a static attribute through a reference to an instance of the interface.

    StaticMember :
        "static" StaticMemberRest

    StaticMemberRest :
        ReadOnly AttributeRest
        RegularOperation

The following IDL fragment defines an interface `Circle` that has a static operation declared on it:

    [Exposed=Window]
    interface Point { /* ... */ };

    [Exposed=Window]
    interface Circle {
      attribute double cx;
      attribute double cy;
      attribute double radius;

      static readonly attribute long triangulationCount;
      static Point triangulate(Circle c1, Circle c2, Circle c3);
    };

In the ECMAScript language binding, the function object for `triangulate` and the accessor property for `triangulationCount` will exist on the interface object for `Circle`:

    var circles = getCircles();           // an Array of Circle objects

    typeof Circle.triangulate;            // Evaluates to "function"
    typeof Circle.triangulationCount;     // Evaluates to "number"
    Circle.prototype.triangulate;         // Evaluates to undefined
    Circle.prototype.triangulationCount;  // Also evaluates to undefined
    circles[0].triangulate;               // As does this
    circles[0].triangulationCount;        // And this

    // Call the static operation
    var triangulationPoint = Circle.triangulate(circles[0], circles[1], circles[2]);

    // Find out how many triangulations we have done
    window.alert(Circle.triangulationCount);

#### 2.5.7. Overloading

If a regular operation or static operation defined on an interface has an identifier that is the same as the identifier of another operation on that interface of the same kind (regular or static), then the operation is said to be overloaded. When the identifier of an overloaded operation is used to invoke one of the operations on an object that implements the interface, the number and types of the arguments passed to the operation determine which of the overloaded operations is actually invoked. Constructor operations can be overloaded too. There are some restrictions on the arguments that overloaded operations and constructors can be specified to take, and in order to describe these restrictions, the notion of an effective overload set is used.

Operations must not be overloaded across interface, partial interface, interface mixin, and partial interface mixin definitions.

For example, the overloads for both f and g are disallowed:

    [Exposed=Window]
    interface A {
      void f();
    };

    partial interface A {
      void f(double x);
      void g();
    };

    partial interface A {
      void g(DOMString x);
    };

Note that constructor operations and [`NamedConstructor`] extended attributes are disallowed from appearing on partial interface definitions, so there is no need to also disallow overloading for constructors.

An effective overload set represents the allowable invocations for a particular operation, constructor (specified with a constructor operation or [`NamedConstructor`]), or callback function. The algorithm to compute the effective overload set operates on one of the following four types of IDL constructs, and listed with them below are the inputs to the algorithm needed to compute the set.

For regular operations
For static operations

  - the interface on which the operations are to be found

  - the identifier of the operations

  - the number of arguments to be passed

For constructors

  - the interface on which the constructor operations are to be found

  - the number of arguments to be passed

For named constructors

  - the interface on which the [`NamedConstructor`] extended attributes are to be found

  - the identifier of the named constructors

  - the number of arguments to be passed

An effective overload set is used, among other things, to determine whether there are ambiguities in the overloaded operations and constructors specified on an interface.

The items of an effective overload set are tuples of the form (callable, type list, optionality list) whose items are described below:

- A callable is an operation if the effective overload set is for regular operations, static operations, or constructor operations; and it is an extended attribute if the effective overload set is for named constructors.

- A type list is a list of IDL types.

- An optionality list is a list of three possible optionality values – "required", "optional" or "variadic" – indicating whether the argument at a given index was declared as being optional or corresponds to a variadic argument.

Each tuple represents an allowable invocation of the operation, constructor, or callback function with an argument value list of the given types. Due to the use of optional arguments and variadic operations and constructors, there may be multiple items in an effective overload set identifying the same operation or constructor.

The algorithm below describes how to compute the effective overload set. The following input variables are used, if they are required:

- the identifier of the operation or named constructor is A

- the argument count is N

- the interface is I

Whenever an argument of an extended attribute is mentioned, it is referring to an argument of the extended attribute’s named argument list.

1. Let S be an ordered set.

2. Let F be an ordered set with items as follows, according to the kind of effective overload set:

   For regular operations

     The elements of F are the regular operations with identifier A defined on interface I.

   For static operations

     The elements of F are the static operations with identifier A defined on interface I.

   For constructors

     The elements of F are the constructor operations on interface I.

   For named constructors

     The elements of F are the [`NamedConstructor`] extended attributes on interface I whose named argument lists’ identifiers are A.

3. Let maxarg be the maximum number of arguments the operations, constructor extended attributes or callback functions in F are declared to take. For variadic operations and constructor extended attributes, the argument on which the ellipsis appears counts as a single argument.

   Note: So `void f(long x, long... y);` is considered to be declared to take two arguments.

4. Let max be max(maxarg, N).

5. For each operation or extended attribute X in F:

   1. Let arguments be the list of arguments X is declared to take.

   2. Let n be the size of arguments.

   3. Let types be a type list.

   4. Let optionalityValues be an optionality list.

   5. For each argument in arguments:

      1. Append the type of argument to types.

      2. Append "variadic" to optionalityValues if argument is a final, variadic argument, "optional" if argument is optional, and "required" otherwise.

   6. Append the tuple (X, types, optionalityValues) to S.

   7. If X is declared to be variadic, then:

      1. For each i in the range n to max − 1, inclusive:

         1. Let t be a type list.

         2. Let o be an optionality list.

         3. For each j in the range 0 to n − 1, inclusive:

            1. Append types[j] to t.

            2. Append optionalityValues[j] to o.

         4. For each j in the range n to i, inclusive:

            1. Append types[n − 1] to t.

            2. Append "variadic" to o.

         5. Append the tuple (X, t, o) to S.

   8. Let i be n − 1.

   9. While i ≥ 0:

      1. If arguments[i] is not optional (i.e., it is not marked as "optional" and is not a final, variadic argument), then break.

      2. Let t be a type list.

      3. Let o be an optionality list.

      4. For each j in the range 0 to i − 1, inclusive:

         1. Append types[j] to t.

         2. Append optionalityValues[j] to o.

      5. Append the tuple (X, t, o) to S.

         Note: if i is 0, this means to add to S the tuple (X, « », « »); (where "« »" represents an empty list).

      6. Set i to i − 1.

6. Return S.

For the following interface:

    [Exposed=Window]
    interface A {
      /* f1 */ void f(DOMString a);
      /* f2 */ void f(Node a, DOMString b, double... c);
      /* f3 */ void f();
      /* f4 */ void f(Event a, DOMString b, optional DOMString c, double... d);
    };

assuming `Node` and `Event` are two other interfaces of which no object can implement both, the effective overload set for regular operations with identifier `f` and argument count 4 is:

    «
      (f1, « DOMString »,                           « required »),
      (f2, « Node, DOMString »,                     « required, required »),
      (f2, « Node, DOMString, double »,             « required, required, variadic »),
      (f2, « Node, DOMString, double, double »,     « required, required, variadic, variadic »),
      (f3, « »,                                     « »),
      (f4, « Event, DOMString »,                    « required, required »),
      (f4, « Event, DOMString, DOMString »,         « required, required, optional »),
      (f4, « Event, DOMString, DOMString, double », « required, required, optional, variadic »)
    »

Two types are distinguishable if the following algorithm returns true.

1. If one type includes a nullable type and the other type either includes a nullable type, is a union type with flattened member types including a dictionary type, or is a dictionary type, return false.

   None of the following pairs are distinguishable:
   - ``double`?` and `Dictionary1`
   - `(Interface1 or `long`)?` and `(Interface2 or `DOMString`)?`
   - `(Interface1 or `long`?)` and `(Interface2 or `DOMString`)?`
   - `(Interface1 or `long`?)` and `(Interface2 or `DOMString`?)`
   - `(Dictionary1 or `long`)` and `(Interface2 or `DOMString`)?`
   - `(Dictionary1 or `long`)` and `(Interface2 or `DOMString`?)`

2. If both types are either a union type or nullable union type, return true if each member type of the one is distinguishable with each member type of the other, or false otherwise.

3. If one type is a union type or nullable union type, return true if each member type of the union type is distinguishable with the non-union type, or false otherwise.

4. Consider the two "innermost" types derived by taking each type’s inner type if it is an annotated type, and then taking its inner type inner type if the result is a nullable type. If these two innermost types appear or are in categories appearing in the following table and there is a “●” mark in the corresponding entry or there is a letter in the corresponding entry and the designated additional requirement below the table is satisfied, then return true. Otherwise return false.

   Categories:

   interface-like

     - interface types

     - buffer source types

   dictionary-like

     - dictionary types

     - record types

     - callback interface types

   sequence-like

     - sequence types

     - frozen array types

   | boolean | numeric types | string types | object | symbol | interface-like | callback function | dictionary-like | sequence-like
   --- | --- | --- | --- | --- | --- | --- | --- | --- | ---
   boolean |  | ● | ● | ● | ● | ● | ● | ● | ●
   numeric types |  |  | ● | ● | ● | ● | ● | ● | ●
   string types |  |  |  | ● | ● | ● | ● | ● | ●
   object |  |  |  |  | ● |  |  |  |
   symbol |  |  |  |  |  | ● | ● | ● | ●
   interface-like |  |  |  |  |  | (a) | ● | ● | ●
   callback function |  |  |  |  |  |  |  |  | ●
   dictionary-like |  |  |  |  |  |  |  |  | ●
   sequence-like |  |  |  |  |  |  |  |  |

   1. The two identified interface-like types are not the same, and no single platform object implements both interface-like types.

   `double` and `DOMString` are distinguishable because there is a ● at the intersection of numeric types with string types.
   `double` and `long` are not distinguishable because they are both numeric types, and there is no ● or letter at the intersection of numeric types with numeric types.
   Given:

       callback interface CBIface {
           void handle();
       };

       [Exposed=Window]
       interface Iface {
           attribute DOMString attr2;
       };

       dictionary Dict {
           DOMString field1;
       };

   `CBIface` is distinguishable from `Iface` because there’s a ● at the intersection of dictionary-like and interface-like, but it is not distinguishable from `Dict` because there’s no ● at the intersection of dictionary-like and itself.

   Promise types do not appear in the above table, and as a consequence are not distinguishable with any other type.

If there is more than one item in an effective overload set that has a given type list size, then for those items there must be an index i such that for each pair of items the types at index i are distinguishable. The lowest such index is termed the distinguishing argument index for the items of the effective overload set with the given type list size.

Consider the effective overload set shown in the previous example. There are multiple items in the set with type lists 2, 3 and 4. For each of these type list size, the distinguishing argument index is 0, since `Node` and `Event` are distinguishable.

The following use of overloading however is invalid:

    [Exposed=Window]
    interface B {
      void f(DOMString x);
      void f(USVString x);
    };

since `DOMString` and `USVString` are not distinguishable.

In addition, for each index j, where j is less than the distinguishing argument index for a given type list size, the types at index j in all of the items’ type lists must be the same, and the optionality values at index j in all of the items’ optionality lists must be the same.

The following is invalid:

    [Exposed=Window]
    interface B {
      /* f1 */ void f(DOMString w);
      /* f2 */ void f(long w, double x, Node y, Node z);
      /* f3 */ void f(double w, double x, DOMString y, Node z);
    };

For argument count 4, the effective overload set is:

    «
      (f1, « DOMString »,                       « required »),
      (f2, « long, double, Node, Node »,        « required, required, required, required »),
      (f3, « double, double, DOMString, Node », « required, required, required, required »)
    »

Looking at items with type list size 4, the distinguishing argument index is 2, since `Node` and `DOMString` are distinguishable. However, since the arguments in these two overloads at index 0 are different, the overloading is invalid.

##### 2.5.7.1. Overloading vs. union types

This section is informative.

For specifications defining IDL operations, it might seem that overloads and a combination of union types and optional arguments have some feature overlap.

It is first important to note that overloads have different behaviors than union types or optional arguments, and one cannot be fully defined using the other (unless, of course, additional prose is provided, which can defeat the purpose of the Web IDL type system). For example, consider the `stroke()` operations defined on the `CanvasDrawPath` interface [HTML]:

    interface CanvasDrawPathExcerpt {
      void stroke();
      void stroke(Path2D path);
    };

Per the ECMAScript language binding, calling `stroke(undefined)` on an object implementing `CanvasDrawPathExcerpt` would attempt to call the second overload, yielding a `TypeError` since undefined cannot be converted to a `Path2D`. However, if the operations were instead defined with optional arguments and merged into one,

    interface CanvasDrawPathExcerptOptional {
      void stroke(optional Path2D path);
    };

the overload resolution algorithm would treat the path argument as not present given the same call `stroke(undefined)`, and not throw any exceptions.

Note: For this particular example, the latter behavior is actually what Web developers would generally expect. If `CanvasDrawPath` were to be designed today, optional arguments would be used for `stroke()`.

Additionally, there are semantic differences as well. Union types are usually used in the sense that "any of the types would work in about the same way". In contrast, overloaded operations are designed to map well to language features such as C++ overloading, and are usually a better fit for operations with more substantial differences in what they do given arguments of different types. However, in most cases, operations with such substantial differences are best off with different names to avoid confusion for Web developers, since the ECMAScript language does not provide language-level overloading. As such, overloads are rarely appropriate for new APIs, instead often appearing in legacy APIs or in specialized circumstances.

That being said, we offer the following recommendations and examples in case of difficulties to determine what Web IDL language feature to use:

- In the unusual case where the operation needs to return values of different types for different argument types, overloading will result in more expressive IDL fragments. This is almost never appropriate API design, and separate operations with distinct names usually are a better choice for such cases.

  Suppose there is an operation `calculate()` that accepts a `long`, `DOMString`, or `CalculatableInterface` (an interface type) as its only argument, and returns a value of the same type as its argument. It would be clearer to write the IDL fragment using overloaded operations as

      interface A {
        long calculate(long input);
        DOMString calculate(DOMString input);
        CalculatableInterface calculate(CalculatableInterface input);
      };

  than using a union type with a typedef as

      typedef (long or DOMString or CalculatableInterface) Calculatable;
      interface A {
        Calculatable calculate(Calculatable input);
      };

  which does not convey the fact that the return value is always of the same type as input.

  The problem is exacerbated when one of the overloads has a return type of `void`, since union types cannot even contain `void` as a member type. In that case, a return type of `any` needs to be used with appropriate prose defining the return type, further decreasing expressiveness.

  If the specified `calculate()` is a new API and does not have any compatibility concerns, it is suggested to use different names for the overloaded operations, perhaps as

      interface A {
        long calculateNumber(long input);
        DOMString calculateString(DOMString input);
        CalculatableInterface calculateCalculatableInterface(CalculatableInterface input);
      };

  which allows Web developers to write explicit and unambiguous code.

- When the operation has significantly different semantics for different argument types or lengths, overloading is preferred. Again, in such scenarios, it is usually better to create separate operations with distinct names, but legacy APIs sometimes follow this pattern.

  As an example, the `supports(property, value)` and `supports(conditionText)` operations of the `CSS` interface are defined as the following IDL fragment [CSS3-CONDITIONAL] [CSSOM].

      partial interface CSS {
        static boolean supports(CSSOMString property, CSSOMString value);
        static boolean supports(CSSOMString conditionText);
      };

  Using optional arguments one can rewrite the IDL fragment as follows:

      partial interface CSSExcerptOptional {
        static boolean supports(CSSOMString propertyOrConditionText, optional CSSOMString value);
      };

  Even though the IDL is shorter in the second version, two distinctively different concepts are conflated in the first argument. Without overloads, the question "is property or conditionText paired with value?" is much more difficult to answer without reading the prose definition of the operation. This makes the second version remarkably less readable than the first.

  Another consideration is that the prose for overloaded operations can be specified in separate blocks, which can aid in both reading and writing specifications. This is not the case for optional arguments. This means that in the first case the specification author can write the prose definition of the operations as:

  The `supports(property, value)` method, when called, must run these steps:

  1. …

  The `supports(conditionText)` method, when called, must run these steps:

  1. …

  Yet using value as an optional argument, the specification author has to use more boilerplate-style text to effectively replicate the overload resolution algorithm.

  The `supports(propertyOrConditionText, value)` method, when called, must run these steps:

  1. If value is given, then:

     1. Let property be propertyOrConditionText.

     2. …

  2. Otherwise:

     1. Let conditionText be propertyOrConditionText.

     2. …

  If the two overloads have little to no shared parts, it is better to leave overload resolution to the IDL mechanism.

- If the operation accepts multiple types for multiple arguments with no coupling between types of different arguments, union types can sometimes be the only viable solution.

      typedef (long long or DOMString or CalculatableInterface) SupportedArgument;
      interface A {
        void add(SupportedArgument operand1, SupportedArgument operand2);
      };

  For the `add()` operation above, to specify it using overloads would require

      interface A {
        void add(long long operand1, long long operand2);
        void add(long long operand1, DOMString operand2);
        void add(long long operand1, CalculatableInterface operand2);
        void add(DOMString operand1, long long operand2);
        void add(DOMString operand1, DOMString operand2);
        void add(DOMString operand1, CalculatableInterface operand2);
        void add(CalculatableInterface operand1, long long operand2);
        void add(CalculatableInterface operand1, DOMString operand2);
        void add(CalculatableInterface operand1, CalculatableInterface operand2);
      };

  and nine times the corresponding prose!

- Specification authors are encouraged to treat missing argument and undefined argument the same way in the ECMAScript language binding.

  Given the following IDL fragment:

      interface A {
        void foo();
        void foo(Node? arg);
      };

  Using the ECMAScript language binding, calling `foo(undefined)` and `foo(null)` would both run the steps corresponding to the `foo(arg)` operation, with arg set to null, while `foo()` alone would go to the first overload. This can be a surprising behavior for many API users. Instead, specification authors are encouraged to use an optional argument, which would categorize both `foo()` and `foo(undefined)` as "arg is not present".

      interface A {
        void foo(optional Node? arg);
      };

  In general, optionality is best expressed using the optional keyword, and not using overloads.

When the case fits none of the categories above, it is up to the specification author to choose the style, since it is most likely that either style would sufficiently and conveniently describe the intended behavior. However, the definition and conversion algorithms of union types and optional arguments are simpler to implement and reason about than those of overloads, and usually result in more idiomatic APIs in the ECMAScript language binding. Thus, unless any other considerations apply, union types (and/or optional arguments) are the default choice.

Specifications are also free to mix and match union types and overloads, if the author finds it appropriate and convenient.

#### 2.5.8. Iterable declarations

An interface can be declared to be iterable by using an iterable declaration (matching Iterable) in the body of the interface.

    interface interface_identifier {
      iterable<value_type>;
      iterable<key_type, value_type>;
    };

Objects implementing an interface that is declared to be iterable support being iterated over to obtain a sequence of values.

Note: In the ECMAScript language binding, an interface that is iterable will have `entries`, `forEach`, `keys`, `values`, and `@@iterator` properties on its interface prototype object.

If a single type parameter is given, then the interface has a value iterator and provides values of the specified type. If two type parameters are given, then the interface has a pair iterator and provides value pairs with the given types.

A value pair, given a key type and a value type, is a struct with two items:

1. an item whose name is "key", which is referred to as the value pair's key, and whose value is an IDL value of the key type;

2. an item whose name is "value", which is referred to as the value pair's value, and whose value is an IDL value of the value type.

A value iterator must only be declared on an interface that supports indexed properties. The value-type of the value iterator must be the same as the type returned by the indexed property getter. A value iterator is implicitly defined to iterate over the object’s indexed properties.

A pair iterator must not be declared on an interface that supports indexed properties.

Prose accompanying an interface with a pair iterator must define a list of value pairs for each instance of the interface, which is the list of value pairs to iterate over.

The ECMAScript forEach method that is generated for a value iterator invokes its callback like Array.prototype.forEach does, and the forEach method for a pair iterator invokes its callback like Map.prototype.forEach does.

Since value iterators are currently allowed only on interfaces that support indexed properties, it makes sense to use an Array-like forEach method. There may be a need for value iterators (a) on interfaces that do not support indexed properties, or (b) with a forEach method that instead invokes its callback like Set.protoype.forEach (where the key is the same as the value). If you’re creating an API that needs such a forEach method, please file an issue.

Note: This is how array iterator objects work. For interfaces that support indexed properties, the iterator objects returned by `entries`, `keys`, `values`, and `@@iterator` are actual array iterator objects.

Interfaces with iterable declarations must not have any interface members named "`entries`", "`forEach`", "`keys`", or "`values`", or have any inherited interfaces that have members with these names.

Consider the following interface `SessionManager`, which allows access to a number of `Session` objects keyed by username:

    [Exposed=Window]
    interface SessionManager {
      Session getSessionForUser(DOMString username);

      iterable<DOMString, Session>;
    };

    [Exposed=Window]
    interface Session {
      readonly attribute DOMString username;
      // ...
    };

The behavior of the iterator could be defined like so:

> The value pairs to iterate over are the list of value pairs with the key being the username and the value being the open `Session` object on the `SessionManager` object corresponding to that username, sorted by username.

In the ECMAScript language binding, the interface prototype object for the `SessionManager` interface has a `values` method that is a function, which, when invoked, returns an iterator object that itself has a `next` method that returns the next value to be iterated over. It has `keys` and `entries` methods that iterate over the usernames of session objects and username/`Session` object pairs, respectively. It also has a `@@iterator` method that allows a `SessionManager` to be used in a `for..of` loop that has the same value as the `entries` method:

    // Get an instance of SessionManager.
    // Assume that it has sessions for two users, "anna" and "brian".
    var sm = getSessionManager();

    typeof SessionManager.prototype.values;            // Evaluates to "function"
    var it = sm.values();                              // values() returns an iterator object
    typeof it.next;                                    // Evaluates to "function"

    // This loop will log "anna" and then "brian".
    for (;;) {
      let result = it.next();
      if (result.done) {
        break;
      }
      let session = result.value;
      console.log(session.username);
    }

    // This loop will also log "anna" and then "brian".
    for (let username of sm.keys()) {
      console.log(username);
    }

    // Yet another way of accomplishing the same.
    for (let [username, session] of sm) {
      console.log(username);
    }

An interface must not have more than one iterable declaration. The inherited interfaces of an interface with an iterable declaration must not also have an iterable declaration. An interface with an iterable declaration and its inherited interfaces must not have a maplike declaration, setlike declaration, or asynchronously iterable declaration.

The following extended attributes are applicable to iterable declarations: [`Exposed`], [`SecureContext`].

    Iterable :
        "iterable" "<" TypeWithExtendedAttributes OptionalType ">" ";"

    OptionalType :
        "," TypeWithExtendedAttributes
        ε

#### 2.5.9. Asynchronously iterable declarations

An interface can be declared to be asynchronously iterable by using an asynchronously iterable declaration (matching AsyncIterable) in the body of the interface.

    interface interface_identifier {
      async iterable<key_type, value_type>;
    };

Objects that implement an interface that is declared to be asynchronously iterable support being iterated over asynchronously to obtain a sequence of values.

Note: In the ECMAScript language binding, an interface that is asynchronously iterable will have `entries`, `keys`, `values`, and `@@asyncIterator` properties on its interface prototype object.

Prose accompanying an interface with an asynchronously iterable declaration must define a get the next iteration result algorithm. This algorithm receives the instance of the interface that is being iterated, as well as the async iterator itself (which can be useful for storing state). It must return a `Promise` that either rejects, resolves with undefined to signal the end of the iteration, or resolves with a tuple containing two elements:

1. a value of the first type given in the declaration;

2. a value of the second type given in the declaration.

The prose may also define an asynchronous iterator return algorithm. This algorithm receives the instance of the interface that is being iterated, the async iterator itself, and a single argument value of type `any`. This algorithm is invoked in the case of premature termination of the async iterator. It must return a `Promise`; if that promise fulfills, its fulfillment value will be ignored, but if it rejects, that failure will be passed on to users of the async iterator API.

In the ECMAScript binding, this algorithm allows customizing the behavior when the async iterator’s `return()` method is invoked. This most commonly occurs when a `break` or `return` statement causes an exit from a `for`-`await`-`of` loop.

We could add a similar hook for `throw()`. So far there has been no need, but if you are creating an API that needs such capabilities, please file an issue.

The prose may also define asynchronous iterator initialization steps. These receive the instance of the interface being iterated, as well as the newly-created iterator object.

Interfaces with an asynchronously iterable declaration must not have any interface members named "`entries`", "`keys`", or "`values`", or have any inherited interfaces that have interface members with these names.

Consider the following interface `SessionManager`, which allows access to a number of `Session` objects keyed by username:

    [Exposed=Window]
    interface SessionManager {
      Session getSessionForUser(DOMString username);

      async iterable<DOMString, Session>;
    };

    [Exposed=Window]
    interface Session {
      readonly attribute DOMString username;
      // ...
    };

The behavior of the iterator could be defined like so:

> The asynchronous iterator initialization steps for a `SessionManager` async iterator iterator are:

> 1. Set iterator’s current state to "not yet started".

> To get the next iteration result for a `SessionManager` manager and its async iterator iterator:

> 1. Let promise be a new promise.

> 2. Let key be the following value, if it exists, or null otherwise:

>    If iterator’s current state is "not yet started"

>      the smallest username in manager’s open sessions, in lexicographical order

>    Otherwise

>      the smallest username in manager’s open sessions that is greater than iterator’s current state, in lexicographical order

>    Note: iterator’s current state might no longer be present in the open sessions.

> 3. If key is null, then:

>    1. Resolve promise with undefined.

> 4. Otherwise:

>    1. Let session be the `Session` object corresponding to key.

>    2. Resolve promise with (username, session).

>    3. Set iterator’s current state to username.

> 5. Return promise.

In the ECMAScript language binding, the interface prototype object for the `SessionManager` interface has a `values` method that is a function, which, when invoked, returns an asynchronous iterator object that itself has a `next` method that returns the next value to be iterated over. It has `keys` and `entries` methods that iterate over the usernames of session objects and (username, `Session`) object pairs, respectively. It also has a `@@asyncIterator` method that allows a `SessionManager` to be used in a `for await..of` loop that has the same value as the `entries` method:

    // Get an instance of SessionManager.
    // Assume that it has sessions for two users, "anna" and "brian".
    var sm = getSessionManager();

    typeof SessionManager.prototype.values;            // Evaluates to "function"
    var it = sm.values();                              // values() returns an iterator object
    typeof it.next;                                    // Evaluates to "function"

    // This loop will log "anna" and then "brian".
    for await (let username of sm.keys()) {
      console.log(username);
    }

    // Yet another way of accomplishing the same.
    for await (let [username, session] of sm) {
      console.log(username);
    }

An interface must not have more than one asynchronously iterable declaration. The inherited interfaces of an interface with an asynchronously iterable declaration must not also have an asynchronously iterable declaration. An interface with an asynchronously iterable declaration and its inherited interfaces must not have a maplike declaration, setlike declaration, or iterable declaration.

The following extended attributes are applicable to asynchronously iterable declarations: [`Exposed`], [`SecureContext`].

these extended attributes are not currently taken into account. When they are, the effect will be as you would expect.

    AsyncIterable :
        "async" "iterable" "<" TypeWithExtendedAttributes "," TypeWithExtendedAttributes ">" ";"

#### 2.5.10. Maplike declarations

An interface can be declared to be maplike by using a maplike declaration (matching ReadWriteMaplike or readonly MaplikeRest) in the body of the interface.

    interface interface_identifier {
      readonly maplike<key_type, value_type>;
      maplike<key_type, value_type>;
    };

Objects implementing an interface that is declared to be maplike represent an ordered list of key–value pairs known as its map entries. The types used for the keys and values are given in the angle brackets of the maplike declaration. Keys are required to be unique.

The map entries of an object implementing a maplike interface is empty at the of the object’s creation. Prose accompanying the interface can describe how the map entries of an object change.

Maplike interfaces support an API for querying the map entries appropriate for the language binding. If the readonly keyword is not used, then it also supports an API for modifying the map entries.

Note: In the ECMAScript language binding, the API for interacting with the map entries is similar to that available on ECMAScript `Map` objects. If the readonly keyword is used, this includes `entries`, `forEach`, `get`, `has`, `keys`, `values`, `@@iterator` methods, and a `size` getter. For read–write maplikes, it also includes `clear`, `delete`, and `set` methods.

Maplike interfaces must not have any interface members named "`entries`", "`forEach`", "`get`", "`has`", "`keys`", "`size`", or "`values`", or have any inherited interfaces that have members with these names. Read–write maplike interfaces must not have any attributes or constants named "`clear`", "`delete`", or "`set`", or have any inherited interfaces that have attributes or constants with these names.

Note: Operations named "`clear`", "`delete`", or "`set`" are allowed on read–write maplike interfaces and will prevent the default implementation of these methods being added to the interface prototype object in the ECMAScript language binding. This allows the default behavior of these operations to be overridden.

An interface must not have more than one maplike declaration. The inherited interfaces of a maplike interface must not also have a maplike declaration. A maplike interface and its inherited interfaces must not have an iterable declaration, an asynchronously iterable declaration, a setlike declaration, or an indexed property getter.

    ReadWriteMaplike :
        MaplikeRest

    MaplikeRest :
        "maplike" "<" TypeWithExtendedAttributes "," TypeWithExtendedAttributes ">" ";"

No extended attributes defined in this specification are applicable to maplike declarations.

Add example.

#### 2.5.11. Setlike declarations

An interface can be declared to be setlike by using a setlike declaration (matching ReadWriteSetlike or readonly SetlikeRest) in the body of the interface.

    interface interface_identifier {
      readonly setlike<type>;
      setlike<type>;
    };

Objects implementing an interface that is declared to be setlike represent an ordered list of values known as its set entries. The type of the values is given in the angle brackets of the setlike declaration. Values are required to be unique.

The set entries of an object implementing a setlike interface is empty at the of the object’s creation. Prose accompanying the interface can describe how the set entries of an object change.

Setlike interfaces support an API for querying the set entries appropriate for the language binding. If the readonly keyword is not used, then it also supports an API for modifying the set entries.

Note: In the ECMAScript language binding, the API for interacting with the set entries is similar to that available on ECMAScript `Set` objects. If the readonly keyword is used, this includes `entries`, `forEach`, `has`, `keys`, `values`, `@@iterator` methods, and a `size` getter. For read–write setlikes, it also includes `add`, `clear`, and `delete` methods.

Setlike interfaces must not have any interface members named "`entries`", "`forEach`", "`has`", "`keys`", "`size`", or "`values`", or have any inherited interfaces that have members with these names. Read–write setlike interfaces must not have any attributes or constants named "`add`", "`clear`", or "`delete`", or have any inherited interfaces that have attributes or constants with these names.

Note: Operations named "`add`", "`clear`", or "`delete`" are allowed on read–write setlike interfaces and will prevent the default implementation of these methods being added to the interface prototype object in the ECMAScript language binding. This allows the default behavior of these operations to be overridden.

An interface must not have more than one setlike declaration. The inherited interfaces of a setlike interface must not also have a setlike declaration. A setlike interface and its inherited interfaces must not have an iterable declaration, an asynchronously iterable declaration, a maplike declaration, or an indexed property getter.

    ReadWriteSetlike :
        SetlikeRest

    SetlikeRest :
        "setlike" "<" TypeWithExtendedAttributes ">" ";"

No extended attributes defined in this specification are applicable to setlike declarations.

Add example.

### 2.6. Namespaces

A namespace is a definition (matching Namespace) that declares a global singleton with associated behaviors.

    namespace identifier {
      /* namespace_members... */
    };

A namespace is a specification of a set of namespace members (matching NamespaceMembers), which are the regular operations and read only regular attributes that appear between the braces in the namespace declaration. These operations and attributes describe the behaviors packaged into the namespace.

As with interfaces, the IDL for namespaces can be split into multiple parts by using partial namespace definitions (matching partial Namespace). The identifier of a partial namespace definition must be the same as the identifier of a namespace definition. All of the members that appear on each of the partial namespace definitions are considered to be members of the namespace itself.

    namespace SomeNamespace {
      /* namespace_members... */
    };

    partial namespace SomeNamespace {
      /* namespace_members... */
    };

Note: As with partial interface definitions, partial namespace definitions are intended for use as a specification editorial aide, allowing the definition of a namespace to be separated over more than one section of the document, and sometimes multiple documents.

The order that members appear in has significance for property enumeration in the ECMAScript binding.

Note that unlike interfaces or dictionaries, namespaces do not create types.

Of the extended attributes defined in this specification, only the [`Exposed`] and [`SecureContext`] extended attributes are applicable to namespaces.

Namespaces must be annotated with the [`Exposed`] extended attribute.

    Namespace :
        "namespace" identifier "{" NamespaceMembers "}" ";"

    NamespaceMembers :
        ExtendedAttributeList NamespaceMember NamespaceMembers
        ε

    NamespaceMember :
        RegularOperation
        "readonly" AttributeRest

The following IDL fragment defines a namespace.

    namespace VectorUtils {
      readonly attribute Vector unit;
      double dotProduct(Vector x, Vector y);
      Vector crossProduct(Vector x, Vector y);
    };

An ECMAScript implementation would then expose a global `VectorUtils` data property which was a simple object (with prototype `%ObjectPrototype%`) with enumerable data properties for each declared operation, and enumerable get-only accessors for each declared attribute:

    Object.getPrototypeOf(VectorUtils);                         // Evaluates to Object.prototype.
    Object.keys(VectorUtils);                                   // Evaluates to ["dotProduct", "crossProduct"].
    Object.getOwnPropertyDescriptor(VectorUtils, "dotProduct"); // Evaluates to { value: <a function>, enumerable: true, configurable: true, writable: true }.
    Object.getOwnPropertyDescriptor(VectorUtils, "unit");       // Evaluates to { get: <a function>, enumerable: true, configurable: true }.

### 2.7. Dictionaries

A dictionary is a definition (matching Dictionary) used to define an ordered map data type with a fixed, ordered set of entries, termed dictionary members, where keys are strings and values are of a particular type specified in the definition.

    dictionary identifier {
      /* dictionary_members... */
    };

Dictionaries are always passed by value. In language bindings where a dictionary is represented by an object of some kind, passing a dictionary to a platform object will not result in a reference to the dictionary being kept by that object. Similarly, any dictionary returned from a platform object will be a copy and modifications made to it will not be visible to the platform object.

A dictionary can be defined to inherit from another dictionary. If the identifier of the dictionary is followed by a colon and a identifier, then that identifier identifies the inherited dictionary. The identifier must identify a dictionary.

A dictionary must not be declared such that its inheritance hierarchy has a cycle. That is, a dictionary A cannot inherit from itself, nor can it inherit from another dictionary B that inherits from A, and so on.

    dictionary Base {
      /* dictionary_members... */
    };

    dictionary Derived : Base {
      /* dictionary_members... */
    };

The inherited dictionaries of a given dictionary D is the set of all dictionaries that D inherits from, directly or indirectly. If D does not inherit from another dictionary, then the set is empty. Otherwise, the set includes the dictionary E that D inherits from and all of E’s inherited dictionaries.

A dictionary value of type D can have key–value pairs corresponding to the dictionary members defined on D and on any of D’s inherited dictionaries. On a given dictionary value, the presence of each dictionary member is optional, unless that member is specified as required. A dictionary member is said to be present in a dictionary value if the value contains an entry with the key given by the member’s identifier, otherwise it is not present. Dictionary members can also optionally have a default value, which is the value to use for the dictionary member when passing a value to a platform object that does not have a specified value. Dictionary members with default values are always considered to be present.

In the ECMAScript binding, a value of undefined is treated as not present, or will trigger the default value where applicable.

An ordered map with string keys can be implicitly treated as a dictionary value of a specific dictionary D if all of its entries correspond to dictionary members, in the correct order and with the correct types, and with appropriate entries for any required dictionary members.

    dictionary Descriptor {
      DOMString name;
      sequence<unsigned long> serviceIdentifiers;
    };

A `Descriptor` dictionary could be created as in the following steps:

1. Let identifiers be « 1, 3, 7 ».

2. Return «[ "name" → "test", "serviceIdentifiers" → identifiers ]».

As with operation argument default values, it is strongly suggested not to use true as the default value for `boolean`-typed dictionary members, as this can be confusing for authors who might otherwise expect the default conversion of undefined to be used (i.e., false).

Each dictionary member (matching DictionaryMember) is specified as a type (matching Type) followed by an identifier (given by an identifier token following the type). The identifier is the key name of the key–value pair. If the Type is an identifier followed by ?, then the identifier must identify an interface, enumeration, callback function, callback interface or typedef. If the dictionary member type is an identifier not followed by ?, then the identifier must identify any one of those definitions or a dictionary.

If the type of the dictionary member, after resolving typedefs, is a nullable type, its inner type must not be a dictionary type.

    dictionary identifier {
      type identifier;
    };

If the identifier is followed by a U+003D EQUALS SIGN ("=") and a value (matching DefaultValue), then that gives the dictionary member its default value.

    dictionary identifier {
      type identifier = "value";
    };

When a boolean literal token (true or false), the null token, an integer token, a decimal token, one of the three special floating point literal values (Infinity, -Infinity or NaN), a string token, the two token sequence [], or the two token sequence {} is used as the default value, it is interpreted in the same way as for an operation’s optional argument default value.

If the type of the dictionary member is an enumeration, then its default value if specified must be one of the enumeration’s values.

If the type of the dictionary member is preceded by the required keyword, the member is considered a required dictionary member and must be present on the dictionary.

    dictionary identifier {
      required type identifier;
    };

The type of a dictionary member must not include the dictionary it appears on. A type includes a dictionary D if at least one of the following is true:

- the type is D

- the type is a dictionary that inherits from D

- the type is a nullable type whose inner type includes D

- the type is a sequence type or frozen array whose element type includes D

- the type is a union type, one of whose member types includes D

- the type is a dictionary, one of whose members or inherited members has a type that includes D

- the type is `record<K, V>` where V includes D

As with interfaces, the IDL for dictionaries can be split into multiple parts by using partial dictionary definitions (matching partial Dictionary). The identifier of a partial dictionary definition must be the same as the identifier of a dictionary definition. All of the members that appear on each of the partial dictionary definitions are considered to be members of the dictionary itself.

    dictionary SomeDictionary {
      /* dictionary_members... */
    };

    partial dictionary SomeDictionary {
      /* dictionary_members... */
    };

Note: As with partial interface definitions, partial dictionary definitions are intended for use as a specification editorial aide, allowing the definition of an interface to be separated over more than one section of the document, and sometimes multiple documents.

The order of the dictionary members on a given dictionary is such that inherited dictionary members are ordered before non-inherited members, and the dictionary members on the one dictionary definition (including any partial dictionary definitions) are ordered lexicographically by the Unicode codepoints that comprise their identifiers.

For example, with the following definitions:

    dictionary B : A {
      long b;
      long a;
    };

    dictionary A {
      long c;
      long g;
    };

    dictionary C : B {
      long e;
      long f;
    };

    partial dictionary A {
      long h;
      long d;
    };

the order of the dictionary members of a dictionary value of type `C` is c, d, g, h, a, b, e, f.

Dictionaries are required to have their members ordered because in some language bindings the behavior observed when passing a dictionary value to a platform object depends on the order the dictionary members are fetched. For example, consider the following additional interface:

    [Exposed=Window]
    interface Something {
      void f(A a);
    };

and this ECMAScript code:

    var something = getSomething();  // Get an instance of Something.
    var x = 0;

    var dict = { };
    Object.defineProperty(dict, "d", { get: function() { return ++x; } });
    Object.defineProperty(dict, "c", { get: function() { return ++x; } });

    something.f(dict);

The order that the dictionary members are fetched in determines what values they will be taken to have. Since the order for `A` is defined to be c then d, the value for c will be 1 and the value for d will be 2.

The identifier of a dictionary member must not be the same as that of another dictionary member defined on the dictionary or on that dictionary’s inherited dictionaries.

Dictionaries must not be used as the type of an attribute or constant.

No extended attributes are applicable to dictionaries.

    Dictionary :
        "dictionary" identifier Inheritance "{" DictionaryMembers "}" ";"

    DictionaryMembers :
        DictionaryMember DictionaryMembers
        ε

    DictionaryMember :
        ExtendedAttributeList DictionaryMemberRest

    DictionaryMemberRest :
        "required" TypeWithExtendedAttributes identifier ";"
        Type identifier Default ";"

    PartialDictionary :
        "dictionary" identifier "{" DictionaryMembers "}" ";"

    Default :
        "=" DefaultValue
        ε

One use of dictionary types is to allow a number of optional arguments to an operation without being constrained as to the order they are specified at the call site. For example, consider the following IDL fragment:

    [Exposed=Window]
    interface Point {
      constructor();
      attribute double x;
      attribute double y;
    };

    dictionary PaintOptions {
      DOMString? fillPattern = "black";
      DOMString? strokePattern = null;
      Point position;
    };

    [Exposed=Window]
    interface GraphicsContext {
      void drawRectangle(double width, double height, optional PaintOptions options);
    };

In an ECMAScript implementation of the IDL, an Object can be passed in for the optional `PaintOptions` dictionary:

    // Get an instance of GraphicsContext.
    var ctx = getGraphicsContext();

    // Draw a rectangle.
    ctx.drawRectangle(300, 200, { fillPattern: "red", position: new Point(10, 10) });

Both fillPattern and strokePattern are given default values, so if they are omitted, the definition of drawRectangle can assume that they have the given default values and not include explicit wording to handle their non-presence.

### 2.8. Exceptions

An exception is a type of object that represents an error and which can be thrown or treated as a first class value by implementations. Web IDL does not allow exceptions to be defined, but instead has a number of pre-defined exceptions that specifications can reference and throw in their definition of operations, attributes, and so on. Exceptions have an error name, a `DOMString`, which is the type of error the exception represents, and a message, which is an optional, user agent-defined value that provides human readable details of the error.

There are two kinds of exceptions available to be thrown from specifications. The first is a simple exception, which is identified by one of the following types:

- `EvalError`

- `RangeError`

- `ReferenceError`

- `TypeError`

- `URIError`

These correspond to all of the ECMAScript error objects (apart from `SyntaxError` and `Error`, which are deliberately omitted as they are reserved for use by the ECMAScript parser and by authors, respectively). The meaning of each simple exception matches its corresponding error object in the ECMAScript specification.

The second kind of exception is a `DOMException`, which is an exception that encapsulates a name and an optional integer code, for compatibility with historically defined exceptions in the DOM.

For simple exceptions, the error name is the type of the exception. For a `DOMException`, the error name must be one of the names listed in the error names table below. The table also indicates the `DOMException`'s integer code for that error name, if it has one.

Note: As `DOMException` is an interface type, it can be used as a type in IDL. This allows for example an operation to be declared to have a `DOMException` return type.

Simple exceptions can be created by providing their error name. A `DOMException` can be created by providing its error name followed by `DOMException`. Exceptions can also be thrown, by providing the same details required to create one.

The resulting behavior from creating and throwing an exception is language binding-specific.

Note: See § 3.12.3 Creating and throwing exceptions for details on what creating and throwing an exception entails in the ECMAScript language binding.

Here is are some examples of wording to use to create and throw exceptions. To throw a new simple exception named `TypeError`:

> Throw a `TypeError`.

To throw a new `DOMException` with error name "`NotAllowedError`":

> Throw an "`NotAllowedError`" `DOMException`.

To create a new `DOMException` with error name "`SyntaxError`":

> Let object be a newly created "`SyntaxError`" `DOMException`.

#### 2.8.1. Error names

The error names table below lists all the allowed error names for `DOMException`, a description, and legacy code values.

The `DOMException` names marked as deprecated are kept for legacy purposes but their usage is discouraged.

Note: If an error name is not listed here, please file a bug as indicated at the top of this specification and it will be addressed shortly. Thanks!

Note: Don’t confuse the "`SyntaxError`" `DOMException` defined here with ECMAScript’s `SyntaxError`. "`SyntaxError`" `DOMException` is used to report parsing errors in web APIs, for example when parsing selectors, while the ECMAScript `SyntaxError` is reserved for the ECMAScript parser. To help disambiguate this further, always favor the "`SyntaxError`" `DOMException` notation over just using `SyntaxError` to refer to the `DOMException`. [DOM]

Name | Description | Legacy code name and value
--- | --- | ---
"`IndexSizeError`" | Deprecated. Use `RangeError` instead. | `INDEX_SIZE_ERR` (1)
"`DOMStringSizeError`" | Deprecated. Use `RangeError` instead. | `DOMSTRING_SIZE_ERR` (2)
"`HierarchyRequestError`" | The operation would yield an incorrect node tree. [DOM] | `HIERARCHY_REQUEST_ERR` (3)
"`WrongDocumentError`" | The object is in the wrong document. [DOM] | `WRONG_DOCUMENT_ERR` (4)
"`InvalidCharacterError`" | The string contains invalid characters. | `INVALID_CHARACTER_ERR` (5)
"`NoDataAllowedError`" | Deprecated. | `NO_DATA_ALLOWED_ERR` (6)
"`NoModificationAllowedError`" | The object can not be modified. | `NO_MODIFICATION_ALLOWED_ERR` (7)
"`NotFoundError`" | The object can not be found here. | `NOT_FOUND_ERR` (8)
"`NotSupportedError`" | The operation is not supported. | `NOT_SUPPORTED_ERR` (9)
"`InUseAttributeError`" | The attribute is in use. | `INUSE_ATTRIBUTE_ERR` (10)
"`InvalidStateError`" | The object is in an invalid state. | `INVALID_STATE_ERR` (11)
"`SyntaxError`" | The string did not match the expected pattern. | `SYNTAX_ERR` (12)
"`InvalidModificationError`" | The object can not be modified in this way. | `INVALID_MODIFICATION_ERR` (13)
"`NamespaceError`" | The operation is not allowed by Namespaces in XML. [XML-NAMES] | `NAMESPACE_ERR` (14)
"`InvalidAccessError`" | Deprecated. Use `TypeError` for invalid arguments, "`NotSupportedError`" `DOMException` for unsupported operations, and "`NotAllowedError`" `DOMException` for denied requests instead. | `INVALID_ACCESS_ERR` (15)
"`ValidationError`" | Deprecated. | `VALIDATION_ERR` (16)
"`TypeMismatchError`" | Deprecated. Use `TypeError` instead. | `TYPE_MISMATCH_ERR` (17)
"`SecurityError`" | The operation is insecure. | `SECURITY_ERR` (18)
"`NetworkError`" | A network error occurred. | `NETWORK_ERR` (19)
"`AbortError`" | The operation was aborted. | `ABORT_ERR` (20)
"`URLMismatchError`" | The given URL does not match another URL. | `URL_MISMATCH_ERR` (21)
"`QuotaExceededError`" | The quota has been exceeded. | `QUOTA_EXCEEDED_ERR` (22)
"`TimeoutError`" | The operation timed out. | `TIMEOUT_ERR` (23)
"`InvalidNodeTypeError`" | The supplied node is incorrect or has an incorrect ancestor for this operation. | `INVALID_NODE_TYPE_ERR` (24)
"`DataCloneError`" | The object can not be cloned. | `DATA_CLONE_ERR` (25)
"`EncodingError`" | The encoding operation (either encoded or decoding) failed. | —
"`NotReadableError`" | The I/O read operation failed. | —
"`UnknownError`" | The operation failed for an unknown transient reason (e.g. out of memory). | —
"`ConstraintError`" | A mutation operation in a transaction failed because a constraint was not satisfied. | —
"`DataError`" | Provided data is inadequate. | —
"`TransactionInactiveError`" | A request was placed against a transaction which is currently not active, or which is finished. | —
"`ReadOnlyError`" | The mutating operation was attempted in a "readonly" transaction. | —
"`VersionError`" | An attempt was made to open a database using a lower version than the existing version. | —
"`OperationError`" | The operation failed for an operation-specific reason. | —
"`NotAllowedError`" | The request is not allowed by the user agent or the platform in the current context, possibly because the user denied permission. | —

### 2.9. Enumerations

An enumeration is a definition (matching Enum) used to declare a type whose valid values are a set of predefined strings. Enumerations can be used to restrict the possible `DOMString` values that can be assigned to an attribute or passed to an operation.

    enum identifier { "enum", "values" /* , ... */ };

The enumeration values are specified as a comma-separated list of string literals. The list of enumeration values must not include duplicates.

It is strongly suggested that enumeration values be all lowercase, and that multiple words be separated using dashes or not be separated at all, unless there is a specific reason to use another value naming scheme. For example, an enumeration value that indicates an object should be created could be named "`createobject`" or "`create-object`". Consider related uses of enumeration values when deciding whether to dash-separate or not separate enumeration value words so that similar APIs are consistent.

The behavior when a string value that is not one a valid enumeration value is used when assigning to an attribute, or passed as an operation argument, whose type is the enumeration, is language binding specific.

Note: In the ECMAScript binding, assignment of an invalid string value to an attribute is ignored, while passing such a value in other contexts (for example as an operation argument) results in an exception being thrown.

No extended attributes defined in this specification are applicable to enumerations.

    Enum :
        "enum" identifier "{" EnumValueList "}" ";"

    EnumValueList :
        string EnumValueListComma

    EnumValueListComma :
        "," EnumValueListString
        ε

    EnumValueListString :
        string EnumValueListComma
        ε

The following IDL fragment defines an enumeration that is used as the type of an attribute and an operation argument:

    enum MealType { "rice", "noodles", "other" };

    [Exposed=Window]
    interface Meal {
      attribute MealType type;
      attribute double size;     // in grams

      void initialize(MealType type, double size);
    };

An ECMAScript implementation would restrict the strings that can be assigned to the type property or passed to the initializeMeal function to those identified in the enumeration.

    var meal = getMeal();                // Get an instance of Meal.

    meal.initialize("rice", 200);        // Operation invoked as normal.

    try {
      meal.initialize("sandwich", 100);  // Throws a TypeError.
    } catch (e) {
    }

    meal.type = "noodles";               // Attribute assigned as normal.
    meal.type = "dumplings";             // Attribute assignment ignored.
    meal.type == "noodles";              // Evaluates to true.

### 2.10. Callback functions

The “Custom DOM Elements” spec wants to use callback function types for platform object provided functions. Should we rename “callback functions” to just “functions” to make it clear that they can be used for both purposes?

A callback function is a definition (matching callback CallbackRest) used to declare a function type.

    callback identifier = return_type (/* arguments... */);

Note: See also the similarly named callback interfaces.

The identifier on the left of the equals sign gives the name of the callback function and the return type and argument list (matching ReturnType and ArgumentList) on the right side of the equals sign gives the signature of the callback function type.

Callback functions must not be used as the type of a constant.

The following extended attribute is applicable to callback functions: [`TreatNonObjectAsNull`].

    CallbackRest :
        identifier "=" ReturnType "(" ArgumentList ")" ";"

The following IDL fragment defines a callback function used for an API that invokes a user-defined function when an operation is complete.

    callback AsyncOperationCallback = void (DOMString status);

    [Exposed=Window]
    interface AsyncOperations {
      void performOperation(AsyncOperationCallback whenFinished);
    };

In the ECMAScript language binding, a function object is passed as the operation argument.

    var ops = getAsyncOperations();  // Get an instance of AsyncOperations.

    ops.performOperation(function(status) {
      window.alert("Operation finished, status is " + status + ".");
    });

### 2.11. Typedefs

A typedef is a definition (matching Typedef) used to declare a new name for a type. This new name is not exposed by language bindings; it is purely used as a shorthand for referencing the type in the IDL.

    typedef type identifier;

The type being given a new name is specified after the typedef keyword (matching TypeWithExtendedAttributes), and the identifier token following the type gives the name.

The Type must not be the identifier of the same or another typedef.

No extended attributes defined in this specification are applicable to typedefs.

    Typedef :
        "typedef" TypeWithExtendedAttributes identifier ";"

The following IDL fragment demonstrates the use of typedefs to allow the use of a short identifier instead of a long sequence type.

    [Exposed=Window]
    interface Point {
      attribute double x;
      attribute double y;
    };

    typedef sequence<Point> Points;

    [Exposed=Window]
    interface Widget {
      boolean pointWithinBounds(Point p);
      boolean allPointsWithinBounds(Points ps);
    };

### 2.12. Objects implementing interfaces

In a given implementation of a set of IDL fragments, an object can be described as being a platform object.

Platform objects are objects that implement an interface.

Legacy platform objects are platform objects that implement an interface which does not have a [`Global`] extended attribute, and which supports indexed properties, named properties, or both.

In a browser, for example, the browser-implemented DOM objects (implementing interfaces such as `Node` and `Document`) that provide access to a web page’s contents to ECMAScript running in the page would be platform objects. These objects might be exotic objects, implemented in a language like C++, or they might be native ECMAScript objects. Regardless, an implementation of a given set of IDL fragments needs to be able to recognize all platform objects that are created by the implementation. This might be done by having some internal state that records whether a given object is indeed a platform object for that implementation, or perhaps by observing that the object is implemented by a given internal C++ class. How exactly platform objects are recognized by a given implementation of a set of IDL fragments is implementation specific.

All other objects in the system would not be treated as platform objects. For example, assume that a web page opened in a browser loads an ECMAScript library that implements DOM Core. This library would be considered to be a different implementation from the browser provided implementation. The objects created by the ECMAScript library that implement the `Node` interface will not be treated as platform objects that implement `Node` by the browser implementation.

Callback interfaces, on the other hand, can be implemented by any ECMAScript object. This allows Web APIs to invoke author-defined operations. For example, the DOM Events implementation allows authors to register callbacks by providing objects that implement the `EventListener` interface.

### 2.13. Types

This section lists the types supported by Web IDL, the set of values corresponding to each type, and how constants of that type are represented.

The following types are known as integer types: `byte`, `octet`, `short`, `unsigned short`, `long`, `unsigned long`, `long long` and `unsigned long long`.

The following types are known as numeric types: the integer types, `float`, `unrestricted float`, `double` and `unrestricted double`.

The primitive types are `boolean` and the numeric types.

The string types are `DOMString`, all enumeration types, `ByteString` and `USVString`.

The typed array types are `Int8Array`, `Int16Array`, `Int32Array`, `Uint8Array`, `Uint16Array`, `Uint32Array`, `Uint8ClampedArray`, `Float32Array` and `Float64Array`.

The buffer source types are `ArrayBuffer`, `DataView`, and the typed array types.

The `object` type, all interface types, and all callback interface types are known as object types.

Every type has a type name, which is a string, not necessarily unique, that identifies the type. Each sub-section below defines what the type name is for each type.

When conversions are made from language binding specific types to IDL types in order to invoke an operation or assign a value to an attribute, all conversions necessary will be performed before the specified functionality of the operation or attribute assignment is carried out. If the conversion cannot be performed, then the operation will not run or the attribute will not be updated. In some language bindings, type conversions could result in an exception being thrown. In such cases, these exceptions will be propagated to the code that made the attempt to invoke the operation or assign to the attribute.

    Type :
        SingleType
        UnionType Null

    TypeWithExtendedAttributes :
        ExtendedAttributeList Type

    SingleType :
        DistinguishableType
        "any"
        PromiseType

    UnionType :
        "(" UnionMemberType "or" UnionMemberType UnionMemberTypes ")"

    UnionMemberType :
        ExtendedAttributeList DistinguishableType
        UnionType Null

    UnionMemberTypes :
        "or" UnionMemberType UnionMemberTypes
        ε

    DistinguishableType :
        PrimitiveType Null
        StringType Null
        identifier Null
        "sequence" "<" TypeWithExtendedAttributes ">" Null
        "object" Null
        "symbol" Null
        BufferRelatedType Null
        "FrozenArray" "<" TypeWithExtendedAttributes ">" Null
        RecordType Null

    PrimitiveType :
        UnsignedIntegerType
        UnrestrictedFloatType
        "boolean"
        "byte"
        "octet"

    UnrestrictedFloatType :
        "unrestricted" FloatType
        FloatType

    FloatType :
        "float"
        "double"

    UnsignedIntegerType :
        "unsigned" IntegerType
        IntegerType

    IntegerType :
        "short"
        "long" OptionalLong

    OptionalLong :
        "long"
        ε

    StringType :
        "ByteString"
        "DOMString"
        "USVString"

    PromiseType :
        "Promise" "<" ReturnType ">"

    RecordType :
        "record" "<" StringType "," TypeWithExtendedAttributes ">"

    Null :
        "?"
        ε

#### 2.13.1. any

The `any` type is the union of all other possible non-union types. Its type name is "`Any`".

The `any` type is like a discriminated union type, in that each of its values has a specific non-`any` type associated with it. For example, one value of the `any` type is the `unsigned long` 150, while another is the `long` 150. These are distinct values.

The particular type of an `any` value is known as its specific type. (Values of union types also have specific types.)

#### 2.13.2. void

The `void` type has a unique value.

It can only be used as the return type of an operation or the parameter of a promise type.

The type name of the `void` type is "`Void`".

#### 2.13.3. boolean

The `boolean` type has two values: `true` and `false`.

`boolean` constant values in IDL are represented with the true and false tokens.

The type name of the `boolean` type is "`Boolean`".

#### 2.13.4. byte

The `byte` type is a signed integer type that has values in the range [−128, 127].

`byte` constant values in IDL are represented with integer tokens.

The type name of the `byte` type is "`Byte`".

#### 2.13.5. octet

The `octet` type is an unsigned integer type that has values in the range [0, 255].

`octet` constant values in IDL are represented with integer tokens.

The type name of the `octet` type is "`Octet`".

#### 2.13.6. short

The `short` type is a signed integer type that has values in the range [−32768, 32767].

`short` constant values in IDL are represented with integer tokens.

The type name of the `short` type is "`Short`".

#### 2.13.7. unsigned short

The `unsigned short` type is an unsigned integer type that has values in the range [0, 65535].

`unsigned short` constant values in IDL are represented with integer tokens.

The type name of the `unsigned short` type is "`UnsignedShort`".

#### 2.13.8. long

The `long` type is a signed integer type that has values in the range [−2147483648, 2147483647].

`long` constant values in IDL are represented with integer tokens.

The type name of the `long` type is "`Long`".

#### 2.13.9. unsigned long

The `unsigned long` type is an unsigned integer type that has values in the range [0, 4294967295].

`unsigned long` constant values in IDL are represented with integer tokens.

The type name of the `unsigned long` type is "`UnsignedLong`".

#### 2.13.10. long long

The `long long` type is a signed integer type that has values in the range [−9223372036854775808, 9223372036854775807].

`long long` constant values in IDL are represented with integer tokens.

The type name of the `long long` type is "`LongLong`".

#### 2.13.11. unsigned long long

The `unsigned long long` type is an unsigned integer type that has values in the range [0, 18446744073709551615].

`unsigned long long` constant values in IDL are represented with integer tokens.

The type name of the `unsigned long long` type is "`UnsignedLongLong`".

#### 2.13.12. float

The `float` type is a floating point numeric type that corresponds to the set of finite single-precision 32 bit IEEE 754 floating point numbers. [IEEE-754]

`float` constant values in IDL are represented with decimal tokens.

The type name of the `float` type is "`Float`".

Unless there are specific reasons to use a 32 bit floating point type, specifications should use `double` rather than `float`, since the set of values that a `double` can represent more closely matches an ECMAScript Number.

#### 2.13.13. unrestricted float

The `unrestricted float` type is a floating point numeric type that corresponds to the set of all possible single-precision 32 bit IEEE 754 floating point numbers, finite, non-finite, and special "not a number" values (NaNs). [IEEE-754]

`unrestricted float` constant values in IDL are represented with decimal tokens.

The type name of the `unrestricted float` type is "`UnrestrictedFloat`".

#### 2.13.14. double

The `double` type is a floating point numeric type that corresponds to the set of finite double-precision 64 bit IEEE 754 floating point numbers. [IEEE-754]

`double` constant values in IDL are represented with decimal tokens.

The type name of the `double` type is "`Double`".

#### 2.13.15. unrestricted double

The `unrestricted double` type is a floating point numeric type that corresponds to the set of all possible double-precision 64 bit IEEE 754 floating point numbers, finite, non-finite, and special "not a number" values (NaNs). [IEEE-754]

`unrestricted double` constant values in IDL are represented with decimal tokens.

The type name of the `unrestricted double` type is "`UnrestrictedDouble`".

#### 2.13.16. DOMString

The `DOMString` type corresponds to the set of all possible sequences of code units. Such sequences are commonly interpreted as UTF-16 encoded strings [RFC2781] although this is not required. While `DOMString` is defined to be an OMG IDL boxed sequence<`unsigned short`> valuetype in DOM Level 3 Core §The DOMString Type, this document defines `DOMString` to be an intrinsic type so as to avoid special casing that sequence type in various situations where a string is required.

Note: Note also that null is not a value of type `DOMString`. To allow null, a nullable `DOMString`, written as `DOMString?` in IDL, needs to be used.

Nothing in this specification requires a `DOMString` value to be a valid UTF-16 string. For example, a `DOMString` value might include unmatched surrogate pair characters. However, authors of specifications using Web IDL might want to obtain a sequence of Unicode scalar values given a particular sequence of code units.

The following algorithm defines a way to convert a DOMString to a sequence of Unicode scalar values:

1. Let S be the `DOMString` value.

2. Let n be the length of S.

3. Initialize i to 0.

4. Initialize U to be an empty sequence of Unicode characters.

5. While i < n:

   1. Let c be the code unit in S at index i.

   2. Depending on the value of c:

      c < 0xD800 or c > 0xDFFF

        Append to U the Unicode character with code point c.

      0xDC00 ≤ c ≤ 0xDFFF

        Append to U a U+FFFD REPLACEMENT CHARACTER.

      0xD800 ≤ c ≤ 0xDBFF

        1. If i = n−1, then append to U a U+FFFD REPLACEMENT CHARACTER.

        2. Otherwise, i < n−1:

           1. Let d be the code unit in S at index i+1.

           2. If 0xDC00 ≤ d ≤ 0xDFFF, then:

              1. Let a be c & 0x3FF.

              2. Let b be d & 0x3FF.

              3. Append to U the Unicode character with code point 216+210a+b.

              4. Set i to i+1.

           3. Otherwise, d < 0xDC00 or d > 0xDFFF. Append to U a U+FFFD REPLACEMENT CHARACTER.

   3. Set i to i+1.

6. Return U.

There is no way to represent a constant `DOMString` value in IDL, although `DOMString` dictionary member default values and operation optional argument default values can be set to the value of a string literal.

The type name of the `DOMString` type is "`String`".

#### 2.13.17. ByteString

The `ByteString` type corresponds to the set of all possible sequences of bytes. Such sequences might be interpreted as UTF-8 encoded strings [RFC3629] or strings in some other 8-bit-per-code-unit encoding, although this is not required.

There is no way to represent a constant `ByteString` value in IDL, although `ByteString` dictionary member default values and operation optional argument default values can be set to the value of a string literal.

The type name of the `ByteString` type is "`ByteString`".

Specifications should only use `ByteString` for interfacing with protocols that use bytes and strings interchangeably, such as HTTP. In general, strings should be represented with `DOMString` values, even if it is expected that values of the string will always be in ASCII or some 8 bit character encoding. Sequences or frozen arrays with `octet` or `byte` elements, `Uint8Array`, or `Int8Array` should be used for holding 8 bit data rather than `ByteString`.

#### 2.13.18. USVString

The `USVString` type corresponds to the set of all possible sequences of Unicode scalar values, which are all of the Unicode code points apart from the surrogate code points.

There is no way to represent a constant `USVString` value in IDL, although `USVString` dictionary member default values and operation optional argument default values can be set to the value of a string literal.

The type name of the `USVString` type is "`USVString`".

Specifications should only use `USVString` for APIs that perform text processing and need a string of Unicode scalar values to operate on. Most APIs that use strings should instead be using `DOMString`, which does not make any interpretations of the code units in the string. When in doubt, use `DOMString`.

#### 2.13.19. object

The `object` type corresponds to the set of all possible non-null object references.

There is no way to represent a constant `object` value in IDL.

To denote a type that includes all possible object references plus the null value, use the nullable type `object?`.

The type name of the `object` type is "`Object`".

#### 2.13.20. symbol

The `symbol` type corresponds to the set of all possible symbol values. Symbol values are opaque, non-`object` values which nevertheless have identity (i.e., are only equal to themselves).

There is no way to represent a constant `symbol` value in IDL.

The type name of the `symbol` type is "`Symbol`".

#### 2.13.21. Interface types

An identifier that identifies an interface is used to refer to a type that corresponds to the set of all possible non-null references to objects that implement that interface.

An IDL value of the interface type is represented just by an object reference.

There is no way to represent a constant object reference value for a particular interface type in IDL.

To denote a type that includes all possible references to objects implementing the given interface plus the null value, use a nullable type.

The type name of an interface type is the identifier of the interface.

#### 2.13.22. Callback interface types

An identifier that identifies a callback interface is used to refer to a type that corresponds to the set of all possible non-null references to objects.

An IDL value of the interface type is represented by a tuple of an object reference and a callback context. The callback context is a language binding specific value, and is used to store information about the execution context at the time the language binding specific object reference is converted to an IDL value.

Note: For ECMAScript objects, the callback context is used to hold a reference to the incumbent settings object at the time the Object value is converted to an IDL callback interface type value. See § 3.2.15 Callback interface types.

There is no way to represent a constant object reference value for a particular callback interface type in IDL.

To denote a type that includes all possible references to objects plus the null value, use a nullable type.

The type name of a callback interface type is the identifier of the callback interface.

#### 2.13.23. Dictionary types

An identifier that identifies a dictionary is used to refer to a type that corresponds to the set of all dictionaries that adhere to the dictionary definition.

The literal syntax for ordered maps may also be used to represent dictionaries, when it is implicitly understood from context that the map is being treated as an instance of a specific dictionary type. However, there is no way to represent a constant dictionary value inside IDL fragments.

The type name of a dictionary type is the identifier of the dictionary.

#### 2.13.24. Enumeration types

An identifier that identifies an enumeration is used to refer to a type whose values are the set of strings (sequences of code units, as with `DOMString`) that are the enumeration’s values.

Like `DOMString`, there is no way to represent a constant enumeration value in IDL, although enumeration-typed dictionary member default values and operation optional argument default values can be set to the value of a string literal.

The type name of an enumeration type is the identifier of the enumeration.

#### 2.13.25. Callback function types

An identifier that identifies a callback function is used to refer to a type whose values are references to objects that are functions with the given signature.

An IDL value of the callback function type is represented by a tuple of an object reference and a callback context.

Note: As with callback interface types, the callback context is used to hold a reference to the incumbent settings object at the time an ECMAScript Object value is converted to an IDL callback function type value. See § 3.2.18 Callback function types.

There is no way to represent a constant callback function value in IDL.

The type name of a callback function type is the identifier of the callback function.

#### 2.13.26. Nullable types — T?

A nullable type is an IDL type constructed from an existing type (called the inner type), which just allows the additional value null to be a member of its set of values. Nullable types are represented in IDL by placing a U+003F QUESTION MARK ("?") character after an existing type. The inner type must not be:

- `any`,

- a Promise type,

- another nullable type, or

- a union type that itself includes a nullable type or has a dictionary type as one of its flattened member types.

Note: Although dictionary types can in general be nullable, they cannot when used as the type of an operation argument or a dictionary member.

Nullable type constant values in IDL are represented in the same way that constant values of their inner type would be represented, or with the null token.

The type name of a nullable type is the concatenation of the type name of the inner type T and the string "`OrNull`".

For example, a type that allows the values true, false and null is written as `boolean?`:

    [Exposed=Window]
    interface NetworkFetcher {
      void get(optional boolean? areWeThereYet = false);
    };

The following interface has two attributes: one whose value can be a `DOMString` or the null value, and another whose value can be a reference to a `Node` object or the null value:

    [Exposed=Window]
    interface Node {
      readonly attribute DOMString? namespaceURI;
      readonly attribute Node? parentNode;
      // ...
    };

#### 2.13.27. Sequence types — sequence<T>

The sequence<T> type is a parameterized type whose values are (possibly zero-length) lists of values of type T.

Sequences are always passed by value. In language bindings where a sequence is represented by an object of some kind, passing a sequence to a platform object will not result in a reference to the sequence being kept by that object. Similarly, any sequence returned from a platform object will be a copy and modifications made to it will not be visible to the platform object.

The literal syntax for lists may also be used to represent sequences, when it is implicitly understood from context that the list is being treated as a sequences. However, there is no way to represent a constant sequence value inside IDL fragments.

Sequences must not be used as the type of an attribute or constant.

Note: This restriction exists so that it is clear to specification writers and API users that sequences are copied rather than having references to them passed around. Instead of a writable attribute of a sequence type, it is suggested that a pair of operations to get and set the sequence is used.

The type name of a sequence type is the concatenation of the type name for T and the string "`Sequence`".

Any list can be implicitly treated as a `sequence<T>`, as long as it contains only items that are of type T.

#### 2.13.28. Record types — record<K, V>

A record type is a parameterized type whose values are ordered maps with keys that are instances of K and values that are instances of V. K must be one of `DOMString`, `USVString`, or `ByteString`.

The literal syntax for ordered maps may also be used to represent records, when it is implicitly understood from context that the map is being treated as a record. However, there is no way to represent a constant record value inside IDL fragments.

Records are always passed by value. In language bindings where a record is represented by an object of some kind, passing a record to a platform object will not result in a reference to the record being kept by that object. Similarly, any record returned from a platform object will be a copy and modifications made to it will not be visible to the platform object.

Records must not be used as the type of an attribute or constant.

The type name of a record type is the concatenation of the type name for K, the type name for V and the string "`Record`".

Any ordered map can be implicitly treated as a `record<K, V>`, as long as it contains only entries whose keys are all of of type K and whose values are all of type V.

#### 2.13.29. Promise types — Promise<T>

A promise type is a parameterized type whose values are references to objects that “is used as a place holder for the eventual results of a deferred (and possibly asynchronous) computation result of an asynchronous operation”. See section 25.4 of the ECMAScript specification for details on the semantics of promise objects.

Promise types are non-nullable, but T may be nullable.

There is no way to represent a promise value in IDL.

The type name of a promise type is the concatenation of the type name for T and the string "`Promise`".

#### 2.13.30. Union types

A union type is a type whose set of values is the union of those in two or more other types. Union types (matching UnionType) are written as a series of types separated by the or keyword with a set of surrounding parentheses. The types which comprise the union type are known as the union’s member types.

For example, you might write `(Node or DOMString)` or `(double or sequence<double>)`. When applying a ? suffix to a union type as a whole, it is placed after the closing parenthesis, as in `(Node or DOMString)?`.

Note that the member types of a union type do not descend into nested union types. So for `(double or (sequence<long> or Event) or (Node or DOMString)?)` the member types are `double`, `(sequence<long> or Event)` and `(Node or DOMString)?`.

Like the `any` type, values of union types have a specific type, which is the particular member type that matches the value.

The flattened member types of a union type, possibly annotated, is a set of types determined as follows:

1. Let T be the union type.

2. Initialize S to ∅.

3. For each member type U of T:

   1. If U is an annotated type, then set U to be the inner type of U.

   2. If U is a nullable type, then set U to be the inner type of U.

   3. If U is a union type, then add to S the flattened member types of U.

   4. Otherwise, U is not a union type. Add U to S.

4. Return S.

Note: For example, the flattened member types of the union type `(Node or (sequence<long> or Event) or (XMLHttpRequest or DOMString)? or sequence<(sequence<double> or NodeList)>)` are the six types `Node`, `sequence<long>`, `Event`, `XMLHttpRequest`, `DOMString` and `sequence<(sequence<double> or NodeList)>`.

The number of nullable member types of a union type is an integer determined as follows:

1. Let T be the union type.

2. Initialize n to 0.

3. For each member type U of T:

   1. If U is a nullable type, then:

      1. Set n to n + 1.

      2. Set U to be the inner type of U.

   2. If U is a union type, then:

      1. Let m be the number of nullable member types of U.

      2. Set n to n + m.

4. Return n.

The `any` type must not be used as a union member type.

The number of nullable member types of a union type must be 0 or 1, and if it is 1 then the union type must also not have a dictionary type in its flattened member types.

A type includes a nullable type if:

- the type is a nullable type, or

- the type is an annotated type and its inner type is a nullable type, or

- the type is a union type and its number of nullable member types is 1.

Each pair of flattened member types in a union type, T and U, must be distinguishable.

Union type constant values in IDL are represented in the same way that constant values of their member types would be represented.

The type name of a union type is formed by taking the type names of each member type, in order, and joining them with the string "`Or`".

#### 2.13.31. Annotated types

Additional types can be created from existing ones by specifying certain extended attributes on the existing types. Such types are called annotated types, and the types they annotate are called inner types.

`[Clamp] long` defines a new annotated type, whose behavior is based on that of the inner type `long`, but modified as specified by the [`Clamp`] extended attribute.

The following extended attributes are applicable to types: [`AllowShared`], [`Clamp`], [`EnforceRange`], and [`TreatNullAs`].

The extended attributes associated with an IDL type type are determined as follows:

1. Let extended attributes be a new empty set.

2. If type appears as part of a TypeWithExtendedAttributes production, append each of the extended attributes present in the production’s ExtendedAttributeList to extended attributes.

       [Exposed=Window]
       interface I {
           attribute [XAttr] long attrib;
           void f1(sequence<[XAttr] long> arg);
           void f2(optional [XAttr] long arg);

           maplike<[XAttr2] DOMString, [XAttr3] long>;
       };

       dictionary D {
           required [XAttr] long member;
       };

3. If type is a member type of a union type U, append each of the extended attributes associated with U to extended attributes.

       [Exposed=Window]
       interface I {
           attribute [XAttr] (long or Node) attrib;
       };

4. If type appears as part of a Type production directly within an Argument production, append to extended attributes all of the extended attributes present in the production’s ExtendedAttributeList that are applicable to types.

       [Exposed=Window]
       interface I {
           void f([XAttr] long attrib);
       };

   Note that this is an example of this step only if [`XAttr`] is applicable to types; otherwise [`XAttr`] applies to the argument, and not the argument’s type.

5. If type appears as part of a Type production directly within an DictionaryMember production, append to extended attributes all of the extended attributes present in the production’s ExtendedAttributeList that are applicable to types.

       dictionary D {
           [XAttr] long member;
       };

   Note that this is an example of this step only if [`XAttr`] is applicable to types; otherwise [`XAttr`] applies to the dictionary member, and not the member’s type.

6. If type is a typedef, append the extended attributes associated with the type being given a new name to extended attributes.

       typedef [XAttr] long xlong;

7. Return extended attributes.

For any type, the extended attributes associated with it must only contain extended attributes that are applicable to types.

The type name of a type associated with extended attributes is the concatenation of the type name of the original type with the set of strings corresponding to the identifiers of each extended attribute associated with the type, sorted in lexicographic order.

The type name for a type of the form `[B, A] long?` is "LongOrNullAB".

#### 2.13.32. Buffer source types

There are a number of types that correspond to sets of all possible non-null references to objects that represent a buffer of data or a view on to a buffer of data. The table below lists these types and the kind of buffer or view they represent.

Type | Kind of buffer
--- | ---
`ArrayBuffer` | An object that holds a pointer (which may be null) to a buffer of a fixed number of bytes
`DataView` | A view on to an `ArrayBuffer` that allows typed access to integers and floating point values stored at arbitrary offsets into the buffer
`Int8Array`, `Int16Array`, `Int32Array` | A view on to an `ArrayBuffer` that exposes it as an array of two’s complement signed integers of the given size in bits
`Uint8Array`, `Uint16Array`, `Uint32Array` | A view on to an `ArrayBuffer` that exposes it as an array of unsigned integers of the given size in bits
`Uint8ClampedArray` | A view on to an `ArrayBuffer` that exposes it as an array of unsigned 8 bit integers with clamped conversions
`Float32Array`, `Float64Array` | A view on to an `ArrayBuffer` that exposes it as an array of IEEE 754 floating point numbers of the given size in bits

Note: These types all correspond to classes defined in ECMAScript.

There is no way to represent a constant value of any of these types in IDL.

The type name of all of these types is the name of the type itself.

At the specification prose level, IDL buffer source types are simply references to objects. To inspect or manipulate the bytes inside the buffer, specification prose must first either get a reference to the bytes held by the buffer source or get a copy of the bytes held by the buffer source. With a reference to the buffer source’s bytes, specification prose can get or set individual byte values using that reference.

Extreme care must be taken when writing specification text that gets a reference to the bytes held by a buffer source, as the underlying data can easily be changed by the script author or other APIs at unpredictable times. If you are using a buffer source type as an operation argument to obtain a chunk of binary data that will not be modified, it is strongly recommended to get a copy of the buffer source’s bytes at the beginning of the prose defining the operation.

Requiring prose to explicitly get a reference to or copy of the bytes is intended to help specification reviewers look for problematic uses of these buffer source types.

When designing APIs that take a buffer, it is recommended to use the `BufferSource` typedef rather than `ArrayBuffer` or any of the view types.

When designing APIs that create and return a buffer, it is recommended to use the `ArrayBuffer` type rather than `Uint8Array`.

Attempting to get a reference to or get a copy of the bytes held by a buffer source when the `ArrayBuffer` has been detached will fail in a language binding-specific manner.

Note: See § 3.2.24 Buffer source types below for how interacting with buffer source types works in the ECMAScript language binding.

We should include an example of specification text that uses these types and terms.

    BufferRelatedType :
        "ArrayBuffer"
        "DataView"
        "Int8Array"
        "Int16Array"
        "Int32Array"
        "Uint8Array"
        "Uint16Array"
        "Uint32Array"
        "Uint8ClampedArray"
        "Float32Array"
        "Float64Array"

#### 2.13.33. Frozen array types — FrozenArray<T>

A frozen array type is a parameterized type whose values are references to objects that hold a fixed length array of unmodifiable values. The values in the array are of type T.

Since FrozenArray<T> values are references, they are unlike sequence types, which are lists of values that are passed by value.

There is no way to represent a constant frozen array value in IDL.

The type name of a frozen array type is the concatenation of the type name for T and the string "`Array`".

### 2.14. Extended attributes

An extended attribute is an annotation that can appear on definitions, types as annotated types, interface members, interface mixin members, callback interface members, namespace members, dictionary members, and operation arguments, and is used to control how language bindings will handle those constructs. Extended attributes are specified with an ExtendedAttributeList, which is a square bracket enclosed, comma separated list of ExtendedAttributes.

The ExtendedAttribute grammar symbol matches nearly any sequence of tokens, however the extended attributes defined in this document only accept a more restricted syntax. Any extended attribute encountered in an IDL fragment is matched against the following five grammar symbols to determine which form (or forms) it is in:

Grammar symbol | Form | Example
--- | --- | ---
ExtendedAttributeNoArgs | takes no arguments | `[Replaceable]`
ExtendedAttributeArgList | takes an argument list | Not currently used; previously used by `[Constructor(double x, double y)]`
ExtendedAttributeNamedArgList | takes a named argument list | `[NamedConstructor=Image(DOMString src)]`
ExtendedAttributeIdent | takes an identifier | `[PutForwards=name]`
ExtendedAttributeIdentList | takes an identifier list | `[Exposed=(Window,Worker)]`

This specification defines a number of extended attributes that are applicable to the ECMAScript language binding, which are described in § 3.3 ECMAScript-specific extended attributes. Each extended attribute definition will state which of the above five forms are allowed.

    ExtendedAttributeList :
        "[" ExtendedAttribute ExtendedAttributes "]"
        ε

    ExtendedAttributes :
        "," ExtendedAttribute ExtendedAttributes
        ε

    ExtendedAttribute :
        "(" ExtendedAttributeInner ")" ExtendedAttributeRest
        "[" ExtendedAttributeInner "]" ExtendedAttributeRest
        "{" ExtendedAttributeInner "}" ExtendedAttributeRest
        Other ExtendedAttributeRest

    ExtendedAttributeRest :
        ExtendedAttribute
        ε

    ExtendedAttributeInner :
        "(" ExtendedAttributeInner ")" ExtendedAttributeInner
        "[" ExtendedAttributeInner "]" ExtendedAttributeInner
        "{" ExtendedAttributeInner "}" ExtendedAttributeInner
        OtherOrComma ExtendedAttributeInner
        ε

    Other :
        integer
        decimal
        identifier
        string
        other
        "-"
        "-Infinity"
        "."
        "..."
        ":"
        ";"
        "<"
        "="
        ">"
        "?"
        "ByteString"
        "DOMString"
        "FrozenArray"
        "Infinity"
        "NaN"
        "Promise"
        "USVString"
        "any"
        "boolean"
        "byte"
        "double"
        "false"
        "float"
        "long"
        "null"
        "object"
        "octet"
        "or"
        "optional"
        "record"
        "sequence"
        "short"
        "symbol"
        "true"
        "unsigned"
        "void"
        ArgumentNameKeyword
        BufferRelatedType

    OtherOrComma :
        Other
        ","

    IdentifierList :
        identifier Identifiers

    Identifiers :
        "," identifier Identifiers
        ε

    ExtendedAttributeNoArgs :
        identifier

    ExtendedAttributeArgList :
        identifier "(" ArgumentList ")"

    ExtendedAttributeIdent :
        identifier "=" identifier

    ExtendedAttributeIdentList :
        identifier "=" "(" IdentifierList ")"

    ExtendedAttributeNamedArgList :
        identifier "=" identifier "(" ArgumentList ")"

## 3. ECMAScript binding

This section describes how definitions written with the IDL defined in § 2 Interface definition language correspond to particular constructs in ECMAScript, as defined by the ECMAScript Language Specification [ECMA-262].

Unless otherwise specified, objects defined in this section are ordinary objects as described in ECMA-262 Ordinary object internal methods and internal slots, and if the object is a function object, ECMA-262 Built-in function objects.

This section may redefine certain internal methods and/or internal slots of objects. Other specifications may also override the definitions of any internal method and/or internal slots of a platform object that is an instance of an interface. These objects with changed semantics shall be treated in accordance with the rules for exotic objects.

As overriding internal ECMAScript object methods is a low level operation and can result in objects that behave differently from ordinary objects, this facility should not be used unless necessary for security or compatibility. This is currently used to define the `HTMLAllCollection` and `Location` interfaces. [HTML]

Unless otherwise specified, exotic objects defined in this section and other specifications have the same internal slots as ordinary objects, and all of the internal methods for which alternative definitions are not given are the same as those of ordinary objects.

Unless otherwise specified, the [[Extensible]] internal slot of objects defined in this section has the value true.

Unless otherwise specified, the [[Prototype]] internal slot of objects defined in this section is `%ObjectPrototype%`.

Some objects described in this section are defined to have a class string, which is the string to include in the string returned from Object.prototype.toString.

If an object has a class string classString, then the object must, at the time it is created, have a property whose name is the `@@toStringTag` symbol with PropertyDescriptor{[[Writable]]: false, [[Enumerable]]: false, [[Configurable]]: true, [[Value]]: classString}.

Algorithms in this section use the conventions described in ECMA-262 Algorithm conventions, such as the use of steps and substeps, the use of mathematical operations, and so on. This section may also reference abstract operations and notations defined in other parts of ECMA-262.

When an algorithm says to throw a `SomethingError` then this means to construct a new ECMAScript `SomethingError` object in the current Realm and to throw it, just as the algorithms in ECMA-262 do.

Note that algorithm steps can call in to other algorithms and abstract operations and not explicitly handle exceptions that are thrown from them. When an exception is thrown by an algorithm or abstract operation and it is not explicitly handled by the caller, then it is taken to end the algorithm and propagate out to its caller, and so on.

Consider the following algorithm:

1. Let x be the ECMAScript value passed in to this algorithm.

2. Let y be the result of calling ToString(x).

3. Return y.

Since ToString can throw an exception (for example if passed the object `({ toString: function() { throw 1 } })`), and the exception is not handled in the above algorithm, if one is thrown then it causes this algorithm to end and for the exception to propagate out to its caller, if there is one.

### 3.1. ECMAScript environment

In an ECMAScript implementation of a given set of IDL fragments, there will exist a number of ECMAScript objects that correspond to definitions in those IDL fragments. These objects are termed the initial objects, and comprise the following:

- interface objects

- legacy callback interface objects

- named constructors

- interface prototype objects

- named properties objects

- iterator prototype objects

- attribute getters

- attribute setters

- the function objects that correspond to operations

- the function objects that correspond to stringifiers

- the function objects that correspond to iterators

- map size getters

Each Realm must have its own unique set of each of the initial objects, created before control enters any ECMAScript execution context associated with the Realm, but after the global object for that Realm is created. The [[Prototype]]s of all initial objects in a given Realm must come from that same Realm.

In an HTML user agent, multiple Realms can exist when multiple frames or windows are created. Each frame or window will have its own set of initial objects, which the following HTML document demonstrates:

    <!DOCTYPE html>
    <title>Different Realms</title>
    <iframe id=a></iframe>
    <script>
    var iframe = document.getElementById("a");
    var w = iframe.contentWindow;              // The global object in the frame

    Object == w.Object;                        // Evaluates to false, per ECMA-262
    Node == w.Node;                            // Evaluates to false
    iframe instanceof w.Node;                  // Evaluates to false
    iframe instanceof w.Object;                // Evaluates to false
    iframe.appendChild instanceof Function;    // Evaluates to true
    iframe.appendChild instanceof w.Function;  // Evaluates to false
    </script>

Note: All interfaces define which Realms they are exposed in. This allows, for example, Realms for Web Workers to expose different sets of supported interfaces from those exposed in Realms for Web pages.

Although at the time of this writing the ECMAScript specification does not reflect this, every ECMAScript object must have an associated Realm. The mechanisms for associating objects with Realms are, for now, underspecified. However, we note that in the case of platform objects, the associated Realm is equal to the object’s relevant Realm, and for non-exotic function objects (i.e. not callable proxies, and not bound functions) the associated Realm is equal to the value of the function object's [[Realm]] internal slot.

### 3.2. ECMAScript type mapping

This section describes how types in the IDL map to types in ECMAScript.

Each sub-section below describes how values of a given IDL type are represented in ECMAScript. For each IDL type, it is described how ECMAScript values are converted to an IDL value when passed to a platform object expecting that type, and how IDL values of that type are converted to ECMAScript values when returned from a platform object.

Note that the sub-sections and algorithms below also apply to annotated types created by applying extended attributes to the types named in their headers.

#### 3.2.1. any

Since the IDL `any` type is the union of all other IDL types, it can correspond to any ECMAScript value type.

An ECMAScript value V is converted to an IDL `any` value by running the following algorithm:

1. If V is undefined, then return an `object` reference to a special object that represents the ECMAScript undefined value.

2. If V is null, then return the null `object?` reference.

3. If Type(V) is Boolean, then return the `boolean` value that represents the same truth value.

4. If Type(V) is Number, then return the result of converting V to an `unrestricted double`.

5. If Type(V) is String, then return the result of converting V to a `DOMString`.

6. If Type(V) is Symbol, then return the result of converting V to a `symbol`.

7. If Type(V) is Object, then return an IDL `object` value that references V.

An IDL `any` value is converted to an ECMAScript value as follows. If the value is an `object` reference to a special object that represents an ECMAScript undefined value, then it is converted to the ECMAScript undefined value. Otherwise, the rules for converting the specific type of the IDL `any` value as described in the remainder of this section are performed.

#### 3.2.2. void

An ECMAScript value V is converted to an IDL `void` value by returning the unique `void` value, ignoring V.

The unique IDL `void` value is converted to the ECMAScript undefined value.

#### 3.2.3. boolean

An ECMAScript value V is converted to an IDL `boolean` value by running the following algorithm:

1. Let x be the result of computing ToBoolean(V).

2. Return the IDL `boolean` value that is the one that represents the same truth value as the ECMAScript Boolean value x.

The IDL `boolean` value `true` is converted to the ECMAScript true value and the IDL `boolean` value `false` is converted to the ECMAScript false value.

#### 3.2.4. Integer types

Mathematical operations used in this section, including those defined in ECMA-262 Algorithm conventions, are to be understood as computing exact mathematical results on mathematical real numbers.

In effect, where x is a Number value, “operating on x” is shorthand for “operating on the mathematical real number that represents the same numeric value as x”.

##### 3.2.4.1. byte

An ECMAScript value V is converted to an IDL `byte` value by running the following algorithm:

1. Let x be ? ConvertToInt(V, 8, "`signed`").

2. Return the IDL `byte` value that represents the same numeric value as x.

The result of converting an IDL `byte` value to an ECMAScript value is a Number that represents the same numeric value as the IDL `byte` value. The Number value will be an integer in the range [−128, 127].

##### 3.2.4.2. octet

An ECMAScript value V is converted to an IDL `octet` value by running the following algorithm:

1. Let x be ? ConvertToInt(V, 8, "`unsigned`").

2. Return the IDL `octet` value that represents the same numeric value as x.

The result of converting an IDL `octet` value to an ECMAScript value is a Number that represents the same numeric value as the IDL `octet` value. The Number value will be an integer in the range [0, 255].

##### 3.2.4.3. short

An ECMAScript value V is converted to an IDL `short` value by running the following algorithm:

1. Let x be ? ConvertToInt(V, 16, "`signed`").

2. Return the IDL `short` value that represents the same numeric value as x.

The result of converting an IDL `short` value to an ECMAScript value is a Number that represents the same numeric value as the IDL `short` value. The Number value will be an integer in the range [−32768, 32767].

##### 3.2.4.4. unsigned short

An ECMAScript value V is converted to an IDL `unsigned short` value by running the following algorithm:

1. Let x be ? ConvertToInt(V, 16, "`unsigned`").

2. Return the IDL `unsigned short` value that represents the same numeric value as x.

The result of converting an IDL `unsigned short` value to an ECMAScript value is a Number that represents the same numeric value as the IDL `unsigned short` value. The Number value will be an integer in the range [0, 65535].

##### 3.2.4.5. long

An ECMAScript value V is converted to an IDL `long` value by running the following algorithm:

1. Let x be ? ConvertToInt(V, 32, "`signed`").

2. Return the IDL `long` value that represents the same numeric value as x.

The result of converting an IDL `long` value to an ECMAScript value is a Number that represents the same numeric value as the IDL `long` value. The Number value will be an integer in the range [−2147483648, 2147483647].

##### 3.2.4.6. unsigned long

An ECMAScript value V is converted to an IDL `unsigned long` value by running the following algorithm:

1. Let x be ? ConvertToInt(V, 32, "`unsigned`").

2. Return the IDL `unsigned long` value that represents the same numeric value as x.

The result of converting an IDL `unsigned long` value to an ECMAScript value is a Number that represents the same numeric value as the IDL `unsigned long` value. The Number value will be an integer in the range [0, 4294967295].

##### 3.2.4.7. long long

An ECMAScript value V is converted to an IDL `long long` value by running the following algorithm:

1. Let x be ? ConvertToInt(V, 64, "`signed`").

2. Return the IDL `long long` value that represents the same numeric value as x.

The result of converting an IDL `long long` value to an ECMAScript value is a Number value that represents the closest numeric value to the `long long`, choosing the numeric value with an even significand if there are two equally close values. If the `long long` is in the range [−253 + 1, 253 − 1], then the Number will be able to represent exactly the same value as the `long long`.

##### 3.2.4.8. unsigned long long

An ECMAScript value V is converted to an IDL `unsigned long long` value by running the following algorithm:

1. Let x be ? ConvertToInt(V, 64, "`unsigned`").

2. Return the IDL `unsigned long long` value that represents the same numeric value as x.

The result of converting an IDL `unsigned long long` value to an ECMAScript value is a Number value that represents the closest numeric value to the `unsigned long long`, choosing the numeric value with an even significand if there are two equally close values. If the `unsigned long long` is less than or equal to 253 − 1, then the Number will be able to represent exactly the same value as the `unsigned long long`.

##### 3.2.4.9. Abstract operations

IntegerPart(n):

1. Let r be floor(abs(n)).

2. If n < 0, then return -1 × r.

3. Otherwise, return r.

ConvertToInt(V, bitLength, signedness):

1. If bitLength is 64, then:

   1. Let upperBound be 253 − 1.

   2. If signedness is "`unsigned`", then let lowerBound be 0.

   3. Otherwise let lowerBound be −253 + 1.

      Note: this ensures `long long` types associated with [`EnforceRange`] or [`Clamp`] extended attributes are representable in ECMAScript’s Number type as unambiguous integers.

2. Otherwise, if signedness is "`unsigned`", then:

   1. Let lowerBound be 0.

   2. Let upperBound be 2bitLength − 1.

3. Otherwise:

   1. Let lowerBound be -2bitLength − 1.

   2. Let upperBound be 2bitLength − 1 − 1.

4. Let x be ? ToNumber(V).

5. If x is −0, then set x to +0.

6. If the conversion is to an IDL type associated with the [`EnforceRange`] extended attribute, then:

   1. If x is NaN, +∞, or −∞, then throw a `TypeError`.

   2. Set x to ! IntegerPart(x).

   3. If x < lowerBound or x > upperBound, then throw a `TypeError`.

   4. Return x.

7. If x is not NaN and the conversion is to an IDL type associated with the [`Clamp`] extended attribute, then:

   1. Set x to min(max(x, lowerBound), upperBound).

   2. Round x to the nearest integer, choosing the even integer if it lies halfway between two, and choosing +0 rather than −0.

   3. Return x.

8. If x is NaN, +0, +∞, or −∞, then return +0.

9. Set x to ! IntegerPart(x).

10. Set x to x modulo 2bitLength.

11. If signedness is "`signed`" and x ≥ 2bitLength − 1, then return x − 2bitLength.

12. Otherwise, return x.

#### 3.2.5. float

An ECMAScript value V is converted to an IDL `float` value by running the following algorithm:

1. Let x be ? ToNumber(V).

2. If x is NaN, +∞, or −∞, then throw a `TypeError`.

3. Let S be the set of finite IEEE 754 single-precision floating point values except −0, but with two special values added: 2128 and −2128.

4. Let y be the number in S that is closest to x, selecting the number with an even significand if there are two equally close values. (The two special values 2128 and −2128 are considered to have even significands for this purpose.)

5. If y is 2128 or −2128, then throw a `TypeError`.

6. If y is +0 and x is negative, return −0.

7. Return y.

The result of converting an IDL `float` value to an ECMAScript value is the Number value that represents the same numeric value as the IDL `float` value.

#### 3.2.6. unrestricted float

An ECMAScript value V is converted to an IDL `unrestricted float` value by running the following algorithm:

1. Let x be ? ToNumber(V).

2. If x is NaN, then return the IDL `unrestricted float` value that represents the IEEE 754 NaN value with the bit pattern 0x7fc00000 [IEEE-754].

3. Let S be the set of finite IEEE 754 single-precision floating point values except −0, but with two special values added: 2128 and −2128.

4. Let y be the number in S that is closest to x, selecting the number with an even significand if there are two equally close values. (The two special values 2128 and −2128 are considered to have even significands for this purpose.)

5. If y is 2128, return +∞.

6. If y is −2128, return −∞.

7. If y is +0 and x is negative, return −0.

8. Return y.

Note: Since there is only a single ECMAScript NaN value, it must be canonicalized to a particular single precision IEEE 754 NaN value. The NaN value mentioned above is chosen simply because it is the quiet NaN with the lowest value when its bit pattern is interpreted as an unsigned 32 bit integer.

The result of converting an IDL `unrestricted float` value to an ECMAScript value is a Number:

1. If the IDL `unrestricted float` value is a NaN, then the Number value is NaN.

2. Otherwise, the Number value is the one that represents the same numeric value as the IDL `unrestricted float` value.

#### 3.2.7. double

An ECMAScript value V is converted to an IDL `double` value by running the following algorithm:

1. Let x be ? ToNumber(V).

2. If x is NaN, +∞, or −∞, then throw a `TypeError`.

3. Return the IDL `double` value that represents the same numeric value as x.

The result of converting an IDL `double` value to an ECMAScript value is the Number value that represents the same numeric value as the IDL `double` value.

#### 3.2.8. unrestricted double

An ECMAScript value V is converted to an IDL `unrestricted double` value by running the following algorithm:

1. Let x be ? ToNumber(V).

2. If x is NaN, then return the IDL `unrestricted double` value that represents the IEEE 754 NaN value with the bit pattern 0x7ff8000000000000 [IEEE-754].

3. Return the IDL `unrestricted double` value that represents the same numeric value as x.

Note: Since there is only a single ECMAScript NaN value, it must be canonicalized to a particular double precision IEEE 754 NaN value. The NaN value mentioned above is chosen simply because it is the quiet NaN with the lowest value when its bit pattern is interpreted as an unsigned 64 bit integer.

The result of converting an IDL `unrestricted double` value to an ECMAScript value is a Number:

1. If the IDL `unrestricted double` value is a NaN, then the Number value is NaN.

2. Otherwise, the Number value is the one that represents the same numeric value as the IDL `unrestricted double` value.

#### 3.2.9. DOMString

An ECMAScript value V is converted to an IDL `DOMString` value by running the following algorithm:

1. If V is null and the conversion is to an IDL type associated with the [`TreatNullAs`] extended attribute, then return the `DOMString` value that represents the empty string.

2. Let x be ToString(V).

3. Return the IDL `DOMString` value that represents the same sequence of code units as the one the ECMAScript String value x represents.

The result of converting an IDL `DOMString` value to an ECMAScript value is the String value that represents the same sequence of code units that the IDL `DOMString` represents.

#### 3.2.10. ByteString

An ECMAScript value V is converted to an IDL `ByteString` value by running the following algorithm:

1. Let x be ToString(V).

2. If the value of any element of x is greater than 255, then throw a `TypeError`.

3. Return an IDL `ByteString` value whose length is the length of x, and where the value of each element is the value of the corresponding element of x.

The result of converting an IDL `ByteString` value to an ECMAScript value is a String value whose length is the length of the `ByteString`, and the value of each element of which is the value of the corresponding element of the `ByteString`.

#### 3.2.11. USVString

An ECMAScript value V is converted to an IDL `USVString` value by running the following algorithm:

1. Let string be the result of converting V to a `DOMString`.

2. Return an IDL `USVString` value that is the result of converting string to a sequence of Unicode scalar values.

An IDL `USVString` value is converted to an ECMAScript value by running the following algorithm:

1. Let scalarValues be the sequence of Unicode scalar values the `USVString` represents.

2. Let string be the sequence of code units that results from encoding scalarValues in UTF-16.

3. Return the String value that represents the same sequence of code units as string.

#### 3.2.12. object

IDL `object` values are represented by ECMAScript Object values.

An ECMAScript value V is converted to an IDL `object` value by running the following algorithm:

1. If Type(V) is not Object, then throw a `TypeError`.

2. Return the IDL `object` value that is a reference to the same object as V.

The result of converting an IDL `object` value to an ECMAScript value is the Object value that represents a reference to the same object that the IDL `object` represents.

#### 3.2.13. symbol

IDL `symbol` values are represented by ECMAScript Symbol values.

An ECMAScript value V is converted to an IDL `symbol` value by running the following algorithm:

1. If Type(V) is not Symbol, then throw a `TypeError`.

2. Return the IDL `symbol` value that is a reference to the same symbol as V.

The result of converting an IDL `symbol` value to an ECMAScript value is the Symbol value that represents a reference to the same symbol that the IDL `symbol` represents.

#### 3.2.14. Interface types

IDL interface type values are represented by ECMAScript Object values (including function objects).

An ECMAScript value V is converted to an IDL interface type value by running the following algorithm (where I is the interface):

1. If V implements I, then return the IDL interface type value that represents a reference to that platform object.

2. Throw a `TypeError`.

The result of converting an IDL interface type value to an ECMAScript value is the Object value that represents a reference to the same object that the IDL interface type value represents.

#### 3.2.15. Callback interface types

IDL callback interface type values are represented by ECMAScript Object values (including function objects).

An ECMAScript value V is converted to an IDL callback interface type value by running the following algorithm:

1. If Type(V) is not Object, then throw a `TypeError`.

2. Return the IDL callback interface type value that represents a reference to V, with the incumbent settings object as the callback context.

The result of converting an IDL callback interface type value to an ECMAScript value is the Object value that represents a reference to the same object that the IDL callback interface type value represents.

#### 3.2.16. Dictionary types

IDL dictionary type values are represented by ECMAScript Object values. Properties on the object (or its prototype chain) correspond to dictionary members.

An ECMAScript value esDict is converted to an IDL dictionary type value by running the following algorithm (where D is the dictionary type):

1. If Type(esDict) is not Undefined, Null or Object, then throw a `TypeError`.

2. Let idlDict be an empty dictionary value of type D; every dictionary member is initially considered to be not present.

3. Let dictionaries be a list consisting of D and all of D’s inherited dictionaries, in order from least to most derived.

4. For each dictionary dictionary in dictionaries, in order:

   1. For each dictionary member member declared on dictionary, in lexicographical order:

      1. Let key be the identifier of member.

      2. Let esMemberValue be an ECMAScript value, depending on Type(esDict):

         Undefined
         Null

           undefined

         anything else

           ? Get(esDict, key)

      3. If esMemberValue is not undefined, then:

         1. Let idlMemberValue be the result of converting esMemberValue to an IDL value whose type is the type member is declared to be of.

         2. Set the dictionary member on idlDict with key name key to the value idlMemberValue. This dictionary member is considered to be present.

      4. Otherwise, if esMemberValue is undefined but member has a default value, then:

         1. Let idlMemberValue be member’s default value.

         2. Set the dictionary member on idlDict with key name key to the value idlMemberValue. This dictionary member is considered to be present.

      5. Otherwise, if esMemberValue is undefined and member is a required dictionary member, then throw a `TypeError`.

5. Return idlDict.

Note: The order that dictionary members are looked up on the ECMAScript object are not necessarily the same as the object’s property enumeration order.

An IDL dictionary value V is converted to an ECMAScript Object value by running the following algorithm (where D is the dictionary):

1. Let O be ! ObjectCreate(`%ObjectPrototype%`).

2. Let dictionaries be a list consisting of D and all of D’s inherited dictionaries, in order from least to most derived.

3. For each dictionary dictionary in dictionaries, in order:

   1. For each dictionary member member declared on dictionary, in lexicographical order:

      1. Let key be the identifier of member.

      2. If the dictionary member named key is present in V, then:

         1. Let idlValue be the value of member on V.

         2. Let value be the result of converting idlValue to an ECMAScript value.

         3. Perform ! CreateDataProperty(O, key, value).

4. Return O.

#### 3.2.17. Enumeration types

IDL enumeration types are represented by ECMAScript String values.

An ECMAScript value V is converted to an IDL enumeration type value as follows (where E is the enumeration):

1. Let S be the result of calling ToString(V).

2. If S is not one of E’s enumeration values, then throw a `TypeError`.

3. Return the enumeration value of type E that is equal to S.

The result of converting an IDL enumeration type value to an ECMAScript value is the String value that represents the same sequence of code units as the enumeration value.

#### 3.2.18. Callback function types

IDL callback function types are represented by ECMAScript function objects, except in the [`TreatNonObjectAsNull`] case, when they can be any object.

An ECMAScript value V is converted to an IDL callback function type value by running the following algorithm:

1. If the result of calling IsCallable(V) is false and the conversion to an IDL value is not being performed due to V being assigned to an attribute whose type is a nullable callback function that is annotated with [`TreatNonObjectAsNull`], then throw a `TypeError`.

2. Return the IDL callback function type value that represents a reference to the same object that V represents, with the incumbent settings object as the callback context.

The result of converting an IDL callback function type value to an ECMAScript value is a reference to the same object that the IDL callback function type value represents.

#### 3.2.19. Nullable types — T?

IDL nullable type values are represented by values of either the ECMAScript type corresponding to the inner IDL type, or the ECMAScript null value.

An ECMAScript value V is converted to an IDL nullable type `T?` value (where T is the inner type) as follows:

1. If Type(V) is not Object, and the conversion to an IDL value is being performed due to V being assigned to an attribute whose type is a nullable callback function that is annotated with [`TreatNonObjectAsNull`], then return the IDL nullable type `T?` value null.

2. Otherwise, if V is null or undefined, then return the IDL nullable type `T?` value null.

3. Otherwise, return the result of converting V using the rules for the inner IDL type `T`.

The result of converting an IDL nullable type value to an ECMAScript value is:

1. If the IDL nullable type `T?` value is null, then the ECMAScript value is null.

2. Otherwise, the ECMAScript value is the result of converting the IDL nullable type value to the inner IDL type `T`.

#### 3.2.20. Sequences — sequence<T>

IDL sequence<T> values are represented by ECMAScript Array values.

An ECMAScript value V is converted to an IDL sequence<T> value as follows:

1. If Type(V) is not Object, throw a `TypeError`.

2. Let method be ? GetMethod(V, `@@iterator`).

3. If method is undefined, throw a `TypeError`.

4. Return the result of creating a sequence from V and method.

An IDL sequence value S of type sequence<T> is converted to an ECMAScript Array object as follows:

1. Let n be the length of S.

2. Let A be a new Array object created as if by the expression `[]`.

3. Initialize i to be 0.

4. While i < n:

   1. Let V be the value in S at index i.

   2. Let E be the result of converting V to an ECMAScript value.

   3. Let P be the result of calling ToString(i).

   4. Call CreateDataProperty(A, P, E).

   5. Set i to i + 1.

5. Return A.

##### 3.2.20.1. Creating a sequence from an iterable

To create an IDL value of type sequence<T> given an iterable iterable and an iterator getter method, perform the following steps:

1. Let iter be ? GetIterator(iterable, sync, method).

2. Initialize i to be 0.

3. Repeat

   1. Let next be ? IteratorStep(iter).

   2. If next is false, then return an IDL sequence value of type sequence<T> of length i, where the value of the element at index j is Sj.

   3. Let nextItem be ? IteratorValue(next).

   4. Initialize Si to the result of converting nextItem to an IDL value of type T.

   5. Set i to i + 1.

The following interface defines an attribute of a sequence type as well as an operation with an argument of a sequence type.

    [Exposed=Window]
    interface Canvas {

      sequence<DOMString> getSupportedImageCodecs();

      void drawPolygon(sequence<double> coordinates);
      sequence<double> getLastDrawnPolygon();

      // ...
    };

In an ECMAScript implementation of this interface, an Array object with elements of type String is used to represent a `sequence<DOMString>`, while an Array with elements of type Number represents a `sequence<double>`. The Array objects are effectively passed by value; every time the `getSupportedImageCodecs()` function is called a new Array is returned, and whenever an Array is passed to `drawPolygon` no reference will be kept after the call completes.

    // Obtain an instance of Canvas.  Assume that getSupportedImageCodecs()
    // returns a sequence with two DOMString values: "image/png" and "image/svg+xml".
    var canvas = getCanvas();

    // An Array object of length 2.
    var supportedImageCodecs = canvas.getSupportedImageCodecs();

    // Evaluates to "image/png".
    supportedImageCodecs[0];

    // Each time canvas.getSupportedImageCodecs() is called, it returns a
    // new Array object.  Thus modifying the returned Array will not
    // affect the value returned from a subsequent call to the function.
    supportedImageCodecs[0] = "image/jpeg";

    // Evaluates to "image/png".
    canvas.getSupportedImageCodecs()[0];

    // This evaluates to false, since a new Array object is returned each call.
    canvas.getSupportedImageCodecs() == canvas.getSupportedImageCodecs();

    // An Array of Numbers...
    var a = [0, 0, 100, 0, 50, 62.5];

    // ...can be passed to a platform object expecting a sequence<double>.
    canvas.drawPolygon(a);

    // Each element will be converted to a double by first calling ToNumber().
    // So the following call is equivalent to the previous one, except that
    // "hi" will be alerted before drawPolygon() returns.
    a = [false, '',
         { valueOf: function() { alert('hi'); return 100; } }, 0,
         '50', new Number(62.5)];
    canvas.drawPolygon(a);

    // Modifying an Array that was passed to drawPolygon() is guaranteed not to
    // have an effect on the Canvas, since the Array is effectively passed by value.
    a[4] = 20;
    var b = canvas.getLastDrawnPolygon();
    alert(b[4]);    // This would alert "50".

#### 3.2.21. Records — record<K, V>

IDL record<K, V> values are represented by ECMAScript Object values.

An ECMAScript value O is converted to an IDL `record<K, V>` value as follows:

1. If Type(O) is not Object, throw a `TypeError`.

2. Let result be a new empty instance of `record<K, V>`.

3. Let keys be ? O.[[OwnPropertyKeys]]().

4. For each key of keys:

   1. Let desc be ? O.[[GetOwnProperty]](key).

   2. If desc is not undefined and desc.[[Enumerable]] is true:

      1. Let typedKey be key converted to an IDL value of type K.

      2. Let value be ? Get(O, key).

      3. Let typedValue be value converted to an IDL value of type V.

      4. Set result[typedKey] to typedValue.

         Note: it’s possible that typedKey is already in result, if O is a proxy object.

5. Return result.

An IDL `record<…>` value D is converted to an ECMAScript value as follows:

1. Let result be ! ObjectCreate(`%ObjectPrototype%`).

2. For each key → value of D:

   1. Let esKey be key converted to an ECMAScript value.

   2. Let esValue be value converted to an ECMAScript value.

   3. Let created be ! CreateDataProperty(result, esKey, esValue).

   4. Assert: created is true.

3. Return result.

Passing the ECMAScript value `{b: 3, a: 4}` as a `record<DOMString, double>` argument would result in the IDL value «[ "`b`" → 3, "`a`" → 4 ]».

Records only consider own enumerable properties, so given an IDL operation `record<DOMString, double> identity(record<DOMString, double> arg)` which returns its argument, the following code passes its assertions:

    let proto = {a: 3, b: 4};
    let obj = {__proto__: proto, d: 5, c: 6}
    Object.defineProperty(obj, "e", {value: 7, enumerable: false});
    let result = identity(obj);
    console.assert(result.a === undefined);
    console.assert(result.b === undefined);
    console.assert(result.e === undefined);
    let entries = Object.entries(result);
    console.assert(entries[0][0] === "d");
    console.assert(entries[0][1] === 5);
    console.assert(entries[1][0] === "c");
    console.assert(entries[1][1] === 6);

Record keys and values can be constrained, although keys can only be constrained among the three string types. The following conversions have the described results:

Value | Passed to type | Result
--- | --- | ---
`{"😞": 1}` | `record<ByteString, double>` | `TypeError`
`{"\uD83D": 1}` | `record<USVString, double>` | «[ "`\uFFFD`" → 1 ]»
`{"\uD83D": {hello: "world"}}` | `record<DOMString, double>` | «[ "`\uD83D`" → 0 ]»

#### 3.2.22. Promise types — Promise<T>

IDL promise type values are represented by ECMAScript PromiseCapability records.

An ECMAScript value V is converted to an IDL `Promise<T>` value as follows:

1. Let promiseCapability be ? NewPromiseCapability(`%Promise%`).

2. Perform ? Call(promiseCapability.[[Resolve]], undefined, « V »).

3. Return promiseCapability.

The result of converting an IDL promise type value to an ECMAScript value is the value of the [[Promise]] field of the record that IDL promise type represents.

##### 3.2.22.1. Creating and manipulating Promises

To create a new `Promise<T>` in a Realm realm, perform the following steps:

1. Let constructor be realm.[[Intrinsics]].[[`%Promise%`]].

2. Return ? NewPromiseCapability(constructor).

To create a resolved promise of type `Promise<T>`, with x (a value of type T) in a Realm realm, perform the following steps:

1. Let value be the result of converting x to an ECMAScript value.

2. Let constructor be realm.[[Intrinsics]].[[`%Promise%`]].

3. Let promiseCapability be ? NewPromiseCapability(constructor).

4. Perform ! Call(promiseCapability.[[Resolve]], undefined, « value »).

5. Return promiseCapability.

To create a rejected promise of type `Promise<T>`, with reason r (an ECMAScript value) in a Realm realm, perform the following steps:

1. Let constructor be realm.[[Intrinsics]].[[`%Promise%`]].

2. Let promiseCapability be ? NewPromiseCapability(constructor).

3. Perform ! Call(promiseCapability.[[Reject]], undefined, « r »).

4. Return promiseCapability.

To resolve a `Promise<T>` p with x (a value of type T), perform the following steps:

1. If x is not given, then let it be the `void` value.

2. Let value be the result of converting x to an ECMAScript value.

3. Perform ! Call(p.[[Resolve]], undefined, « value »).

If T is `void`, then the x argument is optional, allowing a simpler "resolve p" usage.

To reject a `Promise<T>` p with reason r (an ECMAScript value), perform the following steps:

1. Perform ! Call(p.[[Reject]], undefined, « r »).

To react to a `Promise<T>` promise, given one or two sets of steps to perform, covering when the promise is fulfilled, rejected, or both, perform the following steps:

1. Let onFulfilledSteps be the following steps given argument V:

   1. Let value be the result of converting V to an IDL value of type T.

   2. If there are no steps that are required to be run if the promise was fulfilled, then return undefined.

   3. Let result be the result of performing any steps that were required to be run if the promise was fulfilled, given value if T is not `void`.

   4. Return result, converted to an ECMAScript value.

2. Let onFulfilled be ! CreateBuiltinFunction(onFulfilledSteps, « »):

3. Let onRejectedSteps be the following steps given argument R:

   1. Let reason be the result of converting R to an IDL value of type `any`.

   2. If there are no steps that are required to be run if the promise was rejected, then return undefined.

   3. Let result be the result of performing any steps that were required to be run if the promise was rejected, given reason.

   4. Return result, converted to an ECMAScript value.

4. Let onRejected be ! CreateBuiltinFunction(onRejectedSteps, « »):

5. Let constructor be promise.[[Promise]].[[Realm]].[[Intrinsics]].[[`%Promise%`]].

6. Let newCapability be ? NewPromiseCapability(constructor).

   Note: Not all callers will use the returned `Promise`. Implementations might wish to avoid creating newCapability in those cases.

7. Return ! PerformPromiseThen(promise.[[Promise]], onFulfilled, onRejected, newCapability).

Note: This algorithm will behave in a very similar way to the `Promise.then()` method. In particular, if the steps return a value of type U or `Promise<U>`, this algorithm returns a `Promise<U>` as well.

To perform some steps upon fulfillment of a `Promise<T>` promise given some steps steps taking a value of type T, perform the following steps:

1. React to promise:

   - If promise was fulfilled with value v, then:

     1. Perform steps with v.

To perform some steps upon rejection of a `Promise<T>` promise given some steps steps taking an ECMAScript value, perform the following steps:

1. React to promise:

   - If promise was rejected with reason r, then:

     1. Perform steps with r.

To wait for all with a list of `Promise<T>` values promises, with success steps successSteps that take a list of T values and failure steps failureSteps that take a rejection reason `any` value, perform the following steps:

1. Let fullfilledCount be 0.

2. Let rejected be false.

3. Let rejectionHandlerSteps be the following steps given arg:

   1. If rejected is true, abort these steps.

   2. Set rejected to true.

   3. Perform failureSteps given arg.

4. Let rejectionHandler be ! CreateBuiltinFunction(rejectionHandlerSteps, « »):

5. Let total be promises’s size.

6. If total is 0, then:

   1. Queue a microtask to perform successSteps given « ».

   2. Return.

7. Let index be 0.

8. Let result be a list containing total null values.

9. For each promise of promises:

   1. Let promiseIndex be index.

   2. Let fulfillmentHandler be the following steps given arg:

      1. Set result[promiseIndex] to arg.

      2. Set fullfilledCount to fullfilledCount + 1.

      3. If fullfilledCount equals total, then perform successSteps given result.

   3. Let fulfillmentHandler be ! CreateBuiltinFunction(fulfillmentHandler, « »):

   4. Perform PerformPromiseThen(promise, fulfillmentHandler, rejectionHandler).

   5. Set index to index + 1.

To get a promise for waiting for all with a list of `Promise<T>` values promises and a Realm realm, perform the following steps:

1. Let promise be a new promise of type `Promise<sequence<T>>` in realm.

2. Let successSteps be the following steps, given results:

   1. Resolve promise with results.

3. Let failureSteps be the following steps, given reason:

   1. Reject promise with reason.

4. Wait for all with promises, given successSteps and failureSteps.

5. Return promise.

This phrase is useful when you wish to aggregate the results of multiple promises, and then produce another promise from them, in the same way that `Promise.all()` functions for JavaScript code.

##### 3.2.22.2. Examples

`delay` is an operation that returns a promise that will be fulfilled in a number of milliseconds. It illustrates how simply you can resolve a promise, with one line of prose.

    interface I {
      Promise<void> delay(unrestricted double ms);
    };

The `delay(ms)` method steps are:

1. Let realm be this’s relevant Realm.

2. If ms is NaN, let ms be +0; otherwise let ms be the maximum of ms and +0.

3. Let p be a new promise in realm.

4. Run the following steps in parallel:

   1. Wait ms milliseconds.

   2. Resolve p.

5. Return p.

The `validatedDelay` operation is much like the `delay` function, except it will validate its arguments. This shows how to use rejected promises to signal immediate failure before even starting any asynchronous operations.

    interface I {
      Promise<void> validatedDelay(unrestricted double ms);
    };

The `validatedDelay(ms)` method steps are:

1. Let realm be this’s relevant Realm.

2. If ms is NaN, return a promise rejected with a `TypeError` in realm.

3. If ms < 0, return a promise rejected with a `RangeError` in realm.

4. Let p be a new promise in realm.

5. Run the following steps in parallel:

   1. Wait ms milliseconds.

   2. Resolve p.

6. Return p.

`addDelay` is an operation that adds an extra number of milliseconds of delay between promise settling and the returned promise settling.

    interface I {
      Promise<any> addDelay(Promise<any> promise, unrestricted double ms);
    };

The `addDelay(ms, promise)` method steps are:

1. Let realm be this’s relevant Realm.

2. Let taskSource be some appropriate task source.

3. If ms is NaN, let ms be +0; otherwise let ms be the maximum of ms and +0.

4. Let p be a new promise in realm.

5. React to promise:

   - If promise was fulfilled with value v, then:

     1. Run the following steps in parallel:

        1. Wait ms milliseconds.

        2. Queue a task to run the following steps on taskSource:

           1. Resolve p with v.

   - If promise was rejected with reason r, then:

     1. Run the following steps in parallel:

        1. Wait ms milliseconds.

        2. Queue a task to run the following steps on taskSource:

           1. Reject p with r.

6. Return p.

`environment.ready` is an attribute that signals when some part of some environment, e.g. a DOM document, becomes "ready". It illustrates how to encode environmental asynchronicity.

    interface Environment {
      readonly attribute Promise<void> ready;
    };

Every `Environment` object must have a ready promise, which is a `Promise<void>`.

The `ready` attribute getter steps are:

1. Return this’s ready promise.

To create an `Environment` object in a Realm realm, perform the following steps:

1. Let environment be new `Environment` object in realm.

2. Set environment’s ready promise to a new promise in realm.

3. Run the following steps in parallel:

   1. Do some asynchronous work.

   2. If environment becomes ready successfully, resolve environment’s ready promise.

   3. If environment fails to become ready, reject environment’s ready promise with a "`NetworkError`" `DOMException`.

4. Return environment.

`addBookmark` is an operation that requests that the user add the current web page as a bookmark. It’s drawn from some iterative design work and illustrates a more real-world scenario of appealing to environmental asynchrony, as well as immediate rejections.

    interface I {
      Promise<void> addBookmark();
    };

The `addBookmark()` method steps are:

1. If this method was not invoked as a result of explicit user action, return a promise rejected with a "`SecurityError`" `DOMException`.

2. If the document’s mode of operation is standalone, return a promise rejected with a "`NotSupportedError`" `DOMException`.

3. Let promise be a new promise.

4. Let info be the result of getting a web application’s metadata.

5. Run the following steps in parallel:

   1. Using info, and in a manner that is user-agent specific, allow the end user to make a choice as to whether they want to add the bookmark.

      1. If the end-user aborts the request to add the bookmark (e.g., they hit escape, or press a "cancel" button), reject promise with an "`AbortError`" `DOMException`.

      2. Otherwise, resolve promise.

6. Return promise.

Several places in [SERVICE-WORKERS] use get a promise to wait for all. `batchRequest` illustrates a simplified version of one of their uses. It takes as input a sequence of URLs, and returns a promise for a sequence of `Response` objects created by fetching the corresponding URL. If any of the fetches fail, it will return a promise rejected with that failure.

    interface I {
      Promise<sequence<Response>> batchRequest(sequence<USVString> urls);
    };

The `batchRequest(urls)` method steps are:

1. Let responsePromises be « ».

2. For each url of urls:

   1. Let p be the result of calling `fetch()` with url.

   2. Append p to responsePromises.

3. Let p be the result of getting a promise to wait for all with responsePromises.

4. Return p.

#### 3.2.23. Union types

IDL union type values are represented by ECMAScript values that correspond to the union’s member types.

To convert an ECMAScript value V to an IDL union type value is done as follows:

1. If the union type includes a nullable type and V is null or undefined, then return the IDL value null.

2. Let types be the flattened member types of the union type.

3. If V is null or undefined, then:

   1. If types includes a dictionary type, then return the result of converting V to that dictionary type.

4. If V is a platform object, then:

   1. If types includes an interface type that V implements, then return the IDL value that is a reference to the object V.

   2. If types includes `object`, then return the IDL value that is a reference to the object V.

5. If Type(V) is Object and V has an [[ArrayBufferData]] internal slot, then:

   1. If types includes `ArrayBuffer`, then return the result of converting V to `ArrayBuffer`.

   2. If types includes `object`, then return the IDL value that is a reference to the object V.

6. If Type(V) is Object and V has a [[DataView]] internal slot, then:

   1. If types includes `DataView`, then return the result of converting V to `DataView`.

   2. If types includes `object`, then return the IDL value that is a reference to the object V.

7. If Type(V) is Object and V has a [[TypedArrayName]] internal slot, then:

   1. If types includes a typed array type whose name is the value of V’s [[TypedArrayName]] internal slot, then return the result of converting V to that type.

   2. If types includes `object`, then return the IDL value that is a reference to the object V.

8. If IsCallable(V) is true, then:

   1. If types includes a callback function type, then return the result of converting V to that callback function type.

   2. If types includes `object`, then return the IDL value that is a reference to the object V.

9. If Type(V) is Object, then:

   1. If types includes a sequence type, then

      1. Let method be ? GetMethod(V, `@@iterator`).

      2. If method is not undefined, return the result of creating a sequence of that type from V and method.

   2. If types includes a frozen array type, then

      1. Let method be ? GetMethod(V, `@@iterator`).

      2. If method is not undefined, return the result of creating a frozen array of that type from V and method.

   3. If types includes a dictionary type, then return the result of converting V to that dictionary type.

   4. If types includes a record type, then return the result of converting V to that record type.

   5. If types includes a callback interface type, then return the result of converting V to that callback interface type.

   6. If types includes `object`, then return the IDL value that is a reference to the object V.

10. If Type(V) is Boolean, then:

    1. If types includes a `boolean`, then return the result of converting V to `boolean`.

11. If Type(V) is Number, then:

    1. If types includes a numeric type, then return the result of converting V to that numeric type.

12. If types includes a string type, then return the result of converting V to that type.

13. If types includes a numeric type, then return the result of converting V to that numeric type.

14. If types includes a `boolean`, then return the result of converting V to `boolean`.

15. Throw a `TypeError`.

An IDL union type value is converted to an ECMAScript value as follows. If the value is an `object` reference to a special object that represents an ECMAScript undefined value, then it is converted to the ECMAScript undefined value. Otherwise, the rules for converting the specific type of the IDL union type value as described in this section (§ 3.2 ECMAScript type mapping).

#### 3.2.24. Buffer source types

Values of the IDL buffer source types are represented by objects of the corresponding ECMAScript class, with the additional restriction that unless the type is associated with the [`AllowShared`] extended attribute, they can only be backed by ECMAScript `ArrayBuffer` objects, and not `SharedArrayBuffer` objects.

An ECMAScript value V is converted to an IDL `ArrayBuffer` value by running the following algorithm:

1. If Type(V) is not Object, or V does not have an [[ArrayBufferData]] internal slot, then throw a `TypeError`.

2. If the conversion is not to an IDL type associated with the [`AllowShared`] extended attribute, and IsSharedArrayBuffer(V) is true, then throw a `TypeError`.

3. Return the IDL `ArrayBuffer` value that is a reference to the same object as V.

An ECMAScript value V is converted to an IDL `DataView` value by running the following algorithm:

1. If Type(V) is not Object, or V does not have a [[DataView]] internal slot, then throw a `TypeError`.

2. If the conversion is not to an IDL type associated with the [`AllowShared`] extended attribute, and IsSharedArrayBuffer(V.[[ViewedArrayBuffer]]) is true, then throw a `TypeError`.

3. Return the IDL `DataView` value that is a reference to the same object as V.

An ECMAScript value V is converted to an IDL `Int8Array`, `Int16Array`, `Int32Array`, `Uint8Array`, `Uint16Array`, `Uint32Array`, `Uint8ClampedArray`, `Float32Array` or `Float64Array` value by running the following algorithm:

1. Let T be the IDL type V is being converted to.

2. Let typedArrayName be the name of T’s inner type if T is an annotated type, or the name of T otherwise.

3. If Type(V) is not Object, or V does not have a [[TypedArrayName]] internal slot with a value equal to typedArrayName, then throw a `TypeError`.

4. If the conversion is not to an IDL type associated with the [`AllowShared`] extended attribute, and IsSharedArrayBuffer(V.[[ViewedArrayBuffer]]) is true, then throw a `TypeError`.

5. Return the IDL value of type T that is a reference to the same object as V.

The result of converting an IDL value of any buffer source type to an ECMAScript value is the Object value that represents a reference to the same object that the IDL value represents.

When getting a reference to or getting a copy of the bytes held by a buffer source that is an ECMAScript `ArrayBuffer`, `DataView` or typed array object, these steps must be followed:

1. Let O be the ECMAScript object that is the buffer source.

2. Initialize arrayBuffer to O.

3. Initialize offset to 0.

4. Initialize length to 0.

5. If O has a [[ViewedArrayBuffer]] internal slot, then:

   1. Set arrayBuffer to the value of O’s [[ViewedArrayBuffer]] internal slot.

   2. Set offset to the value of O’s [[ByteOffset]] internal slot.

   3. Set length to the value of O’s [[ByteLength]] internal slot.

6. Otherwise, set length to the value of O’s [[ArrayBufferByteLength]] internal slot.

7. If IsDetachedBuffer(arrayBuffer) is true, then return the empty byte sequence.

8. Let data be the value of O’s [[ArrayBufferData]] internal slot.

9. Return a reference to or copy of (as required) the length bytes in data starting at byte offset offset.

To detach an `ArrayBuffer`, these steps must be followed:

1. Let O be the ECMAScript object that is the `ArrayBuffer`.

2. Perform ! DetachArrayBuffer(O).

#### 3.2.25. Frozen arrays — FrozenArray<T>

Values of frozen array types are represented by frozen ECMAScript Array object references.

An ECMAScript value V is converted to an IDL FrozenArray<T> value by running the following algorithm:

1. Let values be the result of converting V to IDL type sequence<T>.

2. Return the result of creating a frozen array from values.

To create a frozen array from a sequence of values of type T, follow these steps:

1. Let array be the result of converting the sequence of values of type T to an ECMAScript value.

2. Perform SetIntegrityLevel(array, "`frozen`").

3. Return array.

The result of converting an IDL FrozenArray<T> value to an ECMAScript value is the Object value that represents a reference to the same object that the IDL FrozenArray<T> represents.

##### 3.2.25.1. Creating a frozen array from an iterable

To create an IDL value of type FrozenArray<T> given an iterable iterable and an iterator getter method, perform the following steps:

1. Let values be the result of creating a sequence of type sequence<T> from iterable and method.

2. Return the result of creating a frozen array from values.

### 3.3. ECMAScript-specific extended attributes

This section defines a number of extended attributes whose presence affects only the ECMAScript binding.

#### 3.3.1. [AllowShared]

If the [`AllowShared`] extended attribute appears on one of the buffer source types, it creates a new IDL type that allows the buffer source type to be backed by an ECMAScript `SharedArrayBuffer`, instead of only by a non-shared `ArrayBuffer`.

The [`AllowShared`] extended attribute must take no arguments.

A type that is not a buffer source type must not be associated with the [`AllowShared`] extended attribute.

See the rules for converting ECMAScript values to IDL buffer source types in § 3.2.24 Buffer source types for the specific requirements that the use of [`AllowShared`] entails.

In the following IDL fragment, one operation’s argument uses the [`AllowShared`] extended attribute, while the other does not:

    [Exposed=Window]
    interface RenderingContext {
      void readPixels(long width, long height, BufferSource pixels);
      void readPixelsShared(long width, long height, [AllowShared] BufferSource pixels);
    };

With this definition, a call to `readPixels` with an `SharedArrayBuffer` instance, or any typed array or `DataView` backed by one, will throw a `TypeError` exception. In contrast, a call to `readPixelsShared` will allow such objects as input.

#### 3.3.2. [Clamp]

If the [`Clamp`] extended attribute appears on one of the integer types, it creates a new IDL type such that that when an ECMAScript Number is converted to the IDL type, out-of-range values will be clamped to the range of valid values, rather than using the operators that use a modulo operation (ToInt32, ToUint32, etc.).

The [`Clamp`] extended attribute must take no arguments.

A type annotated with the [`Clamp`] extended attribute must not appear in a read only attribute. A type must not be associated with both the [`Clamp`] and [`EnforceRange`] extended attributes. A type that is not an integer type must not be associated with the [`Clamp`] extended attribute.

See the rules for converting ECMAScript values to the various IDL integer types in § 3.2.4 Integer types for the specific requirements that the use of [`Clamp`] entails.

In the following IDL fragment, two operations are declared that take three `octet` arguments; one uses the [`Clamp`] extended attribute on all three arguments, while the other does not:

    [Exposed=Window]
    interface GraphicsContext {
      void setColor(octet red, octet green, octet blue);
      void setColorClamped([Clamp] octet red, [Clamp] octet green, [Clamp] octet blue);
    };

A call to `setColorClamped` with Number values that are out of range for an `octet` are clamped to the range [0, 255].

    // Get an instance of GraphicsContext.
    var context = getGraphicsContext();

    // Calling the non-[Clamp] version uses ToUint8 to coerce the Numbers to octets.
    // This is equivalent to calling setColor(255, 255, 1).
    context.setColor(-1, 255, 257);

    // Call setColorClamped with some out of range values.
    // This is equivalent to calling setColorClamped(0, 255, 255).
    context.setColorClamped(-1, 255, 257);

#### 3.3.3. [Default]

If the [`Default`] extended attribute appears on a regular operation, then it indicates that steps described in the corresponding default operation must be carried out when the operation is invoked.

The [`Default`] extended attribute must take no arguments.

The [`Default`] extended attribute must not be used on anything other than a regular operation for which a corresponding default operation has been defined.

As an example, the [`Default`] extended attribute is suitable for use on `toJSON` regular operations:

    [Exposed=Window]
    interface Animal {
      attribute DOMString name;
      attribute unsigned short age;
      [Default] object toJSON();
    };

    [Exposed=Window]
    interface Human : Animal {
      attribute Dog? pet;
      [Default] object toJSON();
    };

    [Exposed=Window]
    interface Dog : Animal {
      attribute DOMString? breed;
    };

In the ECMAScript language binding, there would exist a `toJSON()` method on `Animal`, `Human`, and (via inheritance) `Dog` objects:

    // Get an instance of Human.
    var alice = getHuman();

    // Evaluates to an object like this (notice how "pet" still holds
    // an instance of Dog at this point):
    //
    // {
    //   name: "Alice",
    //   age: 59,
    //   pet: Dog
    // }
    alice.toJSON();

    // Evaluates to an object like this (notice how "breed" is absent,
    // as the Dog interface doesn’t declare a default toJSON operation):
    //
    // {
    //   name: "Tramp",
    //   age: 6
    // }
    alice.pet.toJSON();

    // Evaluates to a string like this:
    // '{"name":"Alice","age":59,"pet":{"name":"Tramp","age":6}}'
    JSON.stringify(alice);

#### 3.3.4. [EnforceRange]

If the [`EnforceRange`] extended attribute appears on one of the integer types, it creates a new IDL type such that that when an ECMAScript Number is converted to the IDL type, out-of-range values will cause an exception to be thrown, rather than being converted to a valid value using using the operators that use a modulo operation (ToInt32, ToUint32, etc.). The Number will be rounded toward zero before being checked against its range.

The [`EnforceRange`] extended attribute must take no arguments.

A type annotated with the [`EnforceRange`] extended attribute must not appear in a read only attribute. A type must not be associated with both the [`Clamp`] and [`EnforceRange`] extended attributes. A type that is not an integer type must not be associated with the [`EnforceRange`] extended attribute.

See the rules for converting ECMAScript values to the various IDL integer types in § 3.2 ECMAScript type mapping for the specific requirements that the use of [`EnforceRange`] entails.

In the following IDL fragment, two operations are declared that take three `octet` arguments; one uses the [`EnforceRange`] extended attribute on all three arguments, while the other does not:

    [Exposed=Window]
    interface GraphicsContext {
      void setColor(octet red, octet green, octet blue);
      void setColorEnforcedRange([EnforceRange] octet red, [EnforceRange] octet green, [EnforceRange] octet blue);
    };

In an ECMAScript implementation of the IDL, a call to setColorEnforcedRange with Number values that are out of range for an `octet` will result in an exception being thrown.

    // Get an instance of GraphicsContext.
    var context = getGraphicsContext();

    // Calling the non-[EnforceRange] version uses ToUint8 to coerce the Numbers to octets.
    // This is equivalent to calling setColor(255, 255, 1).
    context.setColor(-1, 255, 257);

    // When setColorEnforcedRange is called, Numbers are rounded towards zero.
    // This is equivalent to calling setColor(0, 255, 255).
    context.setColorEnforcedRange(-0.9, 255, 255.2);

    // The following will cause a TypeError to be thrown, since even after
    // rounding the first and third argument values are out of range.
    context.setColorEnforcedRange(-1, 255, 256);

#### 3.3.5. [Exposed]

When the [`Exposed`] extended attribute appears on an interface, partial interface, interface mixin, partial interface mixin, callback interface, namespace, partial namespace, or an individual interface member, interface mixin member, or namespace member, it indicates that the construct is exposed on that particular set of global interfaces.

The [`Exposed`] extended attribute must either take an identifier or take an identifier list. Each of the identifiers mentioned must be a global name and be unique. This list of identifiers is known as the construct’s own exposure set.

To get the exposure set of a construct C, run the following steps:

1. Assert: C is an interface, callback interface, namespace, interface member, interface mixin member, or namespace member.

2. Let H be C’s host interface if C is an interface mixin member, or null otherwise.

3. If C is an interface member, interface mixin member, or namespace member, then:

   1. If the [`Exposed`] extended attribute is specified on C, then:

      1. If H is set, return the intersection of C’s own exposure set and H’s exposure set.

      2. Otherwise, return C’s own exposure set.

   2. Otherwise, set C to be the interface, partial interface, interface mixin, partial interface mixin, namespace, or partial namespace C is declared on.

4. If C is a partial interface, partial interface mixin, or partial namespace, then:

   1. If the [`Exposed`] extended attribute is specified on C, then:

      1. If H is set, return the intersection of C’s own exposure set and H’s exposure set.

      2. Otherwise, return C’s own exposure set.

   2. Otherwise, set C to be the original interface, interface mixin, or namespace definition of C.

5. If C is an interface mixin, then:

   1. If the [`Exposed`] extended attribute is specified on C, then return the intersection of C’s own exposure set and H’s exposure set.

   2. Otherwise, set C to H.

6. Assert: C is an interface, callback interface or namespace.

7. Assert: The [`Exposed`] extended attribute is specified on C.

8. Return C’s own exposure set.

If [`Exposed`] appears on an overloaded operation, then it must appear identically on all overloads.

The [`Exposed`] extended attribute must not be specified both on an interface member, interface mixin member, or namespace member, and on the partial interface, partial interface mixin, or partial namespace definition the member is declared on.

Note: This is because adding an [`Exposed`] extended attribute on a partial interface, partial interface mixin, or partial namespace is shorthand for annotating each of its members.

If [`Exposed`] appears on a partial interface or partial namespace, then the partial’s own exposure set must be a subset of the exposure set of the partial’s original interface or namespace.

If [`Exposed`] appears on an interface or namespace member, then the member's exposure set must be a subset of the exposure set of the interface or namespace it is a member of.

If [`Exposed`] appears both on a partial interface mixin and its original interface mixin, then the partial interface mixin's own exposure set must be a subset of the interface mixin's own exposure set.

If [`Exposed`] appears both on an interface mixin member and the interface mixin it is a member of, then the interface mixin members's own exposure set must be a subset of the interface mixin's own exposure set.

If an interface X inherits from another interface Y then the exposure set of X must be a subset of the exposure set of Y.

Note: As an interface mixin can be included by different interfaces, the exposure set of its members is a function of the interface that includes them. If the interface mixin member, partial interface mixin, or interface mixin is annotated with an [`Exposed`] extended attribute, then the interface mixin member's exposure set is the intersection of the relevant construct’s own exposure set with the the host interface's exposure set. Otherwise, it is the host interface's exposure set.

An interface, callback interface, namespace, or member construct is exposed in a given Realm realm if the following steps return true:

1. If realm.[[GlobalObject]] does not implement an interface that is in construct’s exposure set, then return false.

2. If construct is available in both secure and non-secure contexts, then return true.

3. If the relevant settings object of realm.[[GlobalObject]] is a secure context, then return true.

4. Otherwise, return false.

Note: Since it is not possible for the relevant settings object for an ECMAScript global object to change whether it is a secure context or not over time, an implementation’s decision to create properties for an interface or interface member can be made once, at the time the initial objects are created.

See § 3.6 Interfaces, § 3.6.5 Constants, § 3.6.6 Attributes, § 3.6.7 Operations, and § 3.6.8 Common iterator behavior for the specific requirements that the use of [`Exposed`] entails.

[`Exposed`] is intended to be used to control whether interfaces, callback interfaces, namespaces, or individual interface, mixin or namespace members are available for use in workers, `Worklet`, `Window`, or any combination of the above.

The following IDL fragment shows how that might be achieved:

    [Exposed=Window, Global=Window]
    interface Window {
      // ...
    };

    // By using the same identifier Worker for both SharedWorkerGlobalScope
    // and DedicatedWorkerGlobalScope, both can be addressed in an [Exposed]
    // extended attribute at once.
    [Exposed=Worker, Global=Worker]
    interface SharedWorkerGlobalScope : WorkerGlobalScope {
      // ...
    };

    [Exposed=Worker, Global=Worker]
    interface DedicatedWorkerGlobalScope : WorkerGlobalScope {
      // ...
    };

    // Dimensions is available for use in workers and on the main thread.
    [Exposed=(Window,Worker)]
    interface Dimensions {
      constructor(double width, double height);
      readonly attribute double width;
      readonly attribute double height;
    };

    // WorkerNavigator is only available in workers.  Evaluating WorkerNavigator
    // in the global scope of a worker would give you its interface object, while
    // doing so on the main thread will give you a ReferenceError.
    [Exposed=Worker]
    interface WorkerNavigator {
      // ...
    };

    // Node is only available on the main thread.  Evaluating Node
    // in the global scope of a worker would give you a ReferenceError.
    [Exposed=Window]
    interface Node {
      // ...
    };

    // MathUtils is available for use in workers and on the main thread.
    [Exposed=(Window,Worker)]
    namespace MathUtils {
      double someComplicatedFunction(double x, double y);
    };

    // WorkerUtils is only available in workers.  Evaluating WorkerUtils
    // in the global scope of a worker would give you its namespace object, while
    // doing so on the main thread will give you a ReferenceError.
    [Exposed=Worker]
    namespace WorkerUtils {
      void setPriority(double x);
    };

    // NodeUtils is only available in the main thread.  Evaluating NodeUtils
    // in the global scope of a worker would give you a ReferenceError.
    [Exposed=Window]
    namespace NodeUtils {
      DOMString getAllText(Node node);
    };

#### 3.3.6. [Global]

If the [`Global`] extended attribute appears on an interface, it indicates that objects implementing this interface can be used as the global object in a Realm, and that the structure of the prototype chain and how properties corresponding to interface members will be reflected on the prototype objects will be different from other interfaces. Specifically:

1. Any named properties will be exposed on an object in the prototype chain – the named properties object – rather than on the object itself.

2. Interface members from the interface will correspond to properties on the object itself rather than on interface prototype objects.

Placing named properties on an object in the prototype chain is done so that variable declarations and bareword assignments will shadow the named property with a property on the global object itself.

Placing properties corresponding to interface members on the object itself will mean that common feature detection methods like the following will work:

    var indexedDB = window.indexedDB || window.webkitIndexedDB ||
                    window.mozIndexedDB || window.msIndexedDB;

    var requestAnimationFrame = window.requestAnimationFrame ||
                                window.mozRequestAnimationFrame || ...;

Because of the way variable declarations are handled in ECMAScript, the code above would result in the `window.indexedDB` and `window.requestAnimationFrame` evaluating to undefined, as the shadowing variable property would already have been created before the assignment is evaluated.

If the [`Global`] extended attributes is used on an interface, then:

- The interface must not define a named property setter.

- The interface must not define indexed property getters or setters.

- The interface must not define a constructor operation.

- The interface must not also be declared with the [`OverrideBuiltins`] extended attribute.

- The interface must not inherit from another interface with the [`OverrideBuiltins`] extended attribute.

- Any other interface must not inherit from it.

If [`Global`] is specified on a partial interface definition, then that partial interface definition must be the part of the interface definition that defines the named property getter.

The [`Global`] extended attribute must not be used on an interface that can have more than one object implementing it in the same Realm.

Note: This is because the named properties object, which exposes the named properties, is in the prototype chain, and it would not make sense for more than one object’s named properties to be exposed on an object that all of those objects inherit from.

If an interface is declared with the [`Global`] extended attribute, then there must not be more than one member across the interface with the same identifier. There also must not be more than one stringifier or more than one iterable declaration, asynchronously iterable declaration, maplike declaration or setlike declaration across those interfaces.

Note: This is because all of the members of the interface get flattened down on to the object that implements the interface.

The [`Global`] extended attribute can also be used to give a name to one or more global interfaces, which can then be referenced by the [`Exposed`] extended attribute.

The [`Global`] extended attribute must either take an identifier or take an identifier list.

The identifier argument or identifier list argument the [`Global`] extended attribute is declared with define the interface’s global names.

Note: The identifier argument list exists so that more than one global interface can be addressed with a single name in an [`Exposed`] extended attribute.

See § 3.6.4 Named properties object for the specific requirements that the use of [`Global`] entails for named properties, and § 3.6.5 Constants, § 3.6.6 Attributes and § 3.6.7 Operations for the requirements relating to the location of properties corresponding to interface members.

The `Window` interface exposes frames as properties on the `Window` object. Since the `Window` object also serves as the ECMAScript global object, variable declarations or assignments to the named properties will result in them being replaced by the new value. Variable declarations for attributes will not create a property that replaces the existing one.

    [Exposed=Window, Global]
    interface Window {
      getter any (DOMString name);
      attribute DOMString name;
      // ...
    };

The following HTML document illustrates how the named properties on the `Window` object can be shadowed, and how the property for an attribute will not be replaced when declaring a variable of the same name:

    <!DOCTYPE html>
    <title>Variable declarations and assignments on Window</title>
    <iframe name=abc></iframe>
    <!-- Shadowing named properties -->
    <script>
      window.abc;    // Evaluates to the iframe’s Window object.
      abc = 1;       // Shadows the named property.
      window.abc;    // Evaluates to 1.
    </script>

    <!-- Preserving properties for IDL attributes -->
    <script>
      Window.prototype.def = 2;         // Places a property on the prototype.
      window.hasOwnProperty("length");  // Evaluates to true.
      length;                           // Evaluates to 1.
      def;                              // Evaluates to 2.
    </script>
    <script>
      var length;                       // Variable declaration leaves existing property.
      length;                           // Evaluates to 1.
      var def;                          // Variable declaration creates shadowing property.
      def;                              // Evaluates to undefined.
    </script>

#### 3.3.7. [LegacyNamespace]

The [`LegacyNamespace`] extended attribute is an undesirable feature. It exists only so that legacy Web platform features can be specified. It should not be used in specifications unless required to specify the behavior of legacy APIs, or for consistency with these APIs. Instead, interface names can be formed with a naming convention of starting with a particular prefix for a set of interfaces, as part of the identifier, rather than using a namespace. Editors who wish to use this feature are strongly advised to discuss this by filing an issue before proceeding.

If the [`LegacyNamespace`] extended attribute appears on an interface, it indicates that the interface object for this interface will not be created as a property of the global object, but rather as a property of the namespace identified by the argument to the extended attribute.

The [`LegacyNamespace`] extended attribute take an identifier. This identifier must be the identifier of a namespace.

The [`LegacyNamespace`] and [`NoInterfaceObject`] extended attributes must not be specified on the same interface.

See § 3.11.1 Namespace object for details on how an interface is exposed on a namespace.

The following IDL fragment defines a namespace and an interface which uses [`LegacyNamespace`] to be defined inside of it.

    namespace Foo { };

    [LegacyNamespace=Foo]
    interface Bar {
      constructor();
    };

In an ECMAScript implementation of the above namespace and interface, the constructor Bar can be accessed as follows:

    var instance = new Foo.Bar();

#### 3.3.8. [LegacyUnenumerableNamedProperties]

The [`LegacyUnenumerableNamedProperties`] extended attribute is an undesirable feature. It exists only so that legacy Web platform features can be specified. It should not be used in specifications unless required to specify the behavior of legacy APIs, or for consistency with these APIs. Editors who wish to use this feature are strongly advised to discuss this by filing an issue before proceeding.

The [`LegacyUnenumerableNamedProperties`] extended attribute appears on the following interfaces: `HTMLCollection`, `NamedNodeMap`, `HTMLAllCollection`, `HTMLFormElement`, `PluginArray`, `MimeTypeArray`, `Plugin`, and `Window`. [DOM] [HTML]

If the [`LegacyUnenumerableNamedProperties`] extended attribute appears on a interface that supports named properties, it indicates that all the interface’s named properties are unenumerable.

The [`LegacyUnenumerableNamedProperties`] extended attribute must take no arguments and must not appear on an interface that does not define a named property getter.

If the [`LegacyUnenumerableNamedProperties`] extended attribute is specified on an interface, then it applies to all its derived interfaces and must not be specified on any of them.

See § 3.8.1 [[GetOwnProperty]] for the specific requirements that the use of [`LegacyUnenumerableNamedProperties`] entails.

#### 3.3.9. [LegacyWindowAlias]

The [`LegacyWindowAlias`] extended attribute is an undesirable feature. It exists only so that legacy Web platform features can be specified. It should not be used in specifications unless required to specify the behavior of legacy APIs, or for consistency with these APIs. Editors who wish to use this feature are strongly advised to discuss this by filing an issue before proceeding.

The [`LegacyWindowAlias`] extended attribute appears on the following interfaces: `DOMPoint`, `DOMRect`, `DOMMatrix`, and `URL`. [GEOMETRY] [URL]

If the [`LegacyWindowAlias`] extended attribute appears on an interface, it indicates that the `Window` interface will have a property for each identifier mentioned in the extended attribute, whose value is the interface object for the interface.

The [`LegacyWindowAlias`] extended attribute must either take an identifier or take an identifier list. The identifiers that occur after the “=” are the [`LegacyWindowAlias`]'s identifiers.

Each of the identifiers of [`LegacyWindowAlias`] must not be the same as one used by a [`LegacyWindowAlias`] extended attribute on this interface or another interface, must not be the same as the identifier used by a [`NamedConstructor`] extended attribute on this interface or another interface, must not be the same as an identifier of an interface that has an interface object, and must not be one of the reserved identifiers.

The [`LegacyWindowAlias`] and [`NoInterfaceObject`] extended attributes must not be specified on the same interface.

The [`LegacyWindowAlias`] and [`LegacyNamespace`] extended attributes must not be specified on the same interface.

The [`LegacyWindowAlias`] extended attribute must not be specified on an interface that does not include the `Window` interface in its exposure set.

An interface must not have more than one [`LegacyWindowAlias`] extended attributes specified.

See § 3.6 Interfaces for details on how legacy window aliases are to be implemented.

The following IDL defines an interface that uses the [`LegacyWindowAlias`] extended attribute.

    [Exposed=Window,
     LegacyWindowAlias=WebKitCSSMatrix]
    interface DOMMatrix : DOMMatrixReadOnly {
      // ...
    };

An ECMAScript implementation that supports this interface will expose two properties on the `Window` object with the same value and the same characteristics; one for exposing the interface object normally, and one for exposing it with a legacy name.

    WebKitCSSMatrix === DOMMatrix;     // Evaluates to true.

    var m = new WebKitCSSMatrix();     // Creates a new object that
                                       // implements DOMMatrix.

    m.constructor === DOMMatrix;       // Evaluates to true.
    m.constructor === WebKitCSSMatrix; // Evaluates to true.
    {}.toString.call(m);               // Evaluates to '[object DOMMatrix]'.

#### 3.3.10. [LenientSetter]

Specifications should not use [`LenientSetter`] unless required for compatibility reasons. Pages have been observed where authors have attempted to polyfill an IDL attribute by assigning to the property, but have accidentally done so even if the property exists. In strict mode, this would cause an exception to be thrown, potentially breaking page. Without [`LenientSetter`], this could prevent a browser from shipping the feature. Editors who wish to use this feature are strongly advised to discuss this by filing an issue before proceeding.

The [`LenientSetter`] extended attribute appears on the `fullscreenEnabled` and `fullscreenEnabled` attributes of the `Document` interface, and on the `fullscreenElement` attribute of the `DocumentOrShadowRoot` interface mixin. [FULLSCREEN]

If the [`LenientSetter`] extended attribute appears on a read only regular attribute, it indicates that a no-op setter will be generated for the attribute’s accessor property. This results in erroneous assignments to the property in strict mode to be ignored rather than causing an exception to be thrown.

The [`LenientSetter`] extended attribute must take no arguments. It must not be used on anything other than a read only regular attribute.

An attribute with the [`LenientSetter`] extended attribute must not also be declared with the [`PutForwards`] or [`Replaceable`] extended attributes.

The [`LenientSetter`] extended attribute must not be used on an attribute declared on a namespace.

See the Attributes section for how [`LenientSetter`] is to be implemented.

The following IDL fragment defines an interface that uses the [`LenientSetter`] extended attribute.

    [Exposed=Window]
    interface Example {
      [LenientSetter] readonly attribute DOMString x;
      readonly attribute DOMString y;
    };

An ECMAScript implementation that supports this interface will have a setter on the accessor property that correspond to x, which allows any assignment to be ignored in strict mode.

    "use strict";

    var example = getExample();  // Get an instance of Example.

    // Fine; while we are in strict mode, there is a setter that is a no-op.
    example.x = 1;

    // Throws a TypeError, since we are in strict mode and there is no setter.
    example.y = 1;

#### 3.3.11. [LenientThis]

Specifications should not use [`LenientThis`] unless required for compatibility reasons. Editors who wish to use this feature are strongly advised to discuss this by filing an issue before proceeding.

The [`LenientThis`] extended attribute appears on the `onreadystatechange`, `onmouseenter`, and `onmouseleave` attributes of the `Document` interface. [HTML]

If the [`LenientThis`] extended attribute appears on a regular attribute, it indicates that invocations of the attribute’s getter or setter with a this value that is not an object that implements the interface on which the attribute appears will be ignored.

The [`LenientThis`] extended attribute must take no arguments. It must not be used on a static attribute.

The [`LenientThis`] extended attribute must not be used on an attribute declared on a namespace.

See the Attributes section for how [`LenientThis`] is to be implemented.

The following IDL fragment defines an interface that uses the [`LenientThis`] extended attribute.

    [Exposed=Window]
    interface Example {
      [LenientThis] attribute DOMString x;
      attribute DOMString y;
    };

An ECMAScript implementation that supports this interface will allow the getter and setter of the accessor property that corresponds to x to be invoked with something other than an `Example` object.

    var example = getExample();  // Get an instance of Example.
    var obj = { };

    // Fine.
    example.x;

    // Ignored, since the this value is not an Example object and [LenientThis] is used.
    Object.getOwnPropertyDescriptor(Example.prototype, "x").get.call(obj);

    // Also ignored, since Example.prototype is not an Example object and [LenientThis] is used.
    Example.prototype.x;

    // Throws a TypeError, since Example.prototype is not an Example object.
    Example.prototype.y;

#### 3.3.12. [NamedConstructor]

[`NamedConstructor`] extended attribute is an undesirable feature. It exists only so that legacy Web platform features can be specified. It should not be used in specifications unless required to specify the behavior of legacy APIs, or for consistency with these APIs. Editors who wish to use this feature are strongly advised to discuss this by filing an issue before proceeding.

The [`NamedConstructor`] extended attribute appears on the following interfaces: `HTMLAudioElement`, `HTMLOptionElement`, and `HTMLImageElement`. [HTML]

If the [`NamedConstructor`] extended attribute appears on an interface, it indicates that the ECMAScript global object will have a property with the specified name whose value is a constructor that can create objects that implement the interface. Multiple [`NamedConstructor`] extended attributes may appear on a given interface.

The [`NamedConstructor`] extended attribute must either take an identifier or take a named argument list. The identifier that occurs directly after the “=” is the [`NamedConstructor`]'s identifier. The first form, `[NamedConstructor=identifier]`, has the same meaning as using an empty argument list, `[NamedConstructor=identifier()]`. For each [`NamedConstructor`] extended attribute on the interface, there will be a way to construct an object that implements the interface by passing the specified arguments to the constructor that is the value of the aforementioned property.

The identifier used for the named constructor must not be the same as that used by a [`NamedConstructor`] extended attribute on another interface, must not be the same as an identifier used by a [`LegacyWindowAlias`] extended attribute on this interface or another interface, must not be the same as an identifier of an interface that has an interface object, and must not be one of the reserved identifiers.

The [`NamedConstructor`] and [`Global`] extended attributes must not be specified on the same interface.

See § 3.6.2 Named constructors for details on how named constructors are to be implemented.

The following IDL defines an interface that uses the [`NamedConstructor`] extended attribute.

    [Exposed=Window,
     NamedConstructor=Audio,
     NamedConstructor=Audio(DOMString src)]
    interface HTMLAudioElement : HTMLMediaElement {
      // ...
    };

An ECMAScript implementation that supports this interface will allow the construction of `HTMLAudioElement` objects using the `Audio` constructor.

    typeof Audio;                   // Evaluates to 'function'.

    var a1 = new Audio();           // Creates a new object that implements
                                    // HTMLAudioElement, using the zero-argument
                                    // constructor.

    var a2 = new Audio('a.flac');   // Creates an HTMLAudioElement using the
                                    // one-argument constructor.

#### 3.3.13. [NewObject]

If the [`NewObject`] extended attribute appears on a regular or static operation, then it indicates that when calling the operation, a reference to a newly created object must always be returned.

The [`NewObject`] extended attribute must take no arguments.

The [`NewObject`] extended attribute must not be used on anything other than a regular or static operation whose return type is an interface type or a promise type.

As an example, this extended attribute is suitable for use on the `createElement()` operation on the `Document` interface, since a new object should always be returned when it is called. [DOM]

    [Exposed=Window]
    interface Document : Node {
      [NewObject] Element createElement(DOMString localName);
      // ...
    };

#### 3.3.14. [NoInterfaceObject]

The [`NoInterfaceObject`] extended attribute is an undesirable feature. It exists only so that legacy Web platform features can be specified. It should not be used in specifications unless required to specify the behavior of legacy APIs, or for consistency with these APIs. Editors who wish to use this feature are strongly advised to discuss this by filing an issue before proceeding.

The [`NoInterfaceObject`] extended attribute appears on the following interfaces:

`Geolocation`, `Coordinates`, `Position`, `PositionError`, `DeviceAcceleration`, `DeviceRotationRate`, `ConstrainablePattern`, `WEBGL_compressed_texture_astc`, `WEBGL_compressed_texture_s3tc_srgb`, `WEBGL_draw_buffers`, `WEBGL_lose_context`, `ANGLE_instanced_arrays`, `EXT_blend_minmax`, `EXT_color_buffer_float`, `EXT_disjoint_timer_query`, `OES_standard_derivatives`, and `OES_vertex_array_object`. [GEOLOCATION-API] [ORIENTATION-EVENT] [MEDIACAPTURE-STREAMS] (various [WEBGL] extension specifications)

Note: Previously, the [`NoInterfaceObject`] extended attribute could also be used to annotate interfaces, which other interfaces could then implement (using the defunct "implements statement") as if they were mixins. There is now dedicated syntax to cater for this use case in the form of interface mixins and includes statements. Using the [`NoInterfaceObject`] extended attribute for this purpose is no longer supported. Specifications which still do are strongly encouraged to migrate to interface mixins as soon as possible.

If the [`NoInterfaceObject`] extended attribute appears on an interface, it indicates that an interface object will not exist for the interface in the ECMAScript binding.

The [`NoInterfaceObject`] extended attribute must take no arguments.

The [`NoInterfaceObject`] extended attribute must not be specified on an interface that has any constructors or static operations defined on it.

Note: Combining the [`NoInterfaceObject`] and [`NamedConstructor`] extended attribute is not forbidden, however.

An interface that does not have the [`NoInterfaceObject`] extended attribute specified must not inherit from an interface that has the [`NoInterfaceObject`] extended attribute specified.

See § 3.6 Interfaces for the specific requirements that the use of [`NoInterfaceObject`] entails.

The following IDL fragment defines two interfaces, one whose interface object is exposed on the ECMAScript global object, and one whose isn’t:

    [Exposed=Window]
    interface Storage {
      void addEntry(unsigned long key, any value);
    };

    [Exposed=Window,
     NoInterfaceObject]
    interface Query {
      any lookupEntry(unsigned long key);
    };

An ECMAScript implementation of the above IDL would allow manipulation of `Storage`’s prototype, but not `Query`’s.

    typeof Storage;                        // evaluates to "object"

    // Add some tracing alert() call to Storage.addEntry.
    var fn = Storage.prototype.addEntry;
    Storage.prototype.addEntry = function(key, value) {
      alert('Calling addEntry()');
      return fn.call(this, key, value);
    };

    typeof Query;                          // evaluates to "undefined"
    var fn = Query.prototype.lookupEntry;  // exception, Query isn’t defined

#### 3.3.15. [OverrideBuiltins]

The [`OverrideBuiltins`] extended attribute is an undesirable feature. It exists only so that legacy Web platform features can be specified. It should not be used in specifications unless required to specify the behavior of legacy APIs, or for consistency with these APIs. Editors who wish to use this feature are strongly advised to discuss this by filing an issue before proceeding.

The [`OverrideBuiltins`] extended attribute appears on the `DOMStringMap`, `Document`, and `HTMLFormElement` interfaces. [HTML]

If the [`OverrideBuiltins`] extended attribute appears on an interface, it indicates that for a legacy platform object implementing the interface, properties corresponding to all of the object’s supported property names will appear to be on the object, regardless of what other properties exist on the object or its prototype chain. This means that named properties will always shadow any properties that would otherwise appear on the object. This is in contrast to the usual behavior, which is for named properties to be exposed only if there is no property with the same name on the object itself or somewhere on its prototype chain.

The [`OverrideBuiltins`] extended attribute must take no arguments and must not appear on an interface that does not define a named property getter or that also is declared with the [`Global`] extended attribute. If the extended attribute is specified on a partial interface definition, then that partial interface definition must be the part of the interface definition that defines the named property getter.

If the [`OverrideBuiltins`] extended attribute is specified on a partial interface definition, it is considered to appear on the interface itself.

See § 3.8 Legacy platform objects and § 3.8.3 [[DefineOwnProperty]] for the specific requirements that the use of [`OverrideBuiltins`] entails.

The following IDL fragment defines two interfaces, one that has a named property getter and one that does not.

    [Exposed=Window]
    interface StringMap {
      readonly attribute unsigned long length;
      getter DOMString lookup(DOMString key);
    };

    [Exposed=Window,
     OverrideBuiltins]
    interface StringMap2 {
      readonly attribute unsigned long length;
      getter DOMString lookup(DOMString key);
    };

In an ECMAScript implementation of these two interfaces, getting certain properties on objects implementing the interfaces will result in different values:

    // Obtain an instance of StringMap.  Assume that it has "abc", "length" and
    // "toString" as supported property names.
    var map1 = getStringMap();

    // This invokes the named property getter.
    map1.abc;

    // This fetches the "length" property on the object that corresponds to the
    // length attribute.
    map1.length;

    // This fetches the "toString" property from the object’s prototype chain.
    map1.toString;

    // Obtain an instance of StringMap2.  Assume that it also has "abc", "length"
    // and "toString" as supported property names.
    var map2 = getStringMap2();

    // This invokes the named property getter.
    map2.abc;

    // This also invokes the named property getter, despite the fact that the "length"
    // property on the object corresponds to the length attribute.
    map2.length;

    // This too invokes the named property getter, despite the fact that "toString" is
    // a property in map2’s prototype chain.
    map2.toString;

#### 3.3.16. [PutForwards]

If the [`PutForwards`] extended attribute appears on a read only regular attribute declaration whose type is an interface type, it indicates that assigning to the attribute will have specific behavior. Namely, the assignment is “forwarded” to the attribute (specified by the extended attribute argument) on the object that is currently referenced by the attribute being assigned to.

The [`PutForwards`] extended attribute must take an identifier. Assuming that:

- A is the attribute on which the [`PutForwards`] extended attribute appears,

- I is the interface on which A is declared,

- J is the interface type that A is declared to be of, and

- N is the identifier argument of the extended attribute,

then there must be another attribute B declared on J whose identifier is N. Assignment of a value to the attribute A on an object implementing I will result in that value being assigned to attribute B of the object that A references, instead.

Note that [`PutForwards`]-annotated attributes can be chained. That is, an attribute with the [`PutForwards`] extended attribute can refer to an attribute that itself has that extended attribute. There must not exist a cycle in a chain of forwarded assignments. A cycle exists if, when following the chain of forwarded assignments, a particular attribute on an interface is encountered more than once.

An attribute with the [`PutForwards`] extended attribute must not also be declared with the [`LenientSetter`] or [`Replaceable`] extended attributes.

The [`PutForwards`] extended attribute must not be used on an attribute that is not read only.

The [`PutForwards`] extended attribute must not be used on a static attribute.

The [`PutForwards`] extended attribute must not be used on an attribute declared on a namespace.

See the Attributes section for how [`PutForwards`] is to be implemented.

The following IDL fragment defines interfaces for names and people. The [`PutForwards`] extended attribute is used on the `name` attribute of the `Person` interface to indicate that assignments to that attribute result in assignments to the `full` attribute of the `Person` object:

    [Exposed=Window]
    interface Name {
      attribute DOMString full;
      attribute DOMString family;
      attribute DOMString given;
    };

    [Exposed=Window]
    interface Person {
      [PutForwards=full] readonly attribute Name name;
      attribute unsigned short age;
    };

In the ECMAScript binding, this would allow assignments to the `name` property:

    var p = getPerson();           // Obtain an instance of Person.

    p.name = 'John Citizen';       // This statement...
    p.name.full = 'John Citizen';  // ...has the same behavior as this one.

#### 3.3.17. [Replaceable]

If the [`Replaceable`] extended attribute appears on a read only regular attribute, it indicates that setting the corresponding property on the platform object will result in an own property with the same name being created on the object which has the value being assigned. This property will shadow the accessor property corresponding to the attribute, which exists on the interface prototype object.

The [`Replaceable`] extended attribute must take no arguments.

An attribute with the [`Replaceable`] extended attribute must not also be declared with the [`LenientSetter`] or [`PutForwards`] extended attributes.

The [`Replaceable`] extended attribute must not be used on an attribute that is not read only.

The [`Replaceable`] extended attribute must not be used on a static attribute.

The [`Replaceable`] extended attribute must not be used on an attribute declared on a namespace.

See § 3.6.6 Attributes for the specific requirements that the use of [`Replaceable`] entails.

The following IDL fragment defines an interface with an operation that increments a counter, and an attribute that exposes the counter’s value, which is initially 0:

    [Exposed=Window]
    interface Counter {
      [Replaceable] readonly attribute unsigned long value;
      void increment();
    };

Assigning to the `value` property on a platform object implementing `Counter` will shadow the property that corresponds to the attribute:

    var counter = getCounter();                              // Obtain an instance of Counter.
    counter.value;                                           // Evaluates to 0.

    counter.hasOwnProperty("value");                         // Evaluates to false.
    Object.getPrototypeOf(counter).hasOwnProperty("value");  // Evaluates to true.

    counter.increment();
    counter.increment();
    counter.value;                                           // Evaluates to 2.

    counter.value = 'a';                                     // Shadows the property with one that is unrelated
                                                             // to Counter::value.

    counter.hasOwnProperty("value");                         // Evaluates to true.

    counter.increment();
    counter.value;                                           // Evaluates to 'a'.

    delete counter.value;                                    // Reveals the original property.
    counter.value;                                           // Evaluates to 3.

#### 3.3.18. [SameObject]

If the [`SameObject`] extended attribute appears on a read only attribute, then it indicates that when getting the value of the attribute on a given object, the same value must always be returned.

The [`SameObject`] extended attribute must take no arguments.

The [`SameObject`] extended attribute must not be used on anything other than a read only attribute whose type is an interface type or `object`.

As an example, this extended attribute is suitable for use on the `implementation` attribute on the `Document` interface since the same object is always returned for a given `Document` object. [DOM]

    [Exposed=Window]
    interface Document : Node {
      [SameObject] readonly attribute DOMImplementation implementation;
      // ...
    };

#### 3.3.19. [SecureContext]

If the [`SecureContext`] extended attribute appears on an interface, partial interface, interface mixin, partial interface mixin, callback interface, namespace, partial namespace, interface member, interface mixin member, or namespace member, it indicates that the construct is exposed only within a secure context. The [`SecureContext`] extended attribute must not be used on any other construct.

The [`SecureContext`] extended attribute must take no arguments.

A construct is available in both secure and non-secure contexts if it is not available only in secure contexts (i.e., if no [`SecureContext`] extended attribute applies to it).

To check if a construct C is available only in secure contexts, run the following steps:

1. Assert: C is an interface, callback interface, namespace, interface member, interface mixin member, or namespace member.

2. Let H be C’s host interface if C is an interface mixin member, or null otherwise.

3. If C is an interface member, interface mixin member, or namespace member, then:

   1. If the [`SecureContext`] extended attribute is specified on C, then return true.

   2. Otherwise, set C to be the interface, partial interface, interface mixin, partial interface mixin, namespace, or partial namespace C is declared on.

4. If C is a partial interface, partial interface mixin, or partial namespace, then:

   1. If the [`SecureContext`] extended attribute is specified on C, then return true.

   2. Otherwise, set C to be the original interface, interface mixin, or namespace definition of C.

5. If C is an interface mixin, then:

   1. If the [`SecureContext`] extended attribute is specified on C, then return true.

   2. Otherwise, set C to H.

6. Assert: C is an interface, callback interface or namespace.

7. If the [`SecureContext`] extended attribute is specified on C, then return true.

8. Otherwise, return false.

Note: Whether a construct is available only in secure contexts influences whether it is exposed in a given Realm.

If [`SecureContext`] appears on an overloaded operation, then it must appear on all overloads.

The [`SecureContext`] extended attribute must not be specified both on

- an interface member and its interface or partial interface;

- an interface mixin member and its interface mixin or partial interface mixin;

- a namespace member and its namespace or partial namespace.

Note: This is because adding the [`SecureContext`] extended attribute on a member when its containing definition is also annotated with the [`SecureContext`] extended attribute does not further restrict the exposure of the member.

An interface without the [`SecureContext`] extended attribute must not inherit from another interface that does specify [`SecureContext`].

The following IDL fragment defines an interface with one operation that is executable from all contexts, and two which are executable only from secure contexts.

    [Exposed=Window]
    interface PowerfulFeature {
      // This call will succeed in all contexts.
      Promise <Result> calculateNotSoSecretResult();

      // This operation will not be exposed to a non-secure context. In such a context,
      // there will be no "calculateSecretResult" property on PowerfulFeature.prototype.
      [SecureContext] Promise<Result> calculateSecretResult();

      // The same applies here: the attribute will not be exposed to a non-secure context,
      // and in a non-secure context there will be no "secretBoolean" property on
      // PowerfulFeature.prototype.
      [SecureContext] readonly attribute boolean secretBoolean;
    };

    // HeartbeatSensor will not be exposed in a non-secure context, nor will its members.
    // In such a context, there will be no "HeartbeatSensor" property on Window.
    [SecureContext]
    interface HeartbeatSensor {
      Promise<float> getHeartbeatsPerMinute();
    };

    // The interface mixin members defined below will never be exposed in a non-secure context,
    // regardless of whether the interface that includes them is.
    // In a non-secure context, there will be no "snap" property on
    // PowerfulFeature.prototype.
    [SecureContext]
    interface mixin Snapshotable {
      Promise<boolean> snap();
    };
    PowerfulFeature includes Snapshotable;

    // On the other hand, the following interface mixin members will be exposed
    // to a non-secure context when included by a host interface
    // that doesn’t have the [SecureContext] extended attribute.
    // In a non-secure context, there will be a "log" property on
    // PowerfulFeatures.prototype.
    interface mixin Loggable {
      Promise<boolean> log();
    };
    PowerfulFeatures includes Loggable;

#### 3.3.20. [TreatNonObjectAsNull]

The [`TreatNonObjectAsNull`] extended attribute is an undesirable feature. It exists only so that legacy Web platform features can be specified. It should not be used in specifications unless required to specify the behavior of legacy APIs, or for consistency with these APIs. Editors who wish to use this feature are strongly advised to discuss this by filing an issue before proceeding.

The [`TreatNonObjectAsNull`] extended attribute appears on the callback functions `EventHandlerNonNull`, `OnBeforeUnloadEventHandlerNonNull`, and `OnErrorEventHandlerNonNull` used as the type of event handler IDL attributes such as `onclick` and `onerror`. [HTML]

If the [`TreatNonObjectAsNull`] extended attribute appears on a callback function, then it indicates that any value assigned to an attribute whose type is a nullable callback function that is not an object will be converted to the null value.

See § 3.2.19 Nullable types — T? for the specific requirements that the use of [`TreatNonObjectAsNull`] entails.

The following IDL fragment defines an interface that has one attribute whose type is a [`TreatNonObjectAsNull`]-annotated callback function and another whose type is a callback function without the extended attribute:

    callback OccurrenceHandler = void (DOMString details);

    [TreatNonObjectAsNull]
    callback ErrorHandler = void (DOMString details);

    [Exposed=Window]
    interface Manager {
      attribute OccurrenceHandler? handler1;
      attribute ErrorHandler? handler2;
    };

In an ECMAScript implementation, assigning a value that is not an object (such as a Number value) to handler1 will have different behavior from that when assigning to handler2:

    var manager = getManager();  // Get an instance of Manager.

    manager.handler1 = function() { };
    manager.handler1;            // Evaluates to the function.

    try {
      manager.handler1 = 123;    // Throws a TypeError.
    } catch (e) {
    }

    manager.handler2 = function() { };
    manager.handler2;            // Evaluates to the function.

    manager.handler2 = 123;
    manager.handler2;            // Evaluates to null.

#### 3.3.21. [TreatNullAs]

The [`TreatNullAs`] extended attribute is an undesirable feature. It exists only so that legacy Web platform features can be specified. It should not be used in specifications unless required to specify the behavior of legacy APIs, or for consistency with these APIs. Editors who wish to use this feature are strongly advised to discuss this by filing an issue before proceeding.

If the [`TreatNullAs`] extended attribute appears on the `DOMString` type, it creates a new IDL type such that that when an ECMAScript null is converted to the IDL type, it will be handled differently from its default handling. Instead of being stringified to "`null`", which is the default, it will be converted to the empty string.

The [`TreatNullAs`] extended attribute must take the identifier `EmptyString`.

The [`TreatNullAs`] extended attribute must not be associated with a type that is not `DOMString`.

Note: This means that even `DOMString?` must not use [`TreatNullAs`], since null is a valid value of that type.

See § 3.2.9 DOMString for the specific requirements that the use of [`TreatNullAs`] entails.

The following IDL fragment defines an interface that has one attribute whose type has the extended attribute, and one operation whose argument’s type has the extended attribute:

    [Exposed=Window]
    interface Dog {
      attribute DOMString name;
      attribute [TreatNullAs=EmptyString] DOMString owner;

      boolean isMemberOfBreed([TreatNullAs=EmptyString] DOMString breedName);
    };

An ECMAScript implementation implementing the `Dog` interface would convert a null value assigned to the `owner` property or passed as the argument to the `isMemberOfBreed` function to the empty string rather than "`null`":

    var d = getDog();         // Assume d is a platform object implementing the Dog
                              // interface.

    d.name = null;            // This assigns the string "null" to the .name
                              // property.

    d.owner = null;           // This assigns the string "" to the .owner property.

    d.isMemberOfBreed(null);  // This passes the string "" to the isMemberOfBreed
                              // function.

#### 3.3.22. [Unforgeable]

If the [`Unforgeable`] extended attribute appears on regular attributes or non-static operations, it indicates that the attribute or operation will be reflected as an ECMAScript property in a way that means its behavior cannot be modified and that performing a property lookup on the object will always result in the attribute’s property value being returned. In particular, the property will be non-configurable and will exist as an own property on the object itself rather than on its prototype.

An attribute or operation is said to be unforgeable on a given interface A if the attribute or operation is declared on A, and is annotated with the [`Unforgeable`] extended attribute.

The [`Unforgeable`] extended attribute must take no arguments.

The [`Unforgeable`] extended attribute must not appear on anything other than a regular attribute or a non-static operation. If it does appear on an operation, then it must appear on all operations with the same identifier on that interface.

The [`Unforgeable`] extended attribute must not be used on an attribute declared on a namespace.

If an attribute or operation X is unforgeable on an interface A, and A is one of the inherited interfaces of another interface B, then B must not have a regular attribute or non-static operation with the same identifier as X.

For example, the following is disallowed:

    [Exposed=Window]
    interface A1 {
      [Unforgeable] readonly attribute DOMString x;
    };
    [Exposed=Window]
    interface B1 : A1 {
      void x();  // Invalid; would be shadowed by A1’s x.
    };

    [Exposed=Window]
    interface B2 : A1 { };
    B2 includes M1;
    interface mixin M1 {
      void x();  // Invalid; B2’s copy of x would be shadowed by A1’s x.
    };

See § 3.6.6 Attributes, § 3.6.7 Operations, § 3.7 Platform objects implementing interfaces, § 3.8 Legacy platform objects and § 3.8.3 [[DefineOwnProperty]] for the specific requirements that the use of [`Unforgeable`] entails.

The following IDL fragment defines an interface that has two attributes, one of which is designated as [`Unforgeable`]:

    [Exposed=Window]
    interface System {
      [Unforgeable] readonly attribute DOMString username;
      readonly attribute long long loginTime;
    };

In an ECMAScript implementation of the interface, the username attribute will be exposed as a non-configurable property on the object itself:

    var system = getSystem();                      // Get an instance of System.

    system.hasOwnProperty("username");             // Evaluates to true.
    system.hasOwnProperty("loginTime");            // Evaluates to false.
    System.prototype.hasOwnProperty("username");   // Evaluates to false.
    System.prototype.hasOwnProperty("loginTime");  // Evaluates to true.

    try {
      // This call would fail, since the property is non-configurable.
      Object.defineProperty(system, "username", { value: "administrator" });
    } catch (e) { }

    // This defineProperty call would succeed, because System.prototype.loginTime
    // is configurable.
    var forgedLoginTime = 5;
    Object.defineProperty(System.prototype, "loginTime", { value: forgedLoginTime });

    system.loginTime;  // So this now evaluates to forgedLoginTime.

#### 3.3.23. [Unscopable]

If the [`Unscopable`] extended attribute appears on a regular attribute or regular operation, it indicates that an object that implements an interface with the given interface member will not include its property name in any object environment record with it as its base object. The result of this is that bare identifiers matching the property name will not resolve to the property in a `with` statement. This is achieved by including the property name on the interface prototype object’s `@@unscopables` property’s value.

The [`Unscopable`] extended attribute must take no arguments.

The [`Unscopable`] extended attribute must not appear on anything other than a regular attribute or regular operation.

The [`Unscopable`] extended attribute must not be used on an attribute declared on a namespace.

See § 3.6.3 Interface prototype object for the specific requirements that the use of [`Unscopable`] entails.

For example, with the following IDL:

    [Exposed=Window]
    interface Thing {
      void f();
      [Unscopable] g();
    };

the `f` property can be referenced with a bare identifier in a `with` statement but the `g` property cannot:

    var thing = getThing();  // An instance of Thing
    with (thing) {
      f;                     // Evaluates to a Function object.
      g;                     // Throws a ReferenceError.
    }

### 3.4. Security

Certain algorithms in the sections below are defined to perform a security check on a given object. This check is used to determine whether a given operation invocation or attribute access should be allowed. The security check takes the following three inputs:

1. the platform object on which the operation invocation or attribute access is being done,

2. the identifier of the operation or attribute, and

3. the type of the function object – "`method`" (when it corresponds to an IDL operation), or "`getter`" or "`setter`" (when it corresponds to the getter or setter function of an IDL attribute).

Note: The HTML Standard defines how a security check is performed. [HTML]

### 3.5. Overload resolution algorithm

In order to define how function invocations are resolved, the overload resolution algorithm is defined. Its input is an effective overload set, S, and a list of ECMAScript values, args. Its output is a pair consisting of the operation or extended attribute of one of S’s entries and a list of IDL values or the special value “missing”. The algorithm behaves as follows:

1. Let maxarg be the length of the longest type list of the entries in S.

2. Let n be the size of args.

3. Initialize argcount to be min(maxarg, n).

4. Remove from S all entries whose type list is not of length argcount.

5. If S is empty, then throw a `TypeError`.

6. Initialize d to −1.

7. Initialize method to undefined.

8. If there is more than one entry in S, then set d to be the distinguishing argument index for the entries of S.

9. Initialize values to be an empty list, where each entry will be either an IDL value or the special value “missing”.

10. Initialize i to 0.

11. While i < d:

    1. Let V be args[i].

    2. Let type be the type at index i in the type list of any entry in S.

       Note: All entries in S at this point have the same type and optionality value at index i.

    3. Let optionality be the value at index i in the list of optionality values of any entry in S.

    4. If optionality is “optional” and V is undefined, then:

       1. If the argument at index i is declared with a default value, then append to values that default value.

       2. Otherwise, append to values the special value “missing”.

    5. Otherwise, append to values the result of converting V to IDL type type.

    6. Set i to i + 1.

12. If i = d, then:

    1. Let V be args[i].

       Note: This is the argument that will be used to resolve which overload is selected.

    2. If V is undefined, and there is an entry in S whose list of optionality values has “optional” at index i, then remove from S all other entries.

    3. Otherwise: if V is null or undefined, and there is an entry in S that has one of the following types at position i of its type list,

       - a nullable type

       - a dictionary type

       - an annotated type whose inner type is one of the above types

       - a union type or annotated union type that includes a nullable type or that has a dictionary type in its flattened members

       then remove from S all other entries.

    4. Otherwise: if V is a platform object, and there is an entry in S that has one of the following types at position i of its type list,

       - an interface type that V implements

       - `object`

       - a nullable version of any of the above types

       - an annotated type whose inner type is one of the above types

       - a union type, nullable union type, or annotated union type that has one of the above types in its flattened member types

       then remove from S all other entries.

    5. Otherwise: if Type(V) is Object, V has an [[ArrayBufferData]] internal slot, and there is an entry in S that has one of the following types at position i of its type list,

       - `ArrayBuffer`

       - `object`

       - a nullable version of either of the above types

       - an annotated type whose inner type is one of the above types

       - a union type, nullable union type, or annotated union type that has one of the above types in its flattened member types

       then remove from S all other entries.

    6. Otherwise: if Type(V) is Object, V has a [[DataView]] internal slot, and there is an entry in S that has one of the following types at position i of its type list,

       - `DataView`

       - `object`

       - a nullable version of either of the above types

       - an annotated type whose inner type is one of the above types

       - a union type, nullable union type, or annotated union type that has one of the above types in its flattened member types

       then remove from S all other entries.

    7. Otherwise: if Type(V) is Object, V has a [[TypedArrayName]] internal slot, and there is an entry in S that has one of the following types at position i of its type list,

       - a typed array type whose name is equal to the value of V’s [[TypedArrayName]] internal slot

       - `object`

       - a nullable version of either of the above types

       - an annotated type whose inner type is one of the above types

       - a union type, nullable union type, or annotated union type that has one of the above types in its flattened member types

       then remove from S all other entries.

    8. Otherwise: if IsCallable(V) is true, and there is an entry in S that has one of the following types at position i of its type list,

       - a callback function type

       - `object`

       - a nullable version of any of the above types

       - an annotated type whose inner type is one of the above types

       - a union type, nullable union type, or annotated union type that has one of the above types in its flattened member types

       then remove from S all other entries.

    9. Otherwise: if Type(V) is Object and there is an entry in S that has one of the following types at position i of its type list,

       - a sequence type

       - a frozen array type

       - a nullable version of any of the above types

       - an annotated type whose inner type is one of the above types

       - a union type, nullable union type, or annotated union type that has one of the above types in its flattened member types

       and after performing the following steps,

       1. Let method be ? GetMethod(V, `@@iterator`).

       method is not undefined, then remove from S all other entries.

    10. Otherwise: if Type(V) is Object and there is an entry in S that has one of the following types at position i of its type list,

        - a callback interface type

        - a dictionary type

        - a record type

        - `object`

        - a nullable version of any of the above types

        - an annotated type whose inner type is one of the above types

        - a union type, nullable union type, or annotated union type that has one of the above types in its flattened member types

        then remove from S all other entries.

    11. Otherwise: if Type(V) is Boolean and there is an entry in S that has one of the following types at position i of its type list,

        - `boolean`

        - a nullable `boolean`

        - an annotated type whose inner type is one of the above types

        - a union type, nullable union type, or annotated union type that has one of the above types in its flattened member types

        then remove from S all other entries.

    12. Otherwise: if Type(V) is Number and there is an entry in S that has one of the following types at position i of its type list,

        - a numeric type

        - a nullable numeric type

        - an annotated type whose inner type is one of the above types

        - a union type, nullable union type, or annotated union type that has one of the above types in its flattened member types

        then remove from S all other entries.

    13. Otherwise: if there is an entry in S that has one of the following types at position i of its type list,

        - a string type

        - a nullable version of any of the above types

        - an annotated type whose inner type is one of the above types

        - a union type, nullable union type, or annotated union type that has one of the above types in its flattened member types

        then remove from S all other entries.

    14. Otherwise: if there is an entry in S that has one of the following types at position i of its type list,

        - a numeric type

        - a nullable numeric type

        - an annotated type whose inner type is one of the above types

        - a union type, nullable union type, or annotated union type that has one of the above types in its flattened member types

        then remove from S all other entries.

    15. Otherwise: if there is an entry in S that has one of the following types at position i of its type list,

        - `boolean`

        - a nullable `boolean`

        - an annotated type whose inner type is one of the above types

        - a union type, nullable union type, or annotated union type that has one of the above types in its flattened member types

        then remove from S all other entries.

    16. Otherwise: if there is an entry in S that has `any` at position i of its type list, then remove from S all other entries.

    17. Otherwise: throw a `TypeError`.

13. Let callable be the operation or extended attribute of the single entry in S.

14. If i = d and method is not undefined, then

    1. Let V be args[i].

    2. Let T be the type at index i in the type list of the remaining entry in S.

    3. If T is a sequence type, then append to values the result of creating a sequence of type T from V and method.

    4. Otherwise, T is a frozen array type. Append to values the result of creating a frozen array of type T from V and method.

    5. Set i to i + 1.

15. While i < argcount:

    1. Let V be args[i].

    2. Let type be the type at index i in the type list of the remaining entry in S.

    3. Let optionality be the value at index i in the list of optionality values of the remaining entry in S.

    4. If optionality is “optional” and V is undefined, then:

       1. If the argument at index i is declared with a default value, then append to values that default value.

       2. Otherwise, append to values the special value “missing”.

    5. Otherwise, append to values the result of converting V to IDL type type.

    6. Set i to i + 1.

16. While i is less than the number of arguments callable is declared to take:

    1. If callable’s argument at index i is declared with a default value, then append to values that default value.

    2. Otherwise, if callable’s argument at index i is not variadic, then append to values the special value “missing”.

    3. Set i to i + 1.

17. Return the pair <callable, values>.

The overload resolution algorithm performs both the identification of which overloaded operation, constructor, etc. is being called, and the conversion of the ECMAScript argument values to their corresponding IDL values. Informally, it operates as follows.

First, the selection of valid overloads is done by considering the number of ECMAScript arguments that were passed in to the function:

- If there are more arguments passed in than the longest overload argument list, then they are ignored.

- After ignoring these trailing arguments, only overloads that can take this exact number of arguments are considered. If there are none, then a `TypeError` is thrown.

Once we have a set of possible overloads with the right number of arguments, the ECMAScript values are converted from left to right. The nature of the restrictions on overloading means that if we have multiple possible overloads at this point, then there will be one position in the argument list that will be used to distinguish which overload we will finally select; this is the distinguishing argument index.

We first convert the arguments to the left of the distinguishing argument. (There is a requirement that an argument to the left of the distinguishing argument index has the same type as in the other overloads, at the same index.) Then we inspect the type of the ECMAScript value that is passed in at the distinguishing argument index to determine which IDL type it may correspond to. This allows us to select the final overload that will be invoked. If the value passed in is undefined and there is an overload with an optional argument at this position, then we will choose that overload. If there is no valid overload for the type of value passed in here, then we throw a `TypeError`. Generally, the inspection of the value at the distinguishing argument index does not have any side effects, and the only side effects in the overload resolution algorithm are the result of converting the ECMAScript values to IDL values. (An exception exists when one of the overloads has a sequence type or frozen array type at the distinguishing argument index. In this case, we attempt to get the `@@iterator` property to determine the appropriate overload, and perform the conversion of the distinguishing argument separately before continuing with the next step.)

At this point, we have determined which overload to use. We now convert the remaining arguments, from the distinguishing argument onwards, again ignoring any additional arguments that were ignored due to being passed after the last possible argument.

When converting an optional argument’s ECMAScript value to its equivalent IDL value, undefined will be converted into the optional argument’s default value, if it has one, or a special value “missing” otherwise.

Optional arguments corresponding to a final, variadic argument do not treat undefined as a special “missing” value, however. The undefined value is converted to the type of variadic argument as would be done for a non-optional argument.

### 3.6. Interfaces

For every interface that is exposed in a given Realm and that is not declared with the [`NoInterfaceObject`] or [`LegacyNamespace`] extended attributes, a corresponding property exists on the Realm's global object. The name of the property is the identifier of the interface, and its value is an object called the interface object. The characteristics of an interface object are described in § 3.6.1 Interface object.

If the [`LegacyWindowAlias`] extended attribute was specified on an exposed interface, then for each identifier in [`LegacyWindowAlias`]'s identifiers there exists a corresponding property on the `Window` global object. The name of the property is the given identifier, and its value is a reference to the interface object for the interface.

In addition, for every [`NamedConstructor`] extended attribute on an exposed interface, a corresponding property exists on the ECMAScript global object. The name of the property is the [`NamedConstructor`]'s identifier, and its value is an object called a named constructor, which allows construction of objects that implement the interface. The characteristics of a named constructor are described in § 3.6.2 Named constructors.

#### 3.6.1. Interface object

The interface object for a given interface is a built-in function object. It has properties that correspond to the constants and static operations defined on that interface, as described in sections § 3.6.5 Constants and § 3.6.7 Operations.

If the interface is declared with a constructor operation, then the interface object can be called as a constructor to create an object that implements that interface. Calling that interface as a function will throw an exception.

Interface objects whose interfaces are not declared with a constructor operation will throw when called, both as a function and as a constructor.

An interface object for an interface has an associated object called the interface prototype object. This object has properties that correspond to the regular attributes and regular operations defined on the interface, and is described in more detail in § 3.6.3 Interface prototype object.

Note: Since an interface object is a function object the `typeof` operator will return "function" when applied to an interface object.

An interface may have overridden constructor steps, which can change the behavior of the interface object when called or constructed. By default interfaces do not have such steps.

In general, constructors are described by defining a constructor operation and its behavior. The overridden constructor steps are used only for more complicated situations. Editors who wish to use this feature are strongly advised to discuss this by filing an issue before proceeding.

The interface object for a given interface I with identifier id and in Realm realm is created as follows:

1. Let steps be I’s overridden constructor steps if they exist, or the following steps otherwise:

   1. If I was not declared with a constructor operation, then throw a `TypeError`.

   2. If `NewTarget` is undefined, then throw a `TypeError`.

   3. Let args be the passed arguments.

   4. Let n be the size of args.

   5. Let id be the identifier of interface I.

   6. Compute the effective overload set for constructors with identifier id on interface I and with argument count n, and let S be the result.

   7. Let <constructor, values> be the result of passing S and args. to the overload resolution algorithm.

   8. Let object be the result of internally creating a new object implementing I, with realm and `NewTarget`.

   9. Perform the actions listed in the description of constructor with values as the argument values and object as this.

   10. Let O be object, converted to an ECMAScript value.

   11. Assert: O is an object that implements I.

   12. Assert: O.[[Realm]] is realm.

   13. Return O.

2. Let constructorProto be realm.[[Intrinsics]].[[`%FunctionPrototype%`]].

3. If I inherits from some other interface P, then set constructorProto to the interface object of P in realm.

4. Let F be ! CreateBuiltinFunction(steps, « [[Unforgeables]] », realm, constructorProto).

5. Let unforgeables be ObjectCreate(null).

6. Define the unforgeable regular operations of I on unforgeables, given realm.

7. Define the unforgeable regular attributes of I on unforgeables, given realm.

8. Set F.[[Unforgeables]] to unforgeables.

   Note: this object is never exposed to user code. It exists only to ensure all instances of an interface with an unforgeable member use the same JavaScript function objects for attribute getters, attribute setters and operation functions.

9. Perform ! SetFunctionName(F, id).

10. Let length be 0.

11. If I was declared with a constructor operation, then

    1. Compute the effective overload set for constructors with identifier id on interface I and with argument count 0, and let S be the result.

    2. Set length to the length of the shortest argument list of the entries in S.

12. Perform ! SetFunctionLength(F, length).

13. Let proto be the result of creating an interface prototype object of interface I in realm.

14. Perform ! DefinePropertyOrThrow(F, "`prototype`", PropertyDescriptor{[[Value]]: proto, [[Writable]]: false, [[Enumerable]]: false, [[Configurable]]: false}).

15. Define the constants of interface I on F given realm.

16. Define the static attributes of interface I on F given realm.

17. Define the static operations of interface I on F given realm.

18. Return F.

#### 3.6.2. Named constructors

A named constructor that exists due to one or more [`NamedConstructor`] extended attributes with a given identifier is a built-in function object. It allows constructing objects that implement the interface on which the [`NamedConstructor`] extended attributes appear.

The named constructor with identifier id for a given interface I in Realm realm is created as follows:

1. Let steps be the following steps:

   1. If `NewTarget` is undefined, then throw a `TypeError`.

   2. Let args be the passed arguments.

   3. Let n be the size of args.

   4. Compute the effective overload set for named constructors with identifier id on interface I and with argument count n, and let S be the result.

   5. Let <constructor, values> be the result of passing S and args to the overload resolution algorithm.

   6. Let object be the result of internally creating a new object implementing I, with realm and `NewTarget`.

   7. Perform the actions listed in the description of constructor with values as the argument values and object as this.

   8. Let O be object, converted to an ECMAScript value.

   9. Assert: O is an object that implements I.

   10. Assert: O.[[Realm]] is realm.

   11. Return O.

2. Let F be ! CreateBuiltinFunction(steps, « », realm).

3. Perform ! SetFunctionName(F, id).

4. Compute the effective overload set for named constructors with identifier id on interface I and with argument count 0, and let S be the result.

5. Let length be the length of the shortest argument list of the entries in S.

6. Perform ! SetFunctionLength(F, length).

7. Let proto be the interface prototype object of interface I in realm.

8. Perform ! DefinePropertyOrThrow(F, "`prototype`", PropertyDescriptor{[[Value]]: proto, [[Writable]]: false, [[Enumerable]]: false, [[Configurable]]: false}).

9. Return F.

#### 3.6.3. Interface prototype object

There will exist an interface prototype object for every interface defined, regardless of whether the interface was declared with the [`NoInterfaceObject`] extended attribute.

The interface prototype object for a given interface interface and Realm realm is created as follows:

1. Let proto be null.

2. If interface is declared with the [`Global`] extended attribute, and interface supports named properties, then set proto to the result of creating a named properties object for interface and realm.

3. Otherwise, if interface is declared to inherit from another interface, then set proto to the interface prototype object in realm of that inherited interface.

4. Otherwise, if interface is the `DOMException` interface, then set proto to realm.[[Intrinsics]].[[`%ErrorPrototype%`]].

5. Otherwise, set proto to realm.[[Intrinsics]].[[`%ObjectPrototype%`]].

6. Assert: Type(proto) is Object.

7. Let interfaceProtoObj be ! ObjectCreate(proto).

8. If interface has any member declared with the [`Unscopable`] extended attribute, then:

   Should an `@@unscopables` property also be defined if interface is declared with the [`Global`] extended attribute? This is discussed in issue #544.

   1. Let unscopableObject be the result of performing ! ObjectCreate(null).

   2. For each exposed member member of interface that is declared with the [`Unscopable`] extended attribute:

      1. Let id be member’s identifier.

      2. Perform ! CreateDataProperty(unscopableObject, id, true).

   3. Let desc be the PropertyDescriptor{[[Value]]: unscopableObject, [[Writable]]: false, [[Enumerable]]: false, [[Configurable]]: true}.

   4. Perform ! DefinePropertyOrThrow(interfaceProtoObj, `@@unscopables`, desc).

9. If interface is declared with the [`Global`] extended attribute, or interface is in the set of inherited interfaces of an interface that is declared with the [`Global`] extended attribute, then:

   1. Set the internal methods of interfaceProtoObj which are specific to immutable prototype exotic objects to the definitions specified in ECMA-262 Immutable prototype exotic objects.

10. If interface is not declared with the [`Global`] extended attribute, then:

    1. Define the regular attributes of interface on interfaceProtoObj given realm.

    2. Define the regular operations of interface on interfaceProtoObj given realm.

11. Define the constants of interface on interfaceProtoObj given realm.

12. If the [`NoInterfaceObject`] extended attribute was not specified on interface, then:

    1. Let constructor be the interface object of interface in realm.

    2. Let desc be the PropertyDescriptor{[[Writable]]: true, [[Enumerable]]: false, [[Configurable]]: true, [[Value]]: constructor}.

    3. Perform ! DefinePropertyOrThrow(interfaceProtoObj, "`constructor`", desc).

13. Return interfaceProtoObj.

Additionally, interface prototype objects get properties declaratively from:

- § 3.6.7.2 Stringifiers,

- § 3.6.8 Common iterator behavior,

- § 3.6.9 Iterable declarations,

- § 3.6.10 Maplike declarations, and

- § 3.6.11 Setlike declarations.

Define those properties imperatively instead.

The interface prototype object of an interface that is defined with the [`NoInterfaceObject`] extended attribute will be accessible. For example, with the following IDL:

    [Exposed=Window,
     NoInterfaceObject]
    interface Foo {
    };

    partial interface Window {
      attribute Foo foo;
    };

it is not possible to access the interface prototype object through the interface object (since it does not exist as `window.Foo`). However, an instance of `Foo` can expose the interface prototype object by calling its [[GetPrototypeOf]] internal method – `Object.getPrototypeOf(window.foo)` in this example.

The class string of an interface prototype object is the concatenation of the interface’s qualified name and the string "`Prototype`".

#### 3.6.4. Named properties object

For every interface declared with the [`Global`] extended attribute that supports named properties, there will exist an object known as the named properties object for that interface on which named properties are exposed.

The named properties object for a given interface interface and Realm realm, is created as follows:

1. Let proto be null.

2. If interface is declared to inherit from another interface, then set proto to the interface prototype object in realm for the inherited interface.

3. Otherwise, set proto to realm.[[Intrinsics]].[[`%ObjectPrototype%`]].

4. Let obj be a newly created object.

5. Set obj’s internal methods to the definitions specified in ECMA-262 Ordinary object internal methods and internal slots, unless they are specified in the the rest of § 3.6.4 Named properties object.

6. Set obj’s remaining internal methods to the definitions specified below.

7. Set obj.[[Prototype]] to proto.

8. Set obj.[[Extensible]] to true.

9. Return obj.

The class string of a named properties object is the concatenation of the interface’s identifier and the string "`Properties`".

##### 3.6.4.1. [[GetOwnProperty]]

When the [[GetOwnProperty]] internal method of a named properties object O is called with property key P, the following steps are taken:

1. Let A be the interface for the named properties object O.

2. Let object be O.[[Realm]]'s global object.

3. Assert: object implements A.

4. If the result of running the named property visibility algorithm with property name P and object object is true, then:

   1. Let operation be the operation used to declare the named property getter.

   2. Let value be an uninitialized variable.

   3. If operation was defined without an identifier, then set value to the result of performing the steps listed in the interface description to determine the value of a named property with P as the name.

   4. Otherwise, operation was defined with an identifier. Set value to the result of performing the steps listed in the description of operation with P as the only argument value.

   5. Let desc be a newly created Property Descriptor with no fields.

   6. Set desc.[[Value]] to the result of converting value to an ECMAScript value.

   7. If A implements an interface with the [`LegacyUnenumerableNamedProperties`] extended attribute, then set desc.[[Enumerable]] to false, otherwise set it to true.

   8. Set desc.[[Writable]] to true and desc.[[Configurable]] to true.

   9. Return desc.

5. Return OrdinaryGetOwnProperty(O, P).

##### 3.6.4.2. [[DefineOwnProperty]]

When the [[DefineOwnProperty]] internal method of a named properties object is called, the following steps are taken:

1. Return false.

##### 3.6.4.3. [[Delete]]

When the [[Delete]] internal method of a named properties object is called, the following steps are taken:

1. Return false.

##### 3.6.4.4. [[SetPrototypeOf]]

When the [[SetPrototypeOf]] internal method of a named properties object O is called with ECMAScript language value V, the following step is taken:

1. Return ? SetImmutablePrototype(O, V).

##### 3.6.4.5. [[PreventExtensions]]

When the [[PreventExtensions]] internal method of a named properties object is called, the following steps are taken:

1. Return false.

Note: this keeps named properties object extensible by making [[PreventExtensions]] fail.

#### 3.6.5. Constants

Constants are exposed on interface objects, legacy callback interface objects, interface prototype objects, and on the single object that implements the interface, when an interface is declared with the [`Global`] extended attribute.

To define the constants of interface or callback interface definition on target, given Realm realm, run the following steps:

1. For each constant const that is a member of definition:

   1. If const is not exposed in realm, then continue.

   2. Let value be the result of converting const’s IDL value to an ECMAScript value.

   3. Let desc be the PropertyDescriptor{[[Writable]]: false, [[Enumerable]]: true, [[Configurable]]: false, [[Value]]: value}.

   4. Let id be const’s identifier.

   5. Perform ! DefinePropertyOrThrow(target, id, desc).

#### 3.6.6. Attributes

Static attributes are exposed on the interface object. Regular attributes are exposed on the interface prototype object, unless the attribute is unforgeable or if the interface was declared with the [`Global`] extended attribute, in which case they are exposed on every object that implements the interface.

To define the regular attributes of interface or namespace definition on target, given Realm realm, run the following steps:

1. Let attributes be the list of regular attributes that are members of definition.

2. Remove from attributes all the attributes that are unforgeable.

3. Define the attributes attributes of definition on target given realm.

To define the static attributes of interface or namespace definition on target, given Realm realm, run the following steps:

1. Let attributes be the list of static attributes that are members of definition.

2. Define the attributes attributes of definition on target given realm.

To define the unforgeable regular attributes of interface or namespace definition on target, given Realm realm, run the following steps:

1. Let attributes be the list of unforgeable regular attributes that are members of definition.

2. Define the attributes attributes of definition on target given realm.

To define the attributes attributes of interface or namespace definition on target given Realm realm, run the following steps:

1. For each attribute attr of attributes:

   1. If attr is not exposed in realm, then continue.

   2. Let getter be the result of creating an attribute getter given attr, definition, and realm.

   3. Let setter be the result of creating an attribute setter given attr, definition, and realm.

      Note: the algorithm to create an attribute setter returns undefined if attr is read only.

   4. Let configurable be false if attr is unforgeable and true otherwise.

   5. Let desc be the PropertyDescriptor{[[Get]]: getter, [[Set]]: setter, [[Enumerable]]: true, [[Configurable]]: configurable}.

   6. Let id be attr’s identifier.

   7. Perform ! DefinePropertyOrThrow(target, id, desc).

The attribute getter is created as follows, given an attribute attribute, a namespace or interface target, and a Realm realm:

1. Let steps be the following series of steps:

   1. Try running the following steps:

      1. Let idlObject be null.

      2. If target is an interface, and attribute is a regular attribute:

         1. Let esValue be the this value, if it is not null or undefined, or realm’s global object otherwise. (This will subsequently cause a `TypeError` in a few steps, if the global object does not implement target and [`LenientThis`] is not specified.)

         2. If esValue is a platform object, then perform a security check, passing esValue, attribute’s identifier, and "getter".

         3. If esValue does not implement target, then:

            1. If attribute was specified with the [`LenientThis`] extended attribute, then return undefined.

            2. Otherwise, throw a `TypeError`.

         4. Set idlObject to the IDL interface type value that represents a reference to esValue.

      3. Let R be the result of getting the underlying value of attribute given idlObject.

      4. Return the result of converting R to an ECMAScript value of the type attribute is declared as.

   And then, if an exception E was thrown:

   1. If attribute’s type is a promise type, then return ! Call(`%Promise_reject%`, `%Promise%`, «E»).

   2. Otherwise, end these steps and allow the exception to propagate.

2. Let F be ! CreateBuiltinFunction(steps, « », realm).

3. Let name be the string "`get` " prepended to attribute’s identifier.

4. Perform ! SetFunctionName(F, name).

5. Perform ! SetFunctionLength(F, 0).

6. Return F.

The attribute setter is created as follows, given an attribute attribute, a namespace or interface target, and a Realm realm:

1. If target is a namespace:

   1. Assert: attribute is read only.

   2. Return undefined.

2. If attribute is read only and does not have a [`LenientSetter`], [`PutForwards`] or [`Replaceable`] extended attribute, return undefined; there is no attribute setter function.

3. Assert: attribute’s type is not a promise type.

4. Let steps be the following series of steps:

   1. If no arguments were passed, then throw a `TypeError`.

   2. Let V be the value of the first argument passed.

   3. Let id be attribute’s identifier.

   4. Let idlObject be null.

   5. If attribute is a regular attribute:

      1. Let esValue be the this value, if it is not null or undefined, or realm’s global object otherwise. (This will subsequently cause a `TypeError` in a few steps, if the global object does not implement target and [`LenientThis`] is not specified.)

      2. If esValue is a platform object, then perform a security check, passing esValue, id, and "setter".

      3. Let validThis be true if esValue implements target, or false otherwise.

      4. If validThis is false and attribute was not specified with the [`LenientThis`] extended attribute, then throw a `TypeError`.

      5. If attribute is declared with the [`Replaceable`] extended attribute, then:

         1. Perform ? CreateDataProperty(esValue, id, V).

         2. Return undefined.

      6. If validThis is false, then return undefined.

      7. If attribute is declared with a [`LenientSetter`] extended attribute, then return undefined.

      8. If attribute is declared with a [`PutForwards`] extended attribute, then:

         1. Let Q be ? Get(esValue, id).

         2. If Type(Q) is not Object, then throw a `TypeError`.

         3. Let forwardId be the identifier argument of the [`PutForwards`] extended attribute.

         4. Perform ? Set(Q, forwardId, V, true).

         5. Return undefined.

      9. Set idlObject to the IDL interface type value that represents a reference to esValue.

   6. Let idlValue be determined as follows:

      attribute’s type is an enumeration

        1. Let S be ? ToString(V).

        2. If S is not one of the enumeration’s values, then return undefined.

        3. Otherwise, idlValue is the enumeration value equal to S.

      Otherwise
        idlValue is the result of converting V to an IDL value of attribute’s type.

   7. Perform the actions listed in the description of attribute that occur on setting, with idlValue as the given value and idlObject as this if it is not null.

   8. Return undefined

5. Let F be ! CreateBuiltinFunction(steps, « », realm).

6. Let name be the string "`set` " prepended to id.

7. Perform ! SetFunctionName(F, name).

8. Perform ! SetFunctionLength(F, 1).

9. Return F.

Note: Although there is only a single property for an IDL attribute, since accessor property getters and setters are passed a this value for the object on which property corresponding to the IDL attribute is accessed, they are able to expose instance-specific data.

Note: Attempting to assign to a property corresponding to a read only attribute results in different behavior depending on whether the script doing so is in strict mode. When in strict mode, such an assignment will result in a `TypeError` being thrown. When not in strict mode, the assignment attempt will be ignored.

#### 3.6.7. Operations

For each unique identifier of an exposed operation defined on the interface, there exist a corresponding property. Static operations are exposed of the interface object. Regular operations are exposed on the interface prototype object, unless the operation is unforgeable or the interface was declared with the [`Global`] extended attribute, in which case they are exposed on every object that implements the interface.

To define the regular operations of interface or namespace definition on target, given Realm realm, run the following steps:

1. Let operations be the list of regular operations that are members of definition.

2. Remove from operations all the operations that are unforgeable.

3. Define the operations operations of definition on target given realm.

To define the static operations of interface or namespace definition on target, given Realm realm, run the following steps:

1. Let operations be the list of static operations that are members of definition.

2. Define the operations operations of definition on target given realm.

To define the unforgeable regular operations of interface or namespace definition on target, given Realm realm, run the following steps:

1. Let operations be the list of unforgeable regular operations that are members of definition.

2. Define the operations operations of definition on target given realm.

To define the operations operations of interface or namespace definition on target, given Realm realm, run the following steps:

1. For each operation op of operations:

   1. If op is not exposed in realm, then continue.

   2. Let method be the result of creating an operation function given op, definition, and realm.

   3. Let modifiable be false if op is unforgeable and true otherwise.

   4. Let desc be the PropertyDescriptor{[[Value]]: method, [[Writable]]: modifiable, [[Enumerable]]: true, [[Configurable]]: modifiable}.

   5. Let id be op’s identifier.

   6. Perform ! DefinePropertyOrThrow(target, id, desc).

To create an operation function, given an operation op, a namespace or interface target, and a Realm realm:

1. Let id be op’s identifier.

2. Let steps be the following series of steps, given function argument values args:

   1. Try running the following steps:

      1. Let idlObject be null.

      2. If target is an interface, and op is not a static operation:

         1. Let esValue be the this value, if it is not null or undefined, or realm’s global object otherwise. (This will subsequently cause a `TypeError` in a few steps, if the global object does not implement target and [`LenientThis`] is not specified.)

         2. If esValue is a platform object, then perform a security check, passing esValue, id, and "method".

         3. If esValue does not implement the interface target, throw a `TypeError`.

         4. Set idlObject to the IDL interface type value that represents a reference to esValue.

      3. Let n be the size of args.

      4. Compute the effective overload set for regular operations (if op is a regular operation) or for static operations (if op is a static operation) with identifier id on target and with argument count n, and let S be the result.

      5. Let <operation, values> be the result of passing S and args to the overload resolution algorithm.

      6. Let R be null.

      7. If operation is declared with a [`Default`] extended attribute, then:

         1. Set R be the result of performing the actions listed in operation’s corresponding default operation, with values as the argument values and idlObject as this if it is not null.

      8. Otherwise:

         1. Set R be the result of performing the actions listed in the description of operation, with values as the argument values and idlObject as this if it is not null.

      9. Return R, converted to an ECMAScript value.

         R is assumed to be an IDL value of the type op is declared to return. <https://github.com/heycam/webidl/issues/674>

   And then, if an exception E was thrown:

   1. If op has a return type that is a promise type, then return ! Call(`%Promise_reject%`, `%Promise%`, «E»).

   2. Otherwise, end these steps and allow the exception to propagate.

3. Let F be ! CreateBuiltinFunction(steps, « », realm).

4. Perform ! SetFunctionName(F, id).

5. Compute the effective overload set for regular operations (if op is a regular operation) or for static operations (if op is a static operation) with identifier id on target and with argument count 0, and let S be the result.

6. Let length be the length of the shortest argument list in the entries in S.

7. Perform ! SetFunctionLength(F, length).

8. Return F.

##### 3.6.7.1. Default operations

Only regular operations which have a corresponding default operation defined below may be declared with a [`Default`] extended attribute.

###### 3.6.7.1.1. Default toJSON operation

The corresponding default operation of the `toJSON` operation is the default toJSON operation.

The return type of the default toJSON operation must be `object`.

To invoke the default toJSON operation of interface I, run the the following steps:

1. Let map be a new ordered map.

2. Let stack be the result of creating an inheritance stack for interface I.

3. Invoke collect attribute values of an inheritance stack on this, passing it stack and map as arguments.

4. Let result be ! ObjectCreate(`%ObjectPrototype%`).

5. For each key → value of map,

   1. Let k be key converted to an ECMAScript value.

   2. Let v be value converted to an ECMAScript value.

   3. Perform ! CreateDataProperty(result, k, v).

6. Return result.

To invoke the collect attribute values of an inheritance stack abstract operation with stack stack and ordered map map as arguments, run the the following steps:

1. Let I be the result of popping from stack.

2. Invoke collect attribute values on this, passing it I and map as arguments.

3. If stack is not empty, then invoke collect attribute values of an inheritance stack on this, passing it stack and map as arguments.

To invoke the collect attribute values abstract operation with interface I and ordered map map as arguments, run the the following steps:

1. If a `toJSON` operation with a [`Default`] extended attribute is declared on I, then for each exposed regular attribute attr that is an interface member of I, in order:

   1. Let id be the identifier of attr.

   2. Let value be the result of getting the underlying value of attr given this.

   3. If value is a JSON type, then set map[id] to value.

To create an inheritance stack for interface I, run the the following steps:

1. Let stack be a new stack.

2. Push I onto stack.

3. While I inherits from an interface,

   1. Let I be that interface.

   2. Push I onto stack.

4. Return stack.

The following IDL fragment defines a number of interfaces, which are inherited interfaces of `A`, and interface mixins, which are included by `A` or by `A`’s inherited interfaces, as show in the below inheritance tree.

         C* - M4
         |
         B - M3
         |
    M1 - A - M2*

Interfaces and interface mixins marked with an asterisk ("*") declare a `toJSON` operation with a [`Default`] extended attribute.

    [Exposed=Window]
    interface A : B {
      attribute DOMString a;
    };

    [Exposed=Window]
    interface B : C {
      attribute DOMString b;
    };

    [Exposed=Window]
    interface C {
      [Default] object toJSON();
      attribute DOMString c;
    };

    interface mixin M1 {
      attribute DOMString m1;
    };

    interface mixin M2 {
      [Default] object toJSON();
      attribute DOMString m2;
    };

    interface mixin M3 {
      attribute DOMString m3;
    };

    interface mixin M4 {
      attribute DOMString m4;
    };

    A includes M1;
    A includes M2;
    B includes M3;
    C includes M4;

Calling the `toJSON()` method of an object implementing interface `A` defined above would return the following JSON object:

    {
        "a": "...",
        "m1": "...",
        "m2": "...",
        "c": "...",
        "m4": "..."
    }

An object implementing interface `B` would return:

    {
        "c": "...",
        "m4": "..."
    }

##### 3.6.7.2. Stringifiers

If the interface has an exposed stringifier, then there must exist a property with the following characteristics:

- The name of the property is "`toString`".

- If the stringifier is unforgeable on the interface or if the interface was declared with the [`Global`] extended attribute, then the property exists on every object that implements the interface. Otherwise, the property exists on the interface prototype object.

- The property has attributes { [[Writable]]: B, [[Enumerable]]: true, [[Configurable]]: B }, where B is false if the stringifier is unforgeable on the interface, and true otherwise.

- The value of the property is a built-in function object, which behaves as follows:

  1. Let O be the result of calling ToObject on the this value.

  2. If O is a platform object, then perform a security check, passing:

     - the platform object O,

     - the identifier of the stringifier, and

     - the type "`method`".

  3. If O does not implement the interface on which the stringifier was declared, then throw a `TypeError`.

  4. Let V be an uninitialized variable.

  5. Depending on where `stringifier` was specified:

     on an attribute

       Set V to the result of performing the actions listed in the description of the attribute that occur when getting (or those listed in the description of the inherited attribute, if this attribute is declared to inherit its getter), with O as the object.

     on an operation with an identifier

       Set V to the result of performing the actions listed in the description of the operation, using O as the this value and passing no arguments.

     on an operation with no identifier

       Set V to the result of performing the stringification behavior of the interface.

  6. Return the result of converting V to a String value.

- The value of the function object’s `length` property is the Number value 0.

- The value of the function object’s `name` property is the String value "`toString`".

#### 3.6.8. Common iterator behavior

##### 3.6.8.1. @@iterator

If the interface has any of the following:

- an iterable declaration

- an indexed property getter

- a maplike declaration

- a setlike declaration

then a property must exist whose name is the `@@iterator` symbol, with attributes { [[Writable]]: true, [[Enumerable]]: false, [[Configurable]]: true } and whose value is a function object.

The location of the property is determined as follows:

- If the interface was declared with the [`Global`] extended attribute, then the property exists on the single object that implements the interface.

- Otherwise, the property exists solely on the interface’s interface prototype object.

If the interface defines an indexed property getter, then the function object is `%ArrayProto_values%`.

If the interface has a pair iterator, then the function object is a built-in function object that, when invoked, must behave as follows:

1. Let object be the result of calling ToObject on the this value.

2. If object is a platform object, then perform a security check, passing:

   - the platform object object,

   - the identifier "`@@iterator`", and

   - the type "`method`".

3. Let interface be the interface the iterable declaration is on.

4. If object does not implement interface, then throw a `TypeError`.

5. Let iterator be a newly created default iterator object for interface with object as its target and iterator kind "`key+value`".

6. Return iterator.

If the interface has a maplike declaration or setlike declaration, then the function object is a built-in function object that, when invoked, must behave as follows:

1. Let object be the result of calling ToObject on the this value.

2. If object is a platform object, then perform a security check, passing:

   - the platform object object,

   - the identifier "`@@iterator`", and

   - the type "`method`".

3. If object does not implement the interface on which the maplike declaration or setlike declaration is defined, then throw a `TypeError`.

4. If the interface has a maplike declaration, then:

   1. Let backing be the value of the [[BackingMap]] internal slot of object.

   2. Return CreateMapIterator(backing, "`key+value`").

5. Otherwise:

   1. Let backing be the value of the [[BackingSet]] internal slot of object.

   2. Return CreateSetIterator(backing, "`value`").

The value of the `@@iterator` function object’s `length` property is the Number value 0.

The value of the `@@iterator` function object’s `name` property is the String value "`entries`" if the interface has a pair iterator or a maplike declaration and the String "`values`" if the interface has a setlike declaration.

##### 3.6.8.2. @@asyncIterator

If the interface has an asynchronously iterable declaration, then a property must exist whose name is the `@@asyncIterator` symbol, with attributes { [[Writable]]: true, [[Enumerable]]: false, [[Configurable]]: true } and whose value is a function object.

The location of the property is determined as follows:

- If the interface was declared with the [`Global`] extended attribute, then the property exists on the single object that implements the interface.

- Otherwise, the property exists solely on the interface’s interface prototype object.

The function object is a built-in function object that, when invoked, must behave as follows:

1. Let object be the result of calling ToObject on the this value.

2. If object is a platform object, then perform a security check, passing:

   - the platform object object,

   - the identifier "`@@asyncIterator`", and

   - the type "`method`".

3. Let interface be the interface on which the asynchronously iterable declaration is declared.

4. If object does not implement interface, then throw a `TypeError`.

5. Let iterator be a newly created default asynchronous iterator object for interface with object as its target, "`key+value`" as its kind, and is finished set to false.

6. Run the asynchronous iterator initialization steps for interface with object and iterator, if any such steps exist.

7. Return iterator.

The value of the `@@asyncIterator` function object’s `length` property is the Number value 0.

The value of the `@@asyncIterator` function object’s `name` property is the String value "`entries`".

##### 3.6.8.3. forEach

If the interface has any of the following:

- an iterable declaration

- a maplike declaration

- a setlike declaration

then a `forEach` data property must exist with attributes { [[Writable]]: true, [[Enumerable]]: true, [[Configurable]]: true } and whose value is a function object.

The location of the property is determined as follows:

- If the interface was declared with the [`Global`] extended attribute, then the property exists on the single object that implements the interface.

- Otherwise, the property exists solely on the interface’s interface prototype object.

If the interface defines an indexed property getter, then the function object is `%ArrayProto_forEach%`.

If the interface has a pair iterator, then the method must have the same behavior, when invoked with argument callback and optional argument thisArg, as one that would exist assuming the interface had this operation instead of the iterable declaration:

    [Exposed=Window]
    interface Iterable {
      void forEach(Function callback, optional any thisArg);
    };

with the following prose definition:

1. Let pairs be the list of value pairs to iterate over.

2. Let i be 0.

3. While i is less than the length of pairs:

   1. Let pair be the entry in pairs at index i.

   2. Let key be pair’s key.

   3. Let value be pair’s value.

   4. Invoke callback with thisArg (or undefined, if the argument was not supplied) as the callback this value and value, key and this as its arguments.

   5. Update pairs to the current list of value pairs to iterate over.

   6. Set i to i + 1.

If the interface has a maplike declaration or setlike declaration then the method, when invoked, must behave as follows:

1. Let object be the result of calling ToObject on the this value.

2. If object is a platform object, then perform a security check, passing:

   - the platform object object,

   - the identifier "`forEach`", and

   - the type "`method`".

3. Let interface be the interface on which the maplike declaration or setlike declaration is declared.

4. If object does not implement interface, then throw a `TypeError`.

5. Let callbackFn be the value of the first argument passed to the function, or undefined if the argument was not supplied.

6. If IsCallable(callbackFn) is false, throw a `TypeError`.

7. Let thisArg be the value of the second argument passed to the function, or undefined if the argument was not supplied.

8. Let backing be the value of the [[BackingMap]] internal slot of object, if the interface has a maplike declaration, or the [[BackingSet]] internal slot of object otherwise.

9. Let callbackWrapper be a built-in function object that, when invoked, behaves as follows:

   1. Let v and k be the first two arguments passed to the function.

   2. Let thisArg be the this value.

   3. Perform ? Call(callbackFn, thisArg, «v, k, object»).

   Note: The callbackWrapper function simply calls the incoming callbackFn with object as the third argument rather than its internal [[BackingMap]] or [[BackingSet]] object.

   Can the script author observe that callbackWrapper might be a new function every time forEach is called? What’s the best way of specifying that there’s only one function that has captured an environment?

10. Let forEach be ? GetMethod(backing, "`forEach`").

11. If forEach is undefined, then throw a `TypeError`.

12. Perform ? Call(forEach, backing, «callbackWrapper, thisArg»).

13. Return undefined.

The value of the function object’s `length` property is the Number value 1.

The value of the function object’s `name` property is the String value "`forEach`".

#### 3.6.9. Iterable declarations

##### 3.6.9.1. entries

If the interface has an iterable declaration or an asynchronously iterable declaration, then an `entries` data property must exist with attributes { [[Writable]]: true, [[Enumerable]]: true, [[Configurable]]: true } and whose value is a function object.

The location of the property is determined as follows:

- If the interface was declared with the [`Global`] extended attribute, then the property exists on the single object that implements the interface.

- Otherwise, the property exists solely on the interface’s interface prototype object.

If the interface has a value iterator, then the function object is `%ArrayProto_entries%`.

If the interface has a pair iterator, then the function object is the value of the `@@iterator` property.

If the interface has an asynchronously iterable declaration, then the function object is the value of the `@@asyncIterator` property.

##### 3.6.9.2. keys

If the interface has an iterable declaration or an asynchronously iterable declaration, then a `keys` data property must exist with attributes { [[Writable]]: true, [[Enumerable]]: true, [[Configurable]]: true } and whose value is a function object.

The location of the property is determined as follows:

- If the interface was declared with the [`Global`] extended attribute, then the property exists on the single object that implements the interface.

- Otherwise, the property exists solely on the interface’s interface prototype object.

If the interface has a value iterator, then the function object is `%ArrayProto_keys%`.

If the interface has a pair iterator, then the method, when invoked, must behave as follows:

1. Let object be the result of calling ToObject on the this value.

2. If object is a platform object, then perform a security check, passing:

   - the platform object object,

   - the identifier "`keys`", and

   - the type "`method`".

3. Let interface be the interface on which the iterable declaration is declared.

4. If object does not implement interface, then throw a `TypeError`.

5. Let iterator be a newly created default iterator object for interface with object as its target and iterator kind "`key`".

6. Return iterator.

If the interface has an asynchronously iterable declaration, then the method, when invoked, must behave as follows:

1. Let object be the result of calling ToObject on the this value.

2. If object is a platform object, then perform a security check, passing:

   - the platform object object,

   - the identifier "`keys`", and

   - the type "`method`".

3. Let interface be the interface on which the asynchronously iterable declaration is declared.

4. If object does not implement interface, then throw a `TypeError`.

5. Let iterator be a newly created default asynchronous iterator object for interface with object as its target, "`key`" as its kind, and is finished set to false.

6. Run the asynchronous iterator initialization steps for interface with object and iterator, if any such steps exist.

7. Return iterator.

The value of the function object’s `length` property is the Number value 0.

The value of the function object’s `name` property is the String value "`keys`".

##### 3.6.9.3. values

If the interface has an iterable declaration or an asynchronously iterable declaration, then a `values` data property must exist with attributes { [[Writable]]: true, [[Enumerable]]: true, [[Configurable]]: true } and whose value is a function object.

The location of the property is determined as follows:

- If the interface was declared with the [`Global`] extended attribute, then the property exists on the single object that implements the interface.

- Otherwise, the property exists solely on the interface’s interface prototype object.

If the interface has a value iterator, then the function object is the value of the `@@iterator` property.

If the interface has a pair iterator, then the method, when invoked, must behave as follows:

1. Let object be the result of calling ToObject on the this value.

2. If object is a platform object, then perform a security check, passing:

   - the platform object object,

   - the identifier "`entries`", and

   - the type "`method`".

3. Let interface be the interface on which the iterable declaration is declared.

4. If object does not implement interface, then throw a `TypeError`.

5. Let iterator be a newly created default iterator object for interface with object as its target and iterator kind "`value`".

6. Return iterator.

If the interface has an asynchronously iterable declaration, then the method, when invoked, must behave as follows:

1. Let object be the result of calling ToObject on the this value.

2. If object is a platform object, then perform a security check, passing:

   - the platform object object,

   - the identifier "`entries`", and

   - the type "`method`".

3. Let interface be the interface on which the asynchronously iterable declaration is declared.

4. If object does not implement interface, then throw a `TypeError`.

5. Let iterator be a newly created default asynchronous iterator object for interface with object as its target, "`value`" as its kind, and is finished set to false.

6. Run the asynchronous iterator initialization steps for interface with object and iterator, if any such steps exist.

7. Return iterator.

The value of the function object’s `length` property is the Number value 0.

The value of the function object’s `name` property is the String value "`values`".

##### 3.6.9.4. Default iterator objects

A default iterator object for a given interface, target and iteration kind is an object whose [[Prototype]] internal slot is the iterator prototype object for the interface.

A default iterator object has three internal values:

1. its target, which is an object whose values are to be iterated,

2. its kind, which is the iteration kind,

3. its index, which is the current index into the values value to be iterated.

Note: Default iterator objects are only used for pair iterators; value iterators, as they are currently restricted to iterating over an object’s supported indexed properties, use standard ECMAScript Array iterator objects.

When a default iterator object is first created, its index is set to 0.

Default iterator objects do not have class strings; when `Object.prototype.toString()` is called on a default iterator object of a given interface, the class string of the iterator prototype object of that interface is used.

##### 3.6.9.5. Iterator prototype object

The iterator prototype object for a given interface is an object that exists for every interface that has a pair iterator. It serves as the prototype for default iterator objects for the interface.

The [[Prototype]] internal slot of an iterator prototype object must be `%IteratorPrototype%`.

The iterator result for a value pair pair and a kind kind is given by the following steps:

1. Let result be a value determined by the value of kind:

   "`key`"

     1. Let idlKey be pair’s key.

     2. Let key be the result of converting idlKey to an ECMAScript value.

     3. result is key.

   "`value`"

     1. Let idlValue be pair’s value.

     2. Let value be the result of converting idlValue to an ECMAScript value.

     3. result is value.

   "`key+value`"

     1. Let idlKey be pair’s key.

     2. Let idlValue be pair’s value.

     3. Let key be the result of converting idlKey to an ECMAScript value.

     4. Let value be the result of converting idlValue to an ECMAScript value.

     5. Let array be the result of performing ArrayCreate(2).

     6. Call CreateDataProperty(array, "`0`", key).

     7. Call CreateDataProperty(array, "`1`", value).

     8. result is array.

2. Return CreateIterResultObject(result, false).

An iterator prototype object must have a `next` data property with attributes { [[Writable]]: true, [[Enumerable]]: true, [[Configurable]]: true } and whose value is a built-in function object that behaves as follows:

1. Let interface be the interface for which the iterator prototype object exists.

2. Let object be the result of calling ToObject on the this value.

3. If object is a platform object, then perform a security check, passing:

   - the platform object object,

   - the identifier "`next`", and

   - the type "`method`".

4. If object is not a default iterator object for interface, then throw a `TypeError`.

5. Let index be object’s index.

6. Let kind be object’s kind.

7. Let values be the list of value pairs to iterate over.

8. Let len be the length of values.

9. If index is greater than or equal to len, then return CreateIterResultObject(undefined, true).

10. Let pair be the entry in values at index index.

11. Set object’s index to index + 1.

12. Return the iterator result for pair and kind.

The class string of an iterator prototype object for a given interface is the result of concatenating the identifier of the interface and the string "`Iterator`".

##### 3.6.9.6. Default asynchronous iterator objects

A default asynchronous iterator object for a given interface, target and iteration kind is an object whose [[Prototype]] internal slot is the asynchronous iterator prototype object for the interface.

A default asynchronous iterator object has internal values:

- its target, which is an object whose values are to be iterated,

- its kind, which is the iteration kind,

- its ongoing promise, which is a `Promise` or null,

- its is finished, which is a boolean.

Note: Default asynchronous iterator objects do not have class strings; when `Object.prototype.toString()` is called on a default asynchronous iterator object of a given interface, the class string of the asynchronous iterator prototype object of that interface is used.

##### 3.6.9.7. Asynchronous iterator prototype object

The asynchronous iterator prototype object for a given interface is an object that exists for every interface that has an asynchronously iterable declaration. It serves as the prototype for default asynchronous iterator objects for the interface.

The [[Prototype]] internal slot of an asynchronous iterator prototype object must be `%AsyncIteratorPrototype%`.

An asynchronous iterator prototype object must have a `next` data property with attributes { [[Writable]]: true, [[Enumerable]]: true, [[Configurable]]: true } and whose value is a built-in function object that behaves as follows:

1. Let interface be the interface for which the asynchronous iterator prototype object exists.

2. Let thisValidationPromiseCapability be ! NewPromiseCapability(`%Promise%`).

3. Let object be the result of calling ToObject on the this value.

4. IfAbruptRejectPromise(object, thisValidationPromiseCapability).

5. If object is a platform object, then perform a security check, passing:

   - the platform object object,

   - the identifier "`next`", and

   - the type "`method`".

   If this threw an exception e, then:

   1. Perform ! Call(thisValidationPromiseCapability.[[Reject]], undefined, « e »).

   2. Return thisValidationPromiseCapability.[[Promise]].

6. If object is not a default asynchronous iterator object for interface, then:

   1. Let error be a new `TypeError`.

   2. Perform ! Call(thisValidationPromiseCapability.[[Reject]], undefined, « error »).

   3. Return thisValidationPromiseCapability.[[Promise]].

7. Let nextSteps be the following steps:

   1. Let nextPromiseCapability be ! NewPromiseCapability(`%Promise%`).

   2. If object’s is finished is true, then:

      1. Let result be CreateIterResultObject(undefined, true).

      2. Perform ! Call(nextPromiseCapability.[[Resolve]], undefined, « result »).

      3. Return nextPromiseCapability.[[Promise]].

   3. Let kind be object’s kind.

   4. Let nextPromise be the result of getting the next iteration result with object’s target and object.

   5. Let fulfillSteps be the following steps, given next:

      1. Set object’s ongoing promise to null.

      2. If next is undefined, then:

         1. Set object’s is finished to true.

         2. Return ! CreateIterResultObject(undefined, true).

      3. Otherwise:

         1. Return the iterator result for next and kind.

   6. Let onFulfilled be ! CreateBuiltinFunction(fulfillSteps, « »).

   7. Perform ! PerformPromiseThen(nextPromise, onFulfilled, undefined, nextPromiseCapability).

   8. Return nextPromiseCapability.[[Promise]].

8. Let promise be object’s ongoing promise.

9. If promise is not null, then:

   1. Let afterOngoingPromiseCapability be ! NewPromiseCapability(`%Promise%`).

   2. Let onFulfilled be ! CreateBuiltinFunction(nextSteps, « »).

   3. Perform ! PerformPromiseThen(promise, onFulfilled, undefined, afterOngoingPromiseCapability).

   4. Set object’s ongoing promise to afterOngoingPromiseCapability.[[Promise]].

10. Otherwise:

    1. Run nextSteps and set object’s ongoing promise to the result.

11. Return object’s ongoing promise.

If an asynchronous iterator return algorithm is defined for the interface, then the asynchronous iterator prototype object must have a `return` data property with attributes { [[Writable]]: true, [[Enumerable]]: true, [[Configurable]]: true } and whose value is a built-in function object, taking one argument value, that behaves as follows:

1. Let interface be the interface for which the asynchronous iterator prototype object exists.

2. Let returnPromiseCapability be ! NewPromiseCapability(`%Promise%`).

3. Let object be the result of calling ToObject on the this value.

4. IfAbruptRejectPromise(object, returnPromiseCapability).

5. If object is a platform object, then perform a security check, passing:

   - the platform object object,

   - the identifier "`return`", and

   - the type "`method`".

   If this threw an exception e, then:

   1. Perform ! Call(returnPromiseCapability.[[Reject]], undefined, « e »).

   2. Return returnPromiseCapability.[[Promise]].

6. If object is not a default asynchronous iterator object for interface, then:

   1. Let error be a new `TypeError`.

   2. Perform ! Call(returnPromiseCapability.[[Reject]], undefined, « error »).

   3. Return returnPromiseCapability.[[Promise]].

7. If object’s ongoing promise is not null, then:

   1. Let error be a new `TypeError`.

   2. Perform ! Call(returnPromiseCapability.[[Reject]], undefined, « error »).

   3. Return returnPromiseCapability.[[Promise]].

8. If object’s is finished is true, then:

   1. Let result be ! CreateIterResultObject(value, true).

   2. Perform ! Call(returnPromiseCapability.[[Resolve]], undefined, « result »).

   3. Return returnPromiseCapability.[[Promise]].

9. Set object’s is finished to true.

10. Let returnPromise be the result of running the asynchronous iterator return algorithm for interface, given object’s target, object, and value.

11. Let fulfillSteps be the following steps:

    1. Return ! CreateIterResultObject(value, true).

12. Let onFulfilled be ! CreateBuiltinFunction(fulfillSteps, « »).

13. Perform ! PerformPromiseThen(returnPromise, onFulfilled, undefined, returnPromiseCapability).

14. Return returnPromiseCapability.[[Promise]].

The class string of an asynchronous iterator prototype object for a given interface is the result of concatenating the identifier of the interface and the string "`AsyncIterator`".

#### 3.6.10. Maplike declarations

Any object that implements an interface that has a maplike declaration must have a [[BackingMap]] internal slot, which is initially set to a newly created `Map` object. This `Map` object’s [[MapData]] internal slot is the object’s map entries.

If an interface A is declared with a maplike declaration, then there exists a number of additional properties on A’s interface prototype object. These additional properties are described in the sub-sections below.

Some of the properties below are defined to have a function object value that forwards to the internal map object for a given function name. Such functions behave as follows when invoked:

1. Let O be the this value.

2. Let arguments be the list of arguments passed to this function.

3. Let name be the function name.

4. If O is a platform object, then perform a security check, passing:

   - the platform object O,

   - an identifier equal to name, and

   - the type "`method`".

5. If O does not implement A, then throw a `TypeError`.

6. Let map be the `Map` object that is the value of O’s [[BackingMap]] internal slot.

7. Let function be ? GetMethod(map, name).

8. If function is undefined, then throw a `TypeError`.

9. Return ? Call(function, map, arguments).

##### 3.6.10.1. size

There must exist a `size` property on A’s interface prototype object with the following characteristics:

- The property has attributes { [[Get]]: G, [[Enumerable]]: false, [[Configurable]]: true }, where G is the interface’s map size getter, defined below.

- The map size getter is a built-in function object whose behavior when invoked is as follows:

  1. Let O be the this value.

  2. If O is a platform object, then perform a security check, passing:

     - the platform object O,

     - the identifier "`size`", and

     - the type "`getter`".

  3. If O does not implement A, then throw a `TypeError`.

  4. Let map be the `Map` object that is the value of O’s [[BackingMap]] internal slot.

  5. Return Get(map, "`size`").

  The value of the function object’s `length` property is the Number value 0.

  The value of the function object’s `name` property is the String value "`size`".

##### 3.6.10.2. entries

An `entries` data property must exist on A’s interface prototype object with attributes { [[Writable]]: true, [[Enumerable]]: false, [[Configurable]]: true } and whose value is the function object that is the value of the `@@iterator` property.

##### 3.6.10.3. keys and values

For both of `keys` and `values`, there must exist a data property with that name on A’s interface prototype object with the following characteristics:

- The property has attributes { [[Writable]]: true, [[Enumerable]]: false, [[Configurable]]: true }.

- The value of the property is a built-in function object that forwards that name to the internal map object.

The value of the function objects’ `length` properties is the Number value 0.

The value of the function object’s `name` property is the String value "`keys`" or "`values`", correspondingly.

##### 3.6.10.4. get and has

For both of `get` and `has`, there must exist a data property with that name on A’s interface prototype object with the following characteristics:

- The property has attributes { [[Writable]]: true, [[Enumerable]]: false, [[Configurable]]: true }.

- The value of the property is a built-in function object that behaves as follows when invoked:

  1. Let O be the this value.

  2. Let name be the name of the property – "`get`" or "`has`".

  3. If O is a platform object, then perform a security check, passing:

     - the platform object O,

     - an identifier equal to name, and

     - the type "`method`".

  4. If O does not implement A, then throw a `TypeError`.

  5. Let map be the `Map` object that is the value of O’s [[BackingMap]] internal slot.

  6. Let keyType be the key type specified in the maplike declaration.

  7. Let function be ! Get(map, name).

  8. Let keyArg be the first argument passed to this function, or undefined if not supplied.

  9. Let keyIDL be the result of converting keyArg to an IDL value of type keyType.

  10. Let key be the result of converting keyIDL to an ECMAScript value.

  11. Return ? Call(function, map, «key»).

The value of the function object’s `length` properties is the Number value 1.

The value of the function object’s `name` property is the String value "`get`" or "`has`", correspondingly.

##### 3.6.10.5. clear

If A does not declare a member with identifier "`clear`", and A was declared with a read–write maplike declaration, then a `clear` data property with the following characteristics must exist on A’s interface prototype object:

- The property has attributes { [[Writable]]: true, [[Enumerable]]: false, [[Configurable]]: true }.

- The value of the property is a built-in function object that forwards `clear` to the internal map object.

The value of the function object’s `length` property is the Number value 0.

The value of the function object’s `name` property is the String value "`clear`".

##### 3.6.10.6. delete

If A does not declare a member with identifier "`delete`", and A was declared with a read–write maplike declaration, then a `delete` data property with the following characteristics must exist on A’s interface prototype object:

- The property has attributes { [[Writable]]: true, [[Enumerable]]: false, [[Configurable]]: true }.

- The value of the property is a built-in function object that behaves as follows when invoked:

  1. Let O be the this value.

  2. If O is a platform object, then perform a security check, passing:

     - the platform object O,

     - the identifier "`delete`", and

     - the type "`method`".

  3. If O does not implement A, then throw a `TypeError`.

  4. Let map be the `Map` object that is the value of O’s [[BackingMap]] internal slot.

  5. Let keyType be the key type specified in the maplike declaration.

  6. Let function be ! Get(map, "`delete`").

  7. Let keyArg be the first argument passed to this function, or undefined if not supplied.

  8. Let keyIDL be the result of converting keyArg to an IDL value of type keyType.

  9. Let key be the result of converting keyIDL to an ECMAScript value.

  10. Return ? Call(function, map, «key»).

The value of the function object’s `length` property is the Number value 1.

The value of the function object’s `name` property is the String value "`delete`".

##### 3.6.10.7. set

If A does not declare a member with identifier "`set`", and A was declared with a read–write maplike declaration, then a `set` data property with the following characteristics must exist on A’s interface prototype object:

- The property has attributes { [[Writable]]: true, [[Enumerable]]: false, [[Configurable]]: true }.

- The value of the property is a built-in function object that behaves as follows when invoked:

  1. Let O be the this value.

  2. If O is a platform object, then perform a security check, passing:

     - the platform object O,

     - the identifier "`set`", and

     - the type "`method`".

  3. If O does not implement A, then throw a `TypeError`.

  4. Let map be the `Map` object that is the value of O’s [[BackingMap]] internal slot.

  5. Let keyType and valueType be the key and value types specified in the maplike declaration.

  6. Let function be ! Get(map, "`set`").

  7. Let keyArg be the first argument passed to this function, or undefined if not supplied.

  8. Let valueArg be the second argument passed to this function, or undefined if not supplied.

  9. Let keyIDL be the result of converting keyArg to an IDL value of type keyType.

  10. Let valueIDL be the result of converting valueArg to an IDL value of type valueType.

  11. Let key be the result of converting keyIDL to an ECMAScript value.

  12. Let value be the result of converting valueIDL to an ECMAScript value.

  13. Perform ? Call(function, map, «key, value»).

  14. Return O.

The value of the function object’s `length` property is the Number value 2.

The value of the function object’s `name` property is the String value "`set`".

#### 3.6.11. Setlike declarations

Any object that implements an interface that has a setlike declaration must have a [[BackingSet]] internal slot, which is initially set to a newly created `Set` object. This `Set` object’s [[SetData]] internal slot is the object’s set entries.

If an interface A is declared with a setlike declaration, then there exists a number of additional properties on A’s interface prototype object. These additional properties are described in the sub-sections below.

Some of the properties below are defined to have a built-in function object value that forwards to the internal set object for a given function name. Such functions behave as follows when invoked:

1. Let O be the this value.

2. Let arguments be the list of arguments passed to this function.

3. Let name be the function name.

4. If O is a platform object, then perform a security check, passing:

   - the platform object O,

   - an identifier equal to name, and

   - the type "`method`".

5. If O does not implement A, then throw a `TypeError`.

6. Let set be the `Set` object that is the value of O’s [[BackingSet]] internal slot.

7. Let function be ? GetMethod(set, name).

8. If function is undefined, then throw a `TypeError`.

9. Return ? Call(function, set, arguments).

##### 3.6.11.1. size

A `size` property must exist on A’s interface prototype object with the following characteristics:

- The property has attributes { [[Get]]: G, [[Enumerable]]: false, [[Configurable]]: true }, where G is the interface’s set size getter, defined below.

- The set size getter is a built-in function object whose behavior when invoked is as follows:

  1. Let O be the this value.

  2. If O is a platform object, then perform a security check, passing:

     - the platform object O,

     - the identifier "`size`", and

     - the type "`getter`".

  3. If O does not implement A, then throw a `TypeError`.

  4. Let set be the `Set` object that is the value of O’s [[BackingSet]] internal slot.

  5. Return the result of calling the [[Get]] internal method of set passing "`size`" and set as arguments.

  The value of the function object’s `length` property is the Number value 0.

  The value of the function object’s `name` property is the String value "`size`".

##### 3.6.11.2. values

A `values` data property must exist on A’s interface prototype object with attributes { [[Writable]]: true, [[Enumerable]]: false, [[Configurable]]: true } and whose value is the function object that is the value of the `@@iterator` property.

##### 3.6.11.3. entries and keys

For both of `entries` and `keys`, there must exist a data property with that name on A’s interface prototype object with the following characteristics:

- The property has attributes { [[Writable]]: true, [[Enumerable]]: false, [[Configurable]]: true }.

- The value of the property is a built-in function object that forwards that name to the internal set object.

The value of the function object’s `length` properties is the Number value 0.

The value of the function object’s `name` property is the String value "`entries`" or "`keys`", correspondingly.

##### 3.6.11.4. has

There must exist a `has` data property on A’s interface prototype object with the following characteristics:

- The property has attributes { [[Writable]]: true, [[Enumerable]]: false, [[Configurable]]: true }.

- The value of the property is a built-in function object that behaves as follows when invoked:

  1. Let O be the this value.

  2. If O is a platform object, then perform a security check, passing:

     - the platform object O,

     - the identifier "`has`", and

     - the type "`method`".

  3. If O does not implement A, then throw a `TypeError`.

  4. Let set be the `Set` object that is the value of O’s [[BackingSet]] internal slot.

  5. Let type be the value type specified in the setlike declaration.

  6. Let function be ! Get(set, "`has`").

  7. Let arg be the first argument passed to this function, or undefined if not supplied.

  8. Let idlValue be the result of converting arg to an IDL value of type type.

  9. Let value be the result of converting idlValue to an ECMAScript value.

  10. Return ? Call(function, set, «value»).

The value of the function object’s `length` property is a Number value 1.

The value of the function object’s `name` property is the String value "`has`".

##### 3.6.11.5. add and delete

For both of `add` and `delete`, if:

- A does not declare an member with a matching identifier, and

- A was declared with a read–write setlike declaration,

then a data property with that name and the following characteristics must exist on A’s interface prototype object:

- The property has attributes { [[Writable]]: true, [[Enumerable]]: false, [[Configurable]]: true }.

- The value of the property is a built-in function object that behaves as follows when invoked:

  1. Let O be the this value.

  2. Let name be the name of the property – "`add`" or "`delete`".

  3. If O is a platform object, then perform a security check, passing:

     - the platform object O,

     - an identifier equal to name, and

     - the type "`method`".

  4. If O does not implement A, then throw a `TypeError`.

  5. Let set be the `Set` object that is the value of O’s [[BackingSet]] internal slot.

  6. Let type be the value type specified in the setlike declaration.

  7. Let function be ? Get(set, name).

  8. Let arg be the first argument passed to this function, or undefined if not supplied.

  9. Let idlValue be the result of converting arg to an IDL value of type type.

  10. Let value be the result of converting idlValue to an ECMAScript value.

  11. Let result be ? Call(function, set, «value»).

  12. If name is "delete", then return result.

  13. Otherwise, return O.

The value of the function object’s `length` property is the Number value 1.

The value of the function object’s `name` property is the String value "`add`" or "`delete`", correspondingly.

##### 3.6.11.6. clear

If A does not declare a member with a matching identifier, and A was declared with a read–write setlike declaration, then a `clear` data property with the following characteristics must exist on A’s interface prototype object:

- The property has attributes { [[Writable]]: true, [[Enumerable]]: false, [[Configurable]]: true }.

- The value of the property is a built-in function object that forwards `clear` to the internal map object.

The value of the function object’s `length` property is the Number value 0.

The value of the function object’s `name` property is the String value "`clear`".

### 3.7. Platform objects implementing interfaces

An ECMAScript value value is a platform object if Type(value) is Object and if value has a [[PrimaryInterface]] internal slot.
An ECMAScript value value implements an interface interface if value is a platform object and the inclusive inherited interfaces of value.[[PrimaryInterface]] contains interface.

Specifications may reference the concept "object implements interface" in various ways, including "object is an interface object".

Every platform object is associated with a Realm, just as the initial objects are. This Realm is stored in the platform object's [[Realm]] slot. It is the responsibility of specifications using Web IDL to state which Realm (or, by proxy, which global object) each platform object is associated with. In particular, the algorithms below associate the new platform object with the Realm given as an argument.

To create a new object implementing the interface interface, with a Realm realm, perform the following steps:

1. Return the result of internally creating a new object implementing interface, with realm and undefined.

To internally create a new object implementing the interface interface, with a Realm realm and a JavaScript value newTarget, perform the following steps:

1. Assert: interface is exposed in realm.

2. If newTarget is undefined, then:

   1. Let prototype be the interface prototype object for interface in realm.

3. Otherwise:

   1. Assert: IsCallable(newTarget) is true.

   2. Let prototype be ? Get(newTarget, "prototype").

   3. If Type(prototype) is not Object, then:

      1. Let targetRealm be GetFunctionRealm(newTarget).

      2. Set prototype to the interface prototype object for interface in targetRealm.

4. Let slots be « [[Realm]], [[PrimaryInterface]] ».

5. Let instance be a newly created object in realm with an internal slot for each name in slots.

6. Set instance.[[Realm]] to realm.

7. Set instance.[[PrimaryInterface]] to interface.

8. Set instance.[[Prototype]] to prototype.

9. Set instance’s essential internal methods to the definitions specified in ECMA-262 Ordinary object internal methods and internal slots.

10. Let interfaces be the inclusive inherited interfaces of interface.

11. For every interface ancestor interface in interfaces:

    1. Let unforgeables be the value of the [[Unforgeables]] slot of the interface object of ancestor interface in realm.

    2. Let keys be ! unforgeables.[[OwnPropertyKeys]]().

    3. For each element key of keys:

       1. Let descriptor be ! unforgeables.[[GetOwnProperty]](key).

       2. Perform ! DefinePropertyOrThrow(instance, key, descriptor).

12. If interface is declared with the [`Global`] extended attribute, then:

    1. Define the regular operations of interface on instance, given realm.

    2. Define the regular attributes of interface on instance, given realm.

    3. Define the global property references on instance, given realm.

    4. Set instance.[[SetPrototypeOf]] as defined in § 3.7.1 [[SetPrototypeOf]].

13. Otherwise, if interfaces contains an interface which supports indexed properties, named properties, or both:

    1. Set instance.[[GetOwnProperty]] as defined in § 3.8.1 [[GetOwnProperty]].

    2. Set instance.[[Set]] as defined in § 3.8.2 [[Set]].

    3. Set instance.[[DefineOwnProperty]] as defined in § 3.8.3 [[DefineOwnProperty]].

    4. Set instance.[[Delete]] as defined in § 3.8.4 [[Delete]].

    5. Set instance.[[PreventExtensions]] as defined in § 3.8.5 [[PreventExtensions]].

    6. Set instance.[[OwnPropertyKeys]] as defined in § 3.8.6 [[OwnPropertyKeys]].

14. Return instance.

To define the global property references on target, given Realm realm, perform the following steps:

1. Let interfaces be a list that contains every interface that is exposed in realm.

2. Sort interfaces in such a way that if A and B are items of interfaces, and A inherits from B, A has a higher index in interfaces than B.

3. For every interface of interfaces:

   1. If interface is not declared with the [`NoInterfaceObject`] or [`LegacyNamespace`] extended attributes, then:

      1. Let id be interface’s identifier.

      2. Let interfaceObject be the result of creating an interface object for interface with id in realm.

      3. Perform ! CreateMethodProperty(target, id, interfaceObject).

      4. If the interface is declared with a [`LegacyWindowAlias`] extended attribute, and target implements the `Window` interface, then:

         1. For every identifier id in [`LegacyWindowAlias`]'s identifiers:

            1. Perform ! CreateMethodProperty(target, id, interfaceObject).

   2. If the interface is declared with a [`NamedConstructor`] extended attribute, then:

      1. For every identifier id in [`NamedConstructor`]'s identifiers:

         1. Let namedConstructor be the result of creating a named constructor with id for interface in realm.

         2. Perform ! CreateMethodProperty(target, id, namedConstructor).

4. For every callback interface interface that is exposed in realm and on which constants are defined:

   1. Let id be interface’s identifier.

   2. Let interfaceObject be the result of creating a legacy callback interface object for interface with id in realm.

   3. Perform ! CreateMethodProperty(target, id, interfaceObject).

5. For every namespace namespace that is exposed in realm:

   1. Let id be namespace’s identifier.

   2. Let namespaceObject be the result of creating a namespace object for namespace in realm.

   3. Perform ! CreateMethodProperty(target, id, namespaceObject).

The set of interfaces that a platform object implements does not change over the lifetime of the object.

Multiple platform objects with different global objects will share a reference to the same interface in their [[PrimaryInterface]] internal slots. For example, a page may contain a same-origin iframe, with the iframe’s method being called on the main page’s element of the same kind, with no exception thrown.

Interface mixins do not participate directly in the evaluation of the implements algorithm. Instead, each interface that the interface mixin is included in has its own "copy" of each member of the interface mixin, and the corresponding operation function checks that the receiver implements the particular interface which includes the interface mixin.

The primary interface of a platform object is the value of the object’s [[PrimaryInterface]] internal slot, which is is the most-derived interface that it implements.

The Realm that a given platform object is associated with can change after it has been created. When the Realm associated with a platform object is changed, its [[Prototype]] internal slot must be immediately updated to be the interface prototype object of the primary interface from the platform object’s newly associated Realm.

The class string of a platform object that implements one or more interfaces must be the qualified name of the primary interface of the platform object.

Additionally, platform objects which implement an interface which has a [`Global`] extended attribute get properties declaratively from:

- § 3.6.7.2 Stringifiers,

- § 3.6.8 Common iterator behavior,

- § 3.6.9 Iterable declarations,

- § 3.6.10 Maplike declarations, and

- § 3.6.11 Setlike declarations.

Define those properties imperatively instead.

#### 3.7.1. [[SetPrototypeOf]]

When the [[SetPrototypeOf]] internal method of a platform object O that implements an interface with the [`Global`] extended attribute is called with ECMAScript language value V, the following step is taken:

1. Return ? SetImmutablePrototype(O, V).

Note: For `Window` objects, it is unobservable whether this is implemented, since the presence of the `WindowProxy` object ensures that [[SetPrototypeOf]] is never called on a `Window` object directly. For other global objects, however, this is necessary.

### 3.8. Legacy platform objects

Legacy platform objects will appear to have additional properties that correspond to their indexed and named properties. These properties are not “real” own properties on the object, but are made to look like they are by being exposed by the [[GetOwnProperty]] internal method .

It is permissible for an object to implement multiple interfaces that support indexed properties. However, if so, and there are conflicting definitions as to the object’s supported property indices, then it is undefined what additional properties the object will appear to have, or what its exact behavior will be with regard to its indexed properties. The same applies for named properties.

The indexed property getter that is defined on the derived-most interface that the legacy platform object implements is the one that defines the behavior when indexing the object with an array index. Similarly for indexed property setters. This way, the definitions of these special operations from ancestor interfaces can be overridden.

A property name is an unforgeable property name on a given platform object O if the object implements an interface that has an interface member with that identifier and that interface member is unforgeable on any of the interfaces that O implements.

Support for getters is handled in § 3.8.1 [[GetOwnProperty]], and for setters in § 3.8.3 [[DefineOwnProperty]] and § 3.8.2 [[Set]].

Additionally, legacy platform objects have internal methods as defined in:

- § 3.8.4 [[Delete]],

- § 3.8.5 [[PreventExtensions]], and

- § 3.8.6 [[OwnPropertyKeys]].

#### 3.8.1. [[GetOwnProperty]]

The [[GetOwnProperty]] internal method of every legacy platform object O must behave as follows when called with property name P:

1. Return LegacyPlatformObjectGetOwnProperty(O, P, false).

#### 3.8.2. [[Set]]

The [[Set]] internal method of every legacy platform object O must behave as follows when called with property name P, value V, and ECMAScript language value Receiver:

1. If O and Receiver are the same object, then:

   1. If O implements an interface with an indexed property setter and P is an array index, then:

      1. Invoke the indexed property setter with P and V.

      2. Return true.

   2. If O implements an interface with a named property setter and Type(P) is String, then:

      1. Invoke the named property setter with P and V.

      2. Return true.

2. Let ownDesc be LegacyPlatformObjectGetOwnProperty(O, P, true).

3. Perform ? OrdinarySetWithOwnDescriptor(O, P, V, Receiver, ownDesc).

#### 3.8.3. [[DefineOwnProperty]]

When the [[DefineOwnProperty]] internal method of a legacy platform object O is called with property key P and Property Descriptor Desc, the following steps must be taken:

1. If O supports indexed properties and P is an array index, then:

   1. If the result of calling IsDataDescriptor(Desc) is false, then return false.

   2. If O does not implement an interface with an indexed property setter, then return false.

   3. Invoke the indexed property setter with P and Desc.[[Value]].

   4. Return true.

2. If O supports named properties, O does not implement an interface with the [`Global`] extended attribute, Type(P) is String, and P is not an unforgeable property name of O, then:

   1. Let creating be true if P is not a supported property name, and false otherwise.

   2. If O implements an interface with the [`OverrideBuiltins`] extended attribute or O does not have an own property named P, then:

      1. If creating is false and O does not implement an interface with a named property setter, then return false.

      2. If O implements an interface with a named property setter, then:

         1. If the result of calling IsDataDescriptor(Desc) is false, then return false.

         2. Invoke the named property setter with P and Desc.[[Value]].

         3. Return true.

3. If O does not implement an interface with the [`Global`] extended attribute, then set Desc.[[Configurable]] to true.

4. Return OrdinaryDefineOwnProperty(O, P, Desc).

#### 3.8.4. [[Delete]]

The [[Delete]] internal method of every legacy platform object O must behave as follows when called with property name P.

1. If O supports indexed properties and P is an array index, then:

   1. Let index be the result of calling ToUint32(P).

   2. If index is not a supported property index, then return true.

   3. Return false.

2. If O supports named properties, O does not implement an interface with the [`Global`] extended attribute and the result of calling the named property visibility algorithm with property name P and object O is true, then:

   1. If O does not implement an interface with a named property deleter, then return false.

   2. Let operation be the operation used to declare the named property deleter.

   3. If operation was defined without an identifier, then:

      1. Perform the steps listed in the interface description to delete an existing named property with P as the name.

      2. If the steps indicated that the deletion failed, then return false.

   4. Otherwise, operation was defined with an identifier:

      1. Perform the steps listed in the description of operation with P as the only argument value.

      2. If operation was declared with a return type of `boolean` and the steps returned false, then return false.

   5. Return true.

3. If O has an own property with name P, then:

   1. If the property is not configurable, then return false.

   2. Otherwise, remove the property from O.

4. Return true.

#### 3.8.5. [[PreventExtensions]]

When the [[PreventExtensions]] internal method of a legacy platform object is called, the following steps are taken:

1. Return false.

Note: this keeps legacy platform objects extensible by making [[PreventExtensions]] fail for them.

#### 3.8.6. [[OwnPropertyKeys]]

This document does not define a complete property enumeration order for platform objects implementing interfaces (or for platform objects representing exceptions). However, it does for legacy platform objects by defining the [[OwnPropertyKeys]] internal method as follows.

When the [[OwnPropertyKeys]] internal method of a legacy platform object O is called, the following steps are taken:

1. Let keys be a new empty list of ECMAScript String and Symbol values.

2. If O supports indexed properties, then for each index of O’s supported property indices, in ascending numerical order, append ! ToString(index) to keys.

3. If O supports named properties, then for each P of O’s supported property names that is visible according to the named property visibility algorithm, append P to keys.

4. For each P of O’s own property keys that is a String, in ascending chronological order of property creation, append P to keys.

5. For each P of O’s own property keys that is a Symbol, in ascending chronological order of property creation, append P to keys.

6. Assert: keys has no duplicate items.

7. Return keys.

#### 3.8.7. Abstract operations

To determine if a property name P is an array index, the following algorithm is applied:

1. If Type(P) is not String, then return false.

2. Let index be ! CanonicalNumericIndexString(P).

3. If index is undefined, then return false.

4. If IsInteger(index) is false, then return false.

5. If index is −0, then return false.

6. If index < 0, then return false.

7. If index ≥ 232 − 1, then return false.

   Note: 232 − 1 is the maximum array length allowed by ECMAScript.

8. Return true.

The named property visibility algorithm is used to determine if a given named property is exposed on an object. Some named properties are not exposed on an object depending on whether the [`OverrideBuiltins`] extended attribute was used. The algorithm operates as follows, with property name P and object O:

1. If P is not a supported property name of O, then return false.

2. If O has an own property named P, then return false.

   Note: This will include cases in which O has unforgeable properties, because in practice those are always set up before objects have any supported property names, and once set up will make the corresponding named properties invisible.

3. If O implements an interface that has the [`OverrideBuiltins`] extended attribute, then return true.

4. Let prototype be O.[[GetPrototypeOf]]().

5. While prototype is not null:

   1. If prototype is not a named properties object, and prototype has an own property named P, then return false.

   2. Set prototype to prototype.[[GetPrototypeOf]]().

6. Return true.

This should ensure that for objects with named properties, property resolution is done in the following order:

1. Indexed properties.

2. Own properties, including unforgeable attributes and operations.

3. Then, if [`OverrideBuiltins`]:

   1. Named properties.

   2. Properties from the prototype chain.

4. Otherwise, if not [`OverrideBuiltins`]:

   1. Properties from the prototype chain.

   2. Named properties.

To invoke an indexed property setter with property name P and ECMAScript value V, the following steps must be performed:

1. Let index be the result of calling ToUint32(P).

2. Let creating be true if index is not a supported property index, and false otherwise.

3. Let operation be the operation used to declare the indexed property setter.

4. Let T be the type of the second argument of operation.

5. Let value be the result of converting V to an IDL value of type T.

6. If operation was defined without an identifier, then:

   1. If creating is true, then perform the steps listed in the interface description to set the value of a new indexed property with index as the index and value as the value.

   2. Otherwise, creating is false. Perform the steps listed in the interface description to set the value of an existing indexed property with index as the index and value as the value.

7. Otherwise, operation was defined with an identifier. Perform the steps listed in the description of operation with index and value as the two argument values.

To invoke a named property setter with property name P and ECMAScript value V, the following steps must be performed:

1. Let creating be true if P is not a supported property name, and false otherwise.

2. Let operation be the operation used to declare the named property setter.

3. Let T be the type of the second argument of operation.

4. Let value be the result of converting V to an IDL value of type T.

5. If operation was defined without an identifier, then:

   1. If creating is true, then perform the steps listed in the interface description to set the value of a new named property with P as the name and value as the value.

   2. Otherwise, creating is false. Perform the steps listed in the interface description to set the value of an existing named property with P as the name and value as the value.

6. Otherwise, operation was defined with an identifier. Perform the steps listed in the description of operation with P and value as the two argument values.

The LegacyPlatformObjectGetOwnProperty abstract operation performs the following steps when called with an object O, a property name P, and a boolean ignoreNamedProps value:

1. If O supports indexed properties and P is an array index, then:

   1. Let index be the result of calling ToUint32(P).

   2. If index is a supported property index, then:

      1. Let operation be the operation used to declare the indexed property getter.

      2. Let value be an uninitialized variable.

      3. If operation was defined without an identifier, then set value to the result of performing the steps listed in the interface description to determine the value of an indexed property with index as the index.

      4. Otherwise, operation was defined with an identifier. Set value to the result of performing the steps listed in the description of operation with index as the only argument value.

      5. Let desc be a newly created Property Descriptor with no fields.

      6. Set desc.[[Value]] to the result of converting value to an ECMAScript value.

      7. If O implements an interface with an indexed property setter, then set desc.[[Writable]] to true, otherwise set it to false.

      8. Set desc.[[Enumerable]] and desc.[[Configurable]] to true.

      9. Return desc.

   3. Set ignoreNamedProps to true.

2. If O supports named properties and ignoreNamedProps is false, then:

   1. If the result of running the named property visibility algorithm with property name P and object O is true, then:

      1. Let operation be the operation used to declare the named property getter.

      2. Let value be an uninitialized variable.

      3. If operation was defined without an identifier, then set value to the result of performing the steps listed in the interface description to determine the value of a named property with P as the name.

      4. Otherwise, operation was defined with an identifier. Set value to the result of performing the steps listed in the description of operation with P as the only argument value.

      5. Let desc be a newly created Property Descriptor with no fields.

      6. Set desc.[[Value]] to the result of converting value to an ECMAScript value.

      7. If O implements an interface with a named property setter, then set desc.[[Writable]] to true, otherwise set it to false.

      8. If O implements an interface with the [`LegacyUnenumerableNamedProperties`] extended attribute, then set desc.[[Enumerable]] to false, otherwise set it to true.

      9. Set desc.[[Configurable]] to true.

      10. Return desc.

3. Return OrdinaryGetOwnProperty(O, P).

### 3.9. Callback interfaces

As described in § 2.12 Objects implementing interfaces, callback interfaces can be implemented in script by any ECMAScript object. The following cases explain how a callback interface's operation is invoked on a given object:

- If the object is callable, then the implementation of the operation is the callable object itself.

- Otherwise, the implementation of the operation is calling the result of invoking the internal [[Get]] method on the object with a property name that is the identifier of the operation.

Note that ECMAScript objects need not have properties corresponding to constants on them to be considered as implementing callback interfaces that happen to have constants declared on them.

A Web IDL arguments list is a list of values each of which is either an IDL value or the special value “missing”, which represents a missing optional argument.

To convert a Web IDL arguments list to an ECMAScript arguments list, given a Web IDL arguments list args, perform the following steps:

1. Let esArgs be an empty list.

2. Let i be 0.

3. Let count be 0.

4. While i < args’s size:

   1. If args[i] is the special value “missing”, then append undefined to esArgs.

   2. Otherwise, args[i] is an IDL value:

      1. Let convertResult be the result of converting args[i] to an ECMAScript value. Rethrow any exceptions.

      2. Append convertResult to esArgs.

      3. Set count to i + 1.

   3. Set i to i + 1.

5. Truncate esArgs to contain count items.

6. Return esArgs.

To call a user object’s operation, given a callback interface type value value, operation name opName, Web IDL arguments list args, and optional callback this value thisArg, perform the following steps. These steps will either return an IDL value or throw an exception.

1. Let completion be an uninitialized variable.

2. If thisArg was not given, let thisArg be undefined.

3. Let O be the ECMAScript object corresponding to value.

4. Let realm be O’s associated Realm.

5. Let relevant settings be realm’s settings object.

6. Let stored settings be value’s callback context.

7. Prepare to run script with relevant settings.

8. Prepare to run a callback with stored settings.

9. Let X be O.

10. If ! IsCallable(O) is false, then:

    1. Let getResult be Get(O, opName).

    2. If getResult is an abrupt completion, set completion to getResult and jump to the step labeled return.

    3. Set X to getResult.[[Value]].

    4. If ! IsCallable(X) is false, then set completion to a new Completion{[[Type]]: throw, [[Value]]: a newly created `TypeError` object, [[Target]]: empty}, and jump to the step labeled return.

    5. Set thisArg to O (overriding the provided value).

11. Let esArgs be the result of converting args to an ECMAScript arguments list. If this throws an exception, set completion to the completion value representing the thrown exception and jump to the step labeled return.

12. Let callResult be Call(X, thisArg, esArgs).

13. If callResult is an abrupt completion, set completion to callResult and jump to the step labeled return.

14. Set completion to the result of converting callResult.[[Value]] to an IDL value of the same type as the operation’s return type.

15. Return: at this point completion will be set to an ECMAScript completion value.

    1. Clean up after running a callback with stored settings.

    2. Clean up after running script with relevant settings.

    3. If completion is a normal completion, return completion.

    4. If completion is an abrupt completion and the operation has a return type that is not a promise type, return completion.

    5. Let rejectedPromise be ! Call(`%Promise_reject%`, `%Promise%`, «completion.[[Value]]»).

    6. Return the result of converting rejectedPromise to the operation’s return type.

#### 3.9.1. Legacy callback interface object

For every callback interface that is exposed in a given Realm and on which constants are defined, a corresponding property exists on the Realm's global object. The name of the property is the identifier of the callback interface, and its value is an object called the legacy callback interface object.

The legacy callback interface object for a given callback interface is a built-in function object. It has properties that correspond to the constants defined on that interface, as described in sections § 3.6.5 Constants.

Note: Since a legacy callback interface object is a function object the `typeof` operator will return "function" when applied to a legacy callback interface object.

The legacy callback interface object for a given callback interface interface with identifier id and in Realm realm is created as follows:

1. Let steps be the following steps:

   1. Throw a `TypeError`.

2. Let F be ! CreateBuiltinFunction(steps, « », realm).

3. Perform ! SetFunctionName(F, id).

4. Perform ! SetFunctionLength(F, 0).

5. Define the constants of interface on F given realm.

6. Return F.

### 3.10. Invoking callback functions

An ECMAScript callable object that is being used as a callback function value is called in a manner similar to how operations on callback interface values are called (as described in the previous section).

To invoke a callback function type value callable with a Web IDL arguments list args and an optional callback this value thisArg, perform the following steps. These steps will either return an IDL value or throw an exception.

1. Let completion be an uninitialized variable.

2. If thisArg was not given, let thisArg be undefined.

3. Let F be the ECMAScript object corresponding to callable.

4. If ! IsCallable(F) is false:

   1. If the callback function’s return type is `void`, return.

      Note: This is only possible when the callback function came from an attribute marked with [`TreatNonObjectAsNull`].

   2. Return the result of converting undefined to the callback function’s return type.

5. Let realm be F’s associated Realm.

6. Let relevant settings be realm’s settings object.

7. Let stored settings be callable’s callback context.

8. Prepare to run script with relevant settings.

9. Prepare to run a callback with stored settings.

10. Let esArgs be the result of converting args to an ECMAScript arguments list. If this throws an exception, set completion to the completion value representing the thrown exception and jump to the step labeled return.

11. Let callResult be Call(F, thisArg, esArgs).

12. If callResult is an abrupt completion, set completion to callResult and jump to the step labeled return.

13. Set completion to the result of converting callResult.[[Value]] to an IDL value of the same type as the operation’s return type.

14. Return: at this point completion will be set to an ECMAScript completion value.

    1. Clean up after running a callback with stored settings.

    2. Clean up after running script with relevant settings.

    3. If completion is a normal completion, return completion.

    4. If completion is an abrupt completion and the callback function has a return type that is not a promise type, return completion.

    5. Let rejectedPromise be ! Call(`%Promise_reject%`, `%Promise%`, «completion.[[Value]]»).

    6. Return the result of converting rejectedPromise to the callback function’s return type.

Some callback functions are instead used as constructors. Such callback functions must not have a return type that is a promise type.

To construct a callback function type value callable with a Web IDL arguments list args, perform the following steps. These steps will either return an IDL value or throw an exception.

1. Let completion be an uninitialized variable.

2. Let F be the ECMAScript object corresponding to callable.

3. If ! IsConstructor(F) is false, throw a `TypeError` exception.

4. Let realm be F’s associated Realm.

5. Let relevant settings be realm’s settings object.

6. Let stored settings be callable’s callback context.

7. Prepare to run script with relevant settings.

8. Prepare to run a callback with stored settings.

9. Let esArgs be the result of converting args to an ECMAScript arguments list. If this throws an exception, set completion to the completion value representing the thrown exception and jump to the step labeled return.

10. Let callResult be Construct(F, esArgs).

11. If callResult is an abrupt completion, set completion to callResult and jump to the step labeled return.

12. Set completion to the result of converting callResult.[[Value]] to an IDL value of the same type as the operation’s return type.

13. Return: at this point completion will be set to an ECMAScript completion value.

    1. Clean up after running a callback with stored settings.

    2. Clean up after running script with relevant settings.

    3. Return completion.

### 3.11. Namespaces

For every namespace that is exposed in a given Realm, a corresponding property exists on the Realm's global object. The name of the property is the identifier of the namespace, and its value is an object called the namespace object.

The characteristics of a namespace object are described in § 3.11.1 Namespace object.

#### 3.11.1. Namespace object

The namespace object for a given namespace namespace and Realm realm is created as follows:

1. Let namespaceObject be ! ObjectCreate(realm.[[Intrinsics]].[[`%ObjectPrototype%`]]).

2. Define the regular attributes of namespace on namespaceObject given realm.

3. Define the regular operations of namespace on namespaceObject given realm.

4. For each exposed interface interface which has the [`LegacyNamespace`] extended attribute with the identifier of namespace as its argument,

   1. Let id be interface’s identifier.

   2. Let interfaceObject be the result of creating an interface object for interface with id in realm.

   3. Perform ! CreateMethodProperty(namespaceObject, id, interfaceObject).

5. Return namespaceObject.

### 3.12. Exceptions

#### 3.12.1. `DOMException` custom bindings

In the ECMAScript binding, the interface prototype object for `DOMException` has its [[Prototype]] internal slot set to the intrinsic object `%ErrorPrototype%`, as defined in the create an interface prototype object abstract operation.

Additionally, if an implementation gives native `Error` objects special powers or nonstandard properties (such as a `stack` property), it should also expose those on `DOMException` instances.

#### 3.12.2. Exception objects

Simple exceptions are represented by native ECMAScript objects of the corresponding type.

A `DOMException` is represented by a platform object that implements the `DOMException` interface.

#### 3.12.3. Creating and throwing exceptions

To create a simple exception or `DOMException` E, with a string giving the error name N for the `DOMException` case and optionally a string giving a user agent-defined message M:

1. If M was not specified, let M be undefined.

2. Let args be a list of ECMAScript values determined based on the type of E:

   E is `DOMException`

     args is «M, N».

   E is a simple exception

     args is «M».

3. Let X be an object determined based on the type of E:

   E is `DOMException`

     X is the `DOMException` interface object from the current Realm.

   E is a simple exception

     X is the constructor for the corresponding ECMAScript error from the current Realm.

4. Return ! Construct(X, args).

To throw a simple exception or `DOMException`, with a string giving the error name for the `DOMException` case and optionally a string giving a user agent-defined message:

1. Let O be the result of creating an exception with the same arguments.

2. Throw O.

The above algorithms restrict objects representing exceptions propagating out of a function object to be ones that are associated with the Realm of that function object (i.e., the current Realm at the time the function executes). For example, consider the IDL:

    [Exposed=Window]
    interface MathUtils {
      // If x is negative, throws a "NotSupportedError" DOMException.
      double computeSquareRoot(double x);
    };

If we apply `computeSquareRoot` to a `MathUtils` object from a different Realm, then the exception thrown will be from the Realm of the method, not the object it is applied to:

    const myMU = window.getMathUtils();          // A MathUtils object from this Realm
    const otherMU = otherWindow.getMathUtils();  // A MathUtils object from a different Realm

    myMU instanceof Object;                      // Evaluates to true.
    otherMU instanceof Object;                   // Evaluates to false.
    otherMU instanceof otherWindow.Object;       // Evaluates to true.

    try {
      otherMU.doComputation.call(myMU, -1);
    } catch (e) {
      console.assert(!(e instanceof DOMException));
      console.assert(e instanceof otherWindow.DOMException);
    }

#### 3.12.4. Handling exceptions

Unless specified otherwise, whenever ECMAScript runtime semantics are invoked due to requirements in this document and end due to an exception being thrown, that exception must propagate to the caller, and if not caught there, to its caller, and so on.

Per Document conventions, an algorithm specified in this document may intercept thrown exceptions, either by specifying the exact steps to take if an exception was thrown, or by explicitly handling abrupt completions.

The following IDL fragment defines two interfaces and an exception. The `valueOf` attribute on `ExceptionThrower` is defined to throw an exception whenever an attempt is made to get its value.

    [Exposed=Window]
    interface Dahut {
      attribute DOMString type;
    };

    [Exposed=Window]
    interface ExceptionThrower {
      // This attribute always throws a NotSupportedError and never returns a value.
      attribute long valueOf;
    };

Assuming an ECMAScript implementation supporting this interface, the following code demonstrates how exceptions are handled:

    var d = getDahut();              // Obtain an instance of Dahut.
    var et = getExceptionThrower();  // Obtain an instance of ExceptionThrower.

    try {
      d.type = { toString: function() { throw "abc"; } };
    } catch (e) {
      // The string "abc" is caught here, since as part of the conversion
      // from the native object to a string, the anonymous function
      // was invoked, and none of the [[DefaultValue]], ToPrimitive or
      // ToString algorithms are defined to catch the exception.
    }

    try {
      d.type = { toString: { } };
    } catch (e) {
      // An exception is caught here, since an attempt is made to invoke
      // [[Call]] on the native object that is the value of toString
      // property.
    }

    try {
      d.type = Symbol();
    } catch (e) {
      // An exception is caught here, since an attempt is made to invoke
      // the ECMAScript ToString abstract operation on a Symbol value.
    }

    d.type = et;
    // An uncaught "NotSupportedError" DOMException is thrown here, since the
    // [[DefaultValue]] algorithm attempts to get the value of the
    // "valueOf" property on the ExceptionThrower object.  The exception
    // propagates out of this block of code.

### 3.13. Synthetic module records

A Synthetic Module Record is used to represent information about a module that is defined by specifications. The set of exported names is static, and determined at creation time (as an argument to CreateSyntheticModule), while the set of exported values can be changed over time using SetSyntheticModuleExport. It has no imports or dependencies.

Note: A Synthetic Module Record could be used for defining a variety of module types: for example, built-in modules, or JSON modules, or CSS modules.

Note: Synthetic Module Records are being developed in concert with the authors of the JavaScript Standard Library proposal, and might eventually move to the ECMAScript specification. [JSSTDLIB] [ECMA-262].

In addition to the Module Record Fields, Synthetic Module Records have the additional fields listed below. Each of these fields is initially set in CreateSyntheticModule.

Additional Fields of Synthetic Module Records
Field Name | Value Type | Meaning
--- | --- | ---
[[ExportNames]] | List of String | A List of all names that are exported.
[[EvaluationSteps]] | An abstract operation | An abstract operation that will be performed upon evaluation of the module, taking the Synthetic Module Record as its sole argument. These will usually set up the exported values, by using SetSyntheticModuleExport. They must not modify [[ExportNames]]. They may return an abrupt completion.

#### 3.13.1. CreateSyntheticModule

The abstract operation CreateSyntheticModule(exportNames, evaluationSteps, realm, hostDefined) creates a Synthetic Module Record based upon the given exported names and evaluation steps. It performs the following steps:

1. Return Synthetic Module Record { [[Realm]]: realm, [[Environment]]: undefined, [[Namespace]]: undefined, [[HostDefined]]: hostDefined, [[ExportNames]]: exportNames, [[EvaluationSteps]]: evaluationSteps }.

Note: we could set up [[Environment]] either here or in Link(). It is done in Link() for symmetry with Source Text Module Records, but there is no observable difference.

#### 3.13.2. SetSyntheticModuleExport

The abstract operation SetSyntheticModuleExport(module, exportName, exportValue) can be used to set or change the exported value for a pre-established export of a Synthetic Module Record. It performs the following steps:

1. Let envRec be module.[[Environment]]'s EnvironmentRecord.

2. Perform envRec.SetMutableBinding(exportName, exportValue, true).

#### 3.13.3. Concrete Methods

The following are the concrete methods for Synthetic Module Record that implement the corresponding Module Record abstract methods.

##### 3.13.3.1. GetExportedNames

The GetExportedNames(exportStarSet) concrete method of a Synthetic Module Record implements the corresponding Module Record abstract method.

It performs the following steps:

1. Let module be this Synthetic Module Record.

2. Return module.[[ExportNames]].

##### 3.13.3.2. ResolveExport

The ResolveExport(exportName, resolveSet) concrete method of a Synthetic Module Record implements the corresponding Module Record abstract method.

It performs the following steps:

1. Let module be this Synthetic Module Record.

2. If module.[[ExportNames]] does not contain exportName, return null.

3. Return ResolvedBinding Record { [[Module]]: module, [[BindingName]]: exportName }.

##### 3.13.3.3. Link

The Link() concrete method of a Synthetic Module Record implements the corresponding Module Record abstract method.

It performs the following steps:

1. Let module be this Synthetic Module Record.

2. Let realm be module.[[Realm]].

3. Assert: realm is not undefined.

4. Let env be NewModuleEnvironment(realm.[[GlobalEnv]]).

5. Set module.[[Environment]] to env.

6. Let envRec be env’s EnvironmentRecord.

7. For each exportName in module.[[ExportNames]],

   1. Perform ! envRec.CreateMutableBinding(exportName, false).

   2. Perform ! envRec.InitializeBinding(exportName, undefined).

8. Return undefined.

##### 3.13.3.4. Evaluate

The Evaluate() concrete method of a Synthetic Module Record implements the corresponding Module Record abstract method.

It performs the following steps:

1. Let module be this Synthetic Module Record.

2. Let moduleCxt be a new ECMAScript code execution context.

3. Set the Function of moduleCxt to null.

4. Assert: module.[[Realm]] is not undefined.

5. Set the Realm of moduleCxt to module.[[Realm]].

6. Set the ScriptOrModule of moduleCxt to module.

7. Set the VariableEnvironment of moduleCxt to module.[[Environment]].

8. Set the LexicalEnvironment of moduleCxt to module.[[Environment]].

9. Suspend the currently running execution context.

10. Push moduleCxt on to the execution context stack; moduleCxt is now the running execution context.

11. Let completion be the result of performing module.[[EvaluationSteps]](module).

12. Suspend moduleCxt and remove it from the execution context stack.

13. Resume the context that is now on the top of the execution context stack as the running execution context.

14. Return Completion(completion).

## 4. Common definitions

This section specifies some common definitions that all conforming implementations must support.

### 4.1. ArrayBufferView

    typedef (Int8Array or Int16Array or Int32Array or
             Uint8Array or Uint16Array or Uint32Array or Uint8ClampedArray or
             Float32Array or Float64Array or DataView) ArrayBufferView;

The `ArrayBufferView` typedef is used to represent objects that provide a view on to an `ArrayBuffer`.

### 4.2. BufferSource

    typedef (ArrayBufferView or ArrayBuffer) BufferSource;

The `BufferSource` typedef is used to represent objects that are either themselves an `ArrayBuffer` or which provide a view on to an `ArrayBuffer`.

### 4.3. DOMException

The `DOMException` type is an interface type defined by the following IDL fragment:

    [Exposed=(Window,Worker),
     Serializable]
    interface DOMException { // but see below note about ECMAScript binding
      constructor(optional DOMString message = "", optional DOMString name = "Error");
      readonly attribute DOMString name;
      readonly attribute DOMString message;
      readonly attribute unsigned short code;

      const unsigned short INDEX_SIZE_ERR = 1;
      const unsigned short DOMSTRING_SIZE_ERR = 2;
      const unsigned short HIERARCHY_REQUEST_ERR = 3;
      const unsigned short WRONG_DOCUMENT_ERR = 4;
      const unsigned short INVALID_CHARACTER_ERR = 5;
      const unsigned short NO_DATA_ALLOWED_ERR = 6;
      const unsigned short NO_MODIFICATION_ALLOWED_ERR = 7;
      const unsigned short NOT_FOUND_ERR = 8;
      const unsigned short NOT_SUPPORTED_ERR = 9;
      const unsigned short INUSE_ATTRIBUTE_ERR = 10;
      const unsigned short INVALID_STATE_ERR = 11;
      const unsigned short SYNTAX_ERR = 12;
      const unsigned short INVALID_MODIFICATION_ERR = 13;
      const unsigned short NAMESPACE_ERR = 14;
      const unsigned short INVALID_ACCESS_ERR = 15;
      const unsigned short VALIDATION_ERR = 16;
      const unsigned short TYPE_MISMATCH_ERR = 17;
      const unsigned short SECURITY_ERR = 18;
      const unsigned short NETWORK_ERR = 19;
      const unsigned short ABORT_ERR = 20;
      const unsigned short URL_MISMATCH_ERR = 21;
      const unsigned short QUOTA_EXCEEDED_ERR = 22;
      const unsigned short TIMEOUT_ERR = 23;
      const unsigned short INVALID_NODE_TYPE_ERR = 24;
      const unsigned short DATA_CLONE_ERR = 25;
    };

Note: as discussed in § 3.12.1 DOMException custom bindings, the ECMAScript binding imposes additional requirements beyond the normal ones for interface types.

Each `DOMException` object has an associated name and message, both JavaScript strings.

The `DOMException(message, name)` constructor, when invoked, must run these steps:

1. Set this’s name to name.

2. Set this’s message to message.

The `name` attribute’s getter must return this `DOMException` object’s name.

The `message` attribute’s getter must return this `DOMException` object’s message.

The `code` attribute’s getter must return the legacy code indicated in the error names table for this `DOMException` object’s name, or 0 if no such entry exists in the table.

`DOMException` objects are serializable objects.

Their serialization steps, given value and serialized, are:

1. Set serialized.[[Name]] to value’s name.
2. Set serialized.[[Message]] to value’s message.
3. User agents should attach a serialized representation of any interesting accompanying data which are not yet specified, notably the `stack` property, to serialized.

Their deserialization steps, given value and serialized, are:

1. Set value’s name to serialized.[[Name]].
2. Set value’s message to serialized.[[Message]].
3. If any other data is attached to serialized, then deserialize and attach it to value.

### 4.4. DOMTimeStamp

    typedef unsigned long long DOMTimeStamp;

The `DOMTimeStamp` type is used for representing a number of milliseconds, either as an absolute time (relative to some epoch) or as a relative amount of time. Specifications that use this type will need to define how the number of milliseconds is to be interpreted.

### 4.5. Function

    callback Function = any (any... arguments);

The `Function` callback function type is used for representing function values with no restriction on what arguments are passed to it or what kind of value is returned from it.

### 4.6. VoidFunction

    callback VoidFunction = void ();

The `VoidFunction` callback function type is used for representing function values that take no arguments and do not return any value.

## 5. Extensibility

This section is informative.

Extensions to language binding requirements can be specified using extended attributes that do not conflict with those defined in this document. Extensions for private, project-specific use should not be included in IDL fragments appearing in other specifications. It is recommended that extensions that are required for use in other specifications be coordinated with the group responsible for work on Web IDL, which at the time of writing is the W3C Web Platform Working Group, for possible inclusion in a future version of this document.

Extensions to any other aspect of the IDL language are strongly discouraged.

## 6. Legacy constructs

This section is informative.

Legacy WebIDL constructs exist only so that legacy Web platform features can be specified. They are generally prefixed with the "`Legacy`" string. It is strongly discouraged to use legacy WebIDL constructs in specifications unless required to specify the behavior of legacy Web platform features, or for consistency with such features. Editors who wish to use legacy WebIDL constructs are strongly advised to discuss this by filing an issue before proceeding.

Marking a construct as legacy does not, in itself, imply that it is about to be removed from this specification. It does suggest however, that it is a good candidate for future removal from this specification, whenever various heuristics indicate that the Web platform features it helps specify can be removed altogether or can be modified to rely on non-legacy WebIDL constructs instead.

## 7. Referencing this specification

This section is informative.

It is expected that other specifications that define Web platform interfaces using one or more IDL fragments will reference this specification. It is suggested that those specifications include a sentence such as the following, to indicate that the IDL is to be interpreted as described in this specification:

> The IDL fragment in Appendix A of this specification must, in conjunction with the IDL fragments defined in this specification’s normative references, be interpreted as required for conforming sets of IDL fragments, as described in the “Web IDL” specification. [WEBIDL]

In addition, it is suggested that the conformance class for user agents in referencing specifications be linked to the conforming implementation class from this specification:

> A conforming FooML user agent must also be a conforming implementation of the IDL fragment in Appendix A of this specification, as described in the “Web IDL” specification. [WEBIDL]

## 8. Privacy and Security Considerations

This specification defines a conversion layer between JavaScript and IDL values. An incorrect implementation of this layer can lead to security issues.

This specification also provides the ability to use JavaScript values directly, through the `any` and `object` IDL types. These values need to be handled carefully to avoid security issues. In particular, user script can run in response to nearly any manipulation of these values, and invalidate the expectations of specifications or implementations using them.

This specification makes it possible to interact with `SharedArrayBuffer` objects, which can be used to build timing attacks. Specifications that use these objects need to consider such attacks.

## 9. Acknowledgements

This section is informative.

The editor would like to thank the following people for contributing to this specification: Glenn Adams, David Andersson, Jake Archibald, L. David Baron, Art Barstow, Nils Barth, Robin Berjon, David Bruant, Jan-Ivar Bruaroey, Marcos Cáceres, Giovanni Campagna, Domenic Denicola, Chris Dumez, Michael Dyck, Daniel Ehrenberg, Brendan Eich, João Eiras, Gorm Haug Eriksen, Sigbjorn Finne, David Flanagan, Aryeh Gregor, Dimitry Golubovsky, James Graham, Aryeh Gregor, Tiancheng “Timothy” Gu, Kartikaya Gupta, Marcin Hanclik, Jed Hartman, Stefan Haustein, Dominique Hazaël-Massieux, Ian Hickson, Björn Höhrmann, Kyle Huey, Lachlan Hunt, Oliver Hunt, Jim Jewett, Wolfgang Keller, Anne van Kesteren, Olav Junker Kjær, Takayoshi Kochi, Magnus Kristiansen, Takeshi Kurosawa, Yves Lafon, Travis Leithead, Jim Ley, Kevin Lindsey, Jens Lindström, Peter Linss, 呂康豪 (Kang-Hao Lu), Kyle Machulis, Darien Maillet Valentine, Mark Miller, Ms2ger, Andrew Oakley, 岡坂 史紀 (Shiki Okasaka), Jason Orendorff, Olli Pettay, Simon Pieters, Andrei Popescu, François Remy, Tim Renouf, Tim Ruffles, Alex Russell, Takashi Sakamoto, Doug Schepers, Jonas Sicking, Garrett Smith, Sam Sneddon, Jungkee Song, Josh Soref, Maciej Stachowiak, Anton Tayanovskyy, triple-underscore, Peter Van der Beken, Jeff Walden, Allen Wirfs-Brock, Jeffrey Yasskin and, Collin Xu.

Special thanks also go to Sam Weinig for maintaining this document while the editor was unavailable to do so.

## IDL grammar

This section defines an LL(1) grammar whose start symbol, Definitions, matches an entire IDL fragment.

Each production in the grammar has on its right hand side either a non-zero sequence of terminal and non-terminal symbols, or an epsilon (ε) which indicates no symbols. Symbols that begin with an uppercase letter are non-terminal symbols. Symbols in monospaced fonts are terminal symbols. Symbols in sans-serif font that begin with a lowercase letter are terminal symbols that are matched by the regular expressions (using Perl 5 regular expression syntax [PERLRE]) as follows:

integer | `=` | `/-?([1-9][0-9]*|0[Xx][0-9A-Fa-f]+|0[0-7]*)/`
decimal | `=` | `/-?(([0-9]+\.[0-9]*|[0-9]*\.[0-9]+)([Ee][+-]?[0-9]+)?|[0-9]+[Ee][+-]?[0-9]+)/`
identifier | `=` | `/[_-]?[A-Za-z][0-9A-Z_a-z-]*/`
string | `=` | `/"[^"]*"/`
whitespace | `=` | `/[\t\n\r ]+/`
comment | `=` | `/\/\/.*|\/\*(.|\n)*?\*\//`
other | `=` | `/[^\t\n\r 0-9A-Za-z]/`

The tokenizer operates on a sequence of Unicode characters [UNICODE]. When tokenizing, the longest possible match must be used. For example, if the input text is “a1”, it is tokenized as a single identifier, and not as a separate identifier and integer. If the longest possible match could match one of the above named terminal symbols or one of the other terminal symbols from the grammar, it must be tokenized as the latter. Thus, the input text “long” is tokenized as the quoted terminal symbol long rather than an identifier called "`long`", and “.” is tokenized as the quoted terminal symbol . rather than an other.

The IDL syntax is case sensitive, both for the quoted terminal symbols used in the grammar and the values used for identifier terminals. Thus, for example, the input text “Const” is tokenized as an identifier rather than the terminal symbol const, an interface with identifier "`A`" is distinct from one named "`a`", and an extended attribute [`namedconstructor`] will not be recognized as the [`NamedConstructor`] extended attribute.

Implicitly, any number of whitespace and comment terminals are allowed between every other terminal in the input text being parsed. Such whitespace and comment terminals are ignored while parsing.

The following LL(1) grammar, starting with Definitions, matches an IDL fragment:

Note: The Other non-terminal matches any single terminal symbol except for (, ), [, ], {, } and ,.

While the ExtendedAttribute non-terminal matches any non-empty sequence of terminal symbols (as long as any parentheses, square brackets or braces are balanced, and the , token appears only within those balanced brackets), only a subset of those possible sequences are used by the extended attributes defined in this specification — see § 2.14 Extended attributes for the syntaxes that are used by these extended attributes.

## Document conventions

The following typographic conventions are used in this document:

- Defining instances of terms: example term

- Links to terms defined in this document or elsewhere: example term

- Grammar terminals: sometoken

- Grammar non-terminals: ExampleGrammarNonTerminal

- Grammar symbols: identifier

- IDL types: `unsigned long`

- ECMAScript classes: `Map`

- ECMAScript language types: Object

- Code snippets: `a = b + obj.f()`

- Unicode characters: U+0030 DIGIT ZERO ("0")

- Extended attributes: [`ExampleExtendedAttribute`]

- Variable names in prose and algorithms: exampleVariableName.

- IDL informal syntax examples:

      [extended_attributes]
      interface identifier {
        /* interface_members... */
      };

  (Specific parts of the syntax discussed in surrounding prose are highlighted.)

- IDL grammar snippets:

      ExampleGrammarNonTerminal :
          OtherNonTerminal "sometoken"
          other AnotherNonTerminal
          ε  // nothing

- Non-normative notes:

  Note: This is a note.

- Non-normative examples:

  This is an example.

- Normative warnings:

  This is a warning.

- Code blocks:

      // This is an IDL code block.
      [Exposed=Window]
      interface Example {
        attribute long something;
      };

      // This is an ECMAScript code block.
      window.onload = function() { window.alert("loaded"); };

The following conventions are used in the algorithms in this document:

- Algorithms use the conventions of the ECMAScript specification, including the ! and ? notation for unwrapping Completion Records.

- Algorithms sometimes treat returning/throwing values and returning Completion Records interchangeably. That is, an algorithm that uses return/throw terminology may be treated as returning a Completion Record, while one that returns a Completion Record may be treated as returning a value or throwing an exception. Similarly, to catch exceptions, defining the behavior to adopt when an exception was thrown and checking if the Completion Record’s [[Type]] field is “throw” are equivalent.

- Completion Records are extended by allowing them to contain values that are not ECMAScript values, such as Web IDL values.

## Conformance

Everything in this specification is normative except for diagrams, examples, notes and sections marked as being informative.

This specification depends on the Infra Standard. [INFRA]

The following conformance classes are defined by this specification:

conforming set of IDL fragments

  A set of IDL fragments is considered to be a conforming set of IDL fragments if, taken together, they satisfy all of the must-, required- and shall-level criteria in this specification that apply to IDL fragments.

conforming implementation

  A user agent is considered to be a conforming implementation relative to a conforming set of IDL fragments if it satisfies all of the must-, required- and shall-level criteria in this specification that apply to implementations for all language bindings that the user agent supports.

conforming ECMAScript implementation

  A user agent is considered to be a conforming ECMAScript implementation relative to a conforming set of IDL fragments if it satisfies all of the must-, required- and shall-level criteria in this specification that apply to implementations for the ECMAScript language binding.

.

## Index

### Terms defined by this specification

- ABORT_ERR, in §2.8.1
- AbortError, in §2.8.1
- AllowShared, in §3.3
- a new promise, in §3.2.22.1
- an exception was thrown, in §3.12.4
- annotated types, in §2.13.31
- any, in §2.13
- applicable to types, in §2.13.31
- a promise rejected with, in §3.2.22.1
- a promise resolved with, in §3.2.22.1
- ArrayBuffer, in §2.13.32
- ArrayBufferView, in §4
- associated Realm, in §3.1
- asynchronous iterator initialization steps, in §2.5.9
- asynchronous iterator prototype object, in §3.6.9.7
- asynchronous iterator return, in §2.5.9
- asynchronously iterable declaration, in §2.5.9
- attribute, in §2.5.2
- attribute getter, in §3.6.6
- attribute setter, in §3.6.6
- available in both secure and non-secure contexts, in §3.3.19
- available only in secure contexts, in §3.3.19
- boolean, in §2.13.2
- BufferSource, in §4.1
- buffer source types, in §2.13
- byte, in §2.13.3
- ByteString, in §2.13.16
- callable, in §2.5.7
- call a user object’s operation, in §3.9
- callback context, in §2.13.22
- callback function, in §2.10
- Callback function types, in §2.13.24
- callback interface, in §2.4
- callback interface member, in §2.4
- Callback interface types, in §2.13.21
- callback this value, in §3.9
- change, in §3.7
- Clamp, in §3.3.1
- class string, in §3
- code, in §4.3
- code units, in §2.5.3
- collect attribute values, in §3.6.7.1.1
- collect attribute values of an inheritance stack, in §3.6.7.1.1
- compute the effective overload set, in §2.5.7
- conforming ECMAScript implementation, in §Unnumbered section
- conforming implementation, in §Unnumbered section
- conforming set of IDL fragments, in §Unnumbered section
- constant, in §2.5.1
- ConstraintError, in §2.8.1
- construct, in §3.10
- constructor(), in §4.3
- constructor(message), in §4.3
- constructor(message, name), in §4.3
- Constructor operations, in §2.5.3.1
- converted to an ECMAScript value, in §3.2
- converted to an IDL value, in §3.2
- converted to ECMAScript values, in §3.2
- converted to IDL values, in §3.2
- converting, in §3.9
- convert to a sequence of Unicode scalar values, in §2.13.16
- ConvertToInt, in §3.2.4.9
- corresponding default operation, in §3.6.7.1
- create a frozen array, in §3.2.25
- create a legacy callback interface object, in §3.9.1
- create a named constructor, in §3.6.2
- create a named properties object, in §3.6.4
- create a namespace object, in §3.11.1
- create an inheritance stack, in §3.6.7.1.1
- create an interface object, in §3.6.1
- create an interface prototype object, in §3.6.3
- created, in §2.8
- CreateSyntheticModule, in §3.13.1
- Creating a frozen array from an iterable, in §3.2.25
- creating an operation function, in §3.6.7
- Creating a sequence from an iterable, in §3.2.20
- current state, in §2.5.9
- DATA_CLONE_ERR, in §2.8.1
- DataCloneError, in §2.8.1
- DataError, in §2.8.1
- DataView, in §2.13.32
- Default, in §3.3.2
- default asynchronous iterator object, in §3.6.9.6
- default iterator object, in §3.6.9.4
- default toJSON operation, in §3.6.7.1.1
- default value
  - dfn for dictionary member, in §2.7
  - dfn for optional argument, in §2.5.3
- define the attributes, in §3.6.6
- define the constants, in §3.6.5
- define the global property references, in §3.7
- define the operations, in §3.6.7
- define the regular attributes, in §3.6.6
- define the regular operations, in §3.6.7
- define the static attributes, in §3.6.6
- define the static operations, in §3.6.7
- define the unforgeable regular attributes, in §3.6.6
- define the unforgeable regular operations, in §3.6.7
- definitions, in §2
- delete an existing named property, in §2.5.5.3
- deleter, in §2.5.5
- detach, in §3.2.24
- determine the value of a named property, in §2.5.5.3
- determine the value of an indexed property, in §2.5.5.2
- dictionary, in §2.7
- dictionary members, in §2.7
- Dictionary types, in §2.13.22
- distinguishable, in §2.5.7
- distinguishing argument index, in §2.5.7
- DOMException, in §4.2
- DOMException(), in §4.3
- DOMException(message), in §4.3
- DOMException(message, name), in §4.3
- DOMString, in §2.13.15
- DOMSTRING_SIZE_ERR, in §2.8.1
- DOMStringSizeError, in §2.8.1
- DOMTimeStamp, in §4.3
- double, in §2.13.13
- ECMAScript throw, in §3
- effective overload set, in §2.5.7
- EncodingError, in §2.8.1
- EnforceRange, in §3.3.3
- enumeration, in §2.9
- Enumeration types, in §2.13.23
- enumeration value, in §2.9
- error name, in §2.8
- error names table, in §2.8.1
- EvalError, in §2.8
- Evaluate, in §3.13.3.4
- example term, in §Unnumbered section
- exception, in §2.8
- Exception objects, in §3.12.1
- Exposed, in §3.3.4
- exposed, in §3.3.5
- exposure set, in §3.3.5
- extended attribute, in §2.14
- extended attribute associated with, in §2.13.31
- extended attributes associated with, in §2.13.31
- flattened member types, in §2.13.30
- float, in §2.13.11
- Float32Array, in §2.13.32
- Float64Array, in §2.13.32
- forwards to the internal map object, in §3.6.10
- forwards to the internal set object, in §3.6.11
- FrozenArray, in §2.13.32
- FrozenArray<T>, in §2.13.32
- frozen array type, in §2.13.33
- Function, in §4.4
- get a copy of the buffer source, in §2.13.32
- get a promise to wait for all, in §3.2.22.1
- get a reference to the buffer source, in §2.13.32
- GetExportedNames, in §3.13.3.1
- GetOwnProperty, in §3.8
- getter, in §2.5.5
- get the next iteration result, in §2.5.9
- get the underlying value, in §2.5.2
- getting a promise to wait for all, in §3.2.22.1
- Global, in §3.3.5
- global names, in §3.3.6
- HIERARCHY_REQUEST_ERR, in §2.8.1
- HierarchyRequestError, in §2.8.1
- host interfaces, in §2.3
- identifier, in §2.1
- IDL fragment, in §2
- implements, in §3.7
- include, in §2.3
- includes a nullable type, in §2.13.30
- includes statement, in §2.3
- inclusive inherited interfaces, in §2.2
- Indexed properties, in §2.5.5.1
- indexed property getter, in §2.5.5
- indexed property setter, in §2.5.5
- INDEX_SIZE_ERR, in §2.8.1
- IndexSizeError, in §2.8.1
- inherit
  - dfn for dictionary, in §2.7
  - dfn for interface, in §2.2
- inherited dictionaries, in §2.7
- inherited interfaces, in §2.2
- inherit its getter, in §2.5.2
- initial objects, in §3.1
- inner type
  - dfn for annotated types, in §2.13.31
  - dfn for nullable types, in §2.13.26
- Int16Array, in §2.13.32
- Int32Array, in §2.13.32
- Int8Array, in §2.13.32
- IntegerPart, in §3.2.4.9
- integer types, in §2.13
- interface, in §2.2
- interface member, in §2.2
- interface mixin, in §2.3
- interface mixin member, in §2.3
- interface object, in §3.6
- interface prototype object, in §3.6.3
- Interface types, in §2.13.20
- internally create a new object implementing the interface, in §3.7
- INUSE_ATTRIBUTE_ERR, in §2.8.1
- InUseAttributeError, in §2.8.1
- INVALID_ACCESS_ERR, in §2.8.1
- InvalidAccessError, in §2.8.1
- INVALID_CHARACTER_ERR, in §2.8.1
- InvalidCharacterError, in §2.8.1
- INVALID_MODIFICATION_ERR, in §2.8.1
- InvalidModificationError, in §2.8.1
- INVALID_NODE_TYPE_ERR, in §2.8.1
- InvalidNodeTypeError, in §2.8.1
- INVALID_STATE_ERR, in §2.8.1
- InvalidStateError, in §2.8.1
- invoke, in §3.10
- invoke the indexed property setter, in §3.8.7
- invoke the named property setter, in §3.8.7
- is an array index, in §3.8.7
- is a platform object, in §3.7
- is finished, in §3.6.9.6
- is not an array index, in §3.8.7
- iterable, in §2.5.8
- iterable declaration, in §2.5.8
- iterator prototype object, in §3.6.9.5
- iterator result, in §3.6.9.5
- JSON type, in §2.5.3.1
- key, in §2.5.8
- kind, in §3.6.9.6
- legacy callback interface object, in §3.9.1
- LegacyNamespace, in §3.3.6
- LegacyPlatformObjectGetOwnProperty, in §3.8.7
- Legacy platform objects, in §2.12
- LegacyUnenumerableNamedProperties, in §3.3.7
- LegacyWindowAlias, in §3.3.8
- LegacyWindowAlias identifier, in §3.3.9
- LenientSetter, in §3.3.9
- LenientThis, in §3.3.10
- Link, in §3.13.3.3
- long, in §2.13.7
- long long, in §2.13.9
- map entries, in §2.5.10
- maplike, in §2.5.10
- maplike declaration, in §2.5.10
- map size getter, in §3.6.10.1
- members, in §2.5
- member types, in §2.13.30
- message
  - attribute for DOMException, in §4.3
  - dfn for DOMException, in §4.3
  - dfn for exception, in §2.8
- name
  - attribute for DOMException, in §4.3
  - dfn for DOMException, in §4.3
- named constructor, in §3.6
- NamedConstructor, in §3.3.11
- NamedConstructor identifier, in §3.3.12
- named definition, in §2.1
- Named properties, in §2.5.5.2
- named properties object, in §3.6.4
- named property deleter, in §2.5.5
- named property getter, in §2.5.5
- named property setter, in §2.5.5
- named property visibility algorithm, in §3.8.7
- namespace, in §2.6
- NAMESPACE_ERR, in §2.8.1
- NamespaceError, in §2.8.1
- namespace member, in §2.6
- namespace object, in §3.11
- NETWORK_ERR, in §2.8.1
- NetworkError, in §2.8.1
- new, in §3.7
- NewObject, in §3.3.12
- NO_DATA_ALLOWED_ERR, in §2.8.1
- NoDataAllowedError, in §2.8.1
- NoInterfaceObject, in §3.3.13
- NO_MODIFICATION_ALLOWED_ERR, in §2.8.1
- NoModificationAllowedError, in §2.8.1
- NotAllowedError, in §2.8.1
- NOT_FOUND_ERR, in §2.8.1
- NotFoundError, in §2.8.1
- not present, in §2.7
- NotReadableError, in §2.8.1
- NOT_SUPPORTED_ERR, in §2.8.1
- NotSupportedError, in §2.8.1
- nullable type, in §2.13.26
- number of nullable member types, in §2.13.30
- numeric types, in §2.13
- object, in §2.13.18
- object types, in §2.13
- obtain Unicode, in §2.13.16
- octet, in §2.13.4
- ongoing promise, in §3.6.9.6
- operation, in §2.5.3
- OperationError, in §2.8.1
- optional argument, in §2.5.3
- optionality list, in §2.5.7
- optionality values, in §2.5.7
- overloaded, in §2.5.7
- overload resolution algorithm, in §3.5
- overridden constructor steps, in §3.6.1
- OverrideBuiltins, in §3.3.14
- own exposure set, in §3.3.5
- pair iterator, in §2.5.8
- partial dictionary, in §2.7
- partial interface, in §2.2
- partial interface mixin, in §2.3
- partial namespace, in §2.6
- perform a security check, in §3.4
- platform object, in §2.12
- present, in §2.7
- primary interface, in §3.7
- primitive types, in §2.13
- Promise, in §2.13.28
- Promise<T>, in §2.13.28
- promise type, in §2.13.29
- PutForwards, in §3.3.15
- qualified name, in §2.2
- QUOTA_EXCEEDED_ERR, in §2.8.1
- QuotaExceededError, in §2.8.1
- RangeError, in §2.8
- react, in §3.2.22.1
- reacting, in §3.2.22.1
- read only, in §2.5.2
- ReadOnlyError, in §2.8.1
- ready promise, in §3.2.22.2
- record, in §2.13.27
- record type, in §2.13.28
- ReferenceError, in §2.8
- regular attribute, in §2.5.2
- regular operation, in §2.5.3
- reject, in §3.2.22.1
- Replaceable, in §3.3.16
- required dictionary member, in §2.7
- reserved identifiers, in §2.1
- resolve, in §3.2.22.1
- ResolveExport, in §3.13.3.2
- return type, in §2.5.3
- SameObject, in §3.3.17
- SecureContext, in §3.3.18
- SECURITY_ERR, in §2.8.1
- SecurityError, in §2.8.1
- sequence, in §2.13.26
- sequence type, in §2.13.27
- set entries, in §2.5.11
- setlike, in §2.5.11
- setlike declaration, in §2.5.11
- set size getter, in §3.6.11.1
- SetSyntheticModuleExport, in §3.13.2
- setter, in §2.5.5
- set the value of a new indexed property, in §2.5.5.2
- set the value of a new named property, in §2.5.5.3
- set the value of an existing indexed property, in §2.5.5.2
- set the value of an existing named property, in §2.5.5.3
- short, in §2.13.5
- simple exception, in §2.8
- special keyword, in §2.5.5
- special operation, in §2.5.5
- specific type, in §2.13.1
- Static attributes, in §2.5.6
- static operations, in §2.5.6
- stringification behavior, in §2.5.5.1
- stringifier, in §2.5.5
- string types, in §2.13
- supported property indices, in §2.5.5.2
- supported property names, in §2.5.5.3
- support indexed properties, in §2.5.5.2
- support named properties, in §2.5.5.3
- symbol, in §2.13.19
- SYNTAX_ERR, in §2.8.1
- SyntaxError, in §2.8.1
- Synthetic Module Record, in §3.13
- takes a named argument list, in §2.14
- takes an argument list, in §2.14
- takes an identifier, in §2.14
- takes an identifier list, in §2.14
- takes no arguments, in §2.14
- target, in §3.6.9.6
- the given value, in §2.5
- this, in §2.5
- throw
  - dfn for ECMAScript, in §3
  - dfn for exception, in §2.8
- TIMEOUT_ERR, in §2.8.1
- TimeoutError, in §2.8.1
- TransactionInactiveError, in §2.8.1
- TreatNonObjectAsNull, in §3.3.19
- TreatNullAs, in §3.3.20
- type being given a new name, in §2.11
- typed array types, in §2.13
- typedef, in §2.11
- TypeError, in §2.8
- type list, in §2.5.7
- TYPE_MISMATCH_ERR, in §2.8.1
- TypeMismatchError, in §2.8.1
- type name, in §2.13
- Uint16Array, in §2.13.32
- Uint32Array, in §2.13.32
- Uint8Array, in §2.13.32
- Uint8ClampedArray, in §2.13.32
- Unforgeable, in §3.3.21
- unforgeable, in §3.3.22
- unforgeable property name, in §3.8
- union type, in §2.13.30
- UnknownError, in §2.8.1
- unrestricted double, in §2.13.14
- unrestricted float, in §2.13.12
- Unscopable, in §3.3.22
- unsigned long, in §2.13.8
- unsigned long long, in §2.13.10
- unsigned short, in §2.13.6
- upon fulfillment, in §3.2.22.1
- upon rejection, in §3.2.22.1
- URIError, in §2.8
- URL_MISMATCH_ERR, in §2.8.1
- URLMismatchError, in §2.8.1
- USVString, in §2.13.17
- VALIDATION_ERR, in §2.8.1
- ValidationError, in §2.8.1
- value, in §2.5.8
- value iterator, in §2.5.8
- value of string literal tokens, in §2.5.3
- value pair, in §2.5.8
- value pairs to iterate over, in §2.5.8
- variadic, in §2.5.3
- VersionError, in §2.8.1
- void, in §2.13.1
- VoidFunction, in §4.5
- wait for all, in §3.2.22.1
- waiting for all, in §3.2.22.1
- Web IDL arguments list, in §3.9
- WRONG_DOCUMENT_ERR, in §2.8.1
- WrongDocumentError, in §2.8.1

https://www.khronos.org/registry/webgl/extensions/ANGLE_instanced_arrays/#angle_instanced_arrays Referenced in:

- 3.3.14. [NoInterfaceObject]

https://drafts.csswg.org/css-conditional-3/#dom-css-supports-conditiontext Referenced in:

- 2.5.7.1. Overloading vs. union types

https://drafts.csswg.org/css-conditional-3/#dom-css-supports Referenced in:

- 2.5.7.1. Overloading vs. union types

https://drafts.csswg.org/cssom-1/#namespacedef-css Referenced in:

- 2.5.7.1. Overloading vs. union types

https://dom.spec.whatwg.org/#document Referenced in:

- 3.3.10. [LenientSetter]
- 3.3.11. [LenientThis]
- 3.3.13. [NewObject]
- 3.3.15. [OverrideBuiltins]
- 3.3.18. [SameObject] (2)

https://dom.spec.whatwg.org/#documentorshadowroot Referenced in:

- 3.3.10. [LenientSetter]

https://dom.spec.whatwg.org/#callbackdef-eventlistener Referenced in:

- 2.4. Callback interfaces
- 2.12. Objects implementing interfaces

https://dom.spec.whatwg.org/#htmlcollection Referenced in:

- 3.3.8. [LegacyUnenumerableNamedProperties]

https://dom.spec.whatwg.org/#namednodemap Referenced in:

- 3.3.8. [LegacyUnenumerableNamedProperties]

https://dom.spec.whatwg.org/#dom-document-createelement Referenced in:

- 3.3.13. [NewObject]

https://dom.spec.whatwg.org/#concept-document Referenced in:

- 2.8.1. Error names

https://dom.spec.whatwg.org/#dom-document-implementation Referenced in:

- 3.3.18. [SameObject]

https://dom.spec.whatwg.org/#concept-node-tree Referenced in:

- 2.8.1. Error names

https://tc39.github.io/ecma262/#sec-returnifabrupt-shorthands Referenced in:

- 3.2.4.1. byte
- 3.2.4.2. octet
- 3.2.4.3. short
- 3.2.4.4. unsigned short
- 3.2.4.5. long
- 3.2.4.6. unsigned long
- 3.2.4.7. long long
- 3.2.4.8. unsigned long long
- 3.2.4.9. Abstract operations (2) (3)
- 3.2.5. float
- 3.2.6. unrestricted float
- 3.2.7. double
- 3.2.8. unrestricted double
- 3.2.16. Dictionary types (2) (3)
- 3.2.20. Sequences — sequence<T>
- 3.2.20.1. Creating a sequence from an iterable (2) (3)
- 3.2.21. Records — record<K, V> (2) (3) (4) (5)
- 3.2.22. Promise types — Promise<T> (2)
- 3.2.22.1. Creating and manipulating Promises (2) (3) (4) (5) (6) (7) (8) (9) (10) (11) (12) (13)
- 3.2.23. Union types (2)
- 3.2.24. Buffer source types
- 3.5. Overload resolution algorithm
- 3.6.1. Interface object (2) (3) (4)
- 3.6.2. Named constructors (2) (3) (4)
- 3.6.3. Interface prototype object (2) (3) (4) (5)
- 3.6.4.4. [[SetPrototypeOf]]
- 3.6.5. Constants
- 3.6.6. Attributes (2) (3) (4) (5) (6) (7) (8) (9) (10) (11) (12)
- 3.6.7. Operations (2) (3) (4) (5)
- 3.6.7.1.1. Default toJSON operation (2)
- 3.6.8.3. forEach (2) (3)
- 3.6.9.7. Asynchronous iterator prototype object (2) (3) (4) (5) (6) (7) (8) (9) (10) (11) (12) (13) (14) (15) (16) (17) (18) (19) (20)
- 3.6.10. Maplike declarations (2)
- 3.6.10.4. get and has (2)
- 3.6.10.6. delete (2)
- 3.6.10.7. set (2)
- 3.6.11. Setlike declarations (2)
- 3.6.11.4. has (2)
- 3.6.11.5. add and delete (2)
- 3.7. Platform objects implementing interfaces (2) (3) (4) (5) (6) (7) (8) (9)
- 3.7.1. [[SetPrototypeOf]]
- 3.8.2. [[Set]]
- 3.8.6. [[OwnPropertyKeys]]
- 3.8.7. Abstract operations
- 3.9. Callback interfaces (2) (3)
- 3.9.1. Legacy callback interface object (2) (3)
- 3.10. Invoking callback functions (2) (3)
- 3.11.1. Namespace object (2)
- 3.12.3. Creating and throwing exceptions
- 3.13.3.3. Link (2)
- Document conventions (2)

https://tc39.github.io/ecma262/#sec-array.prototype.entries Referenced in:

- 3.6.9.1. entries

https://tc39.github.io/ecma262/#sec-array.prototype.foreach Referenced in:

- 3.6.8.3. forEach

https://tc39.github.io/ecma262/#sec-array.prototype.keys Referenced in:

- 3.6.9.2. keys

https://tc39.github.io/ecma262/#sec-array.prototype.values Referenced in:

- 3.6.8.1. @@iterator

https://tc39.github.io/ecma262/#sec-asynciteratorprototype Referenced in:

- 3.6.9.7. Asynchronous iterator prototype object

https://tc39.github.io/ecma262/#sec-properties-of-the-error-prototype-object Referenced in:

- 3.6.3. Interface prototype object
- 3.12.1. DOMException custom bindings

https://tc39.github.io/ecma262/#sec-properties-of-the-function-prototype-object Referenced in:

- 3.6.1. Interface object

https://tc39.github.io/ecma262/#sec-%iteratorprototype%-object Referenced in:

- 3.6.9.5. Iterator prototype object

https://tc39.github.io/ecma262/#sec-properties-of-the-object-prototype-object Referenced in:

- 2.6. Namespaces
- 3. ECMAScript binding
- 3.2.16. Dictionary types
- 3.2.21. Records — record<K, V>
- 3.6.3. Interface prototype object
- 3.6.4. Named properties object
- 3.6.7.1.1. Default toJSON operation
- 3.11.1. Namespace object

https://tc39.github.io/ecma262/#sec-promise-constructor Referenced in:

- 3.2.22. Promise types — Promise<T>
- 3.2.22.1. Creating and manipulating Promises (2) (3) (4)
- 3.6.6. Attributes
- 3.6.7. Operations
- 3.6.9.7. Asynchronous iterator prototype object (2) (3) (4)
- 3.9. Callback interfaces
- 3.10. Invoking callback functions

https://tc39.github.io/ecma262/#sec-promise.prototype.then Referenced in:

- 3.2.22.1. Creating and manipulating Promises

https://tc39.github.io/ecma262/#sec-promise.reject Referenced in:

- 3.6.6. Attributes
- 3.6.7. Operations
- 3.9. Callback interfaces
- 3.10. Invoking callback functions

https://tc39.github.io/ecma262/#sec-returnifabrupt-shorthands Referenced in:

- 3.2.4.1. byte
- 3.2.4.2. octet
- 3.2.4.3. short
- 3.2.4.4. unsigned short
- 3.2.4.5. long
- 3.2.4.6. unsigned long
- 3.2.4.7. long long
- 3.2.4.8. unsigned long long
- 3.2.4.9. Abstract operations (2) (3)
- 3.2.5. float
- 3.2.6. unrestricted float
- 3.2.7. double
- 3.2.8. unrestricted double
- 3.2.16. Dictionary types (2) (3)
- 3.2.20. Sequences — sequence<T>
- 3.2.20.1. Creating a sequence from an iterable (2) (3)
- 3.2.21. Records — record<K, V> (2) (3) (4) (5)
- 3.2.22. Promise types — Promise<T> (2)
- 3.2.22.1. Creating and manipulating Promises (2) (3) (4) (5) (6) (7) (8) (9) (10) (11) (12) (13)
- 3.2.23. Union types (2)
- 3.2.24. Buffer source types
- 3.5. Overload resolution algorithm
- 3.6.1. Interface object (2) (3) (4)
- 3.6.2. Named constructors (2) (3) (4)
- 3.6.3. Interface prototype object (2) (3) (4) (5)
- 3.6.4.4. [[SetPrototypeOf]]
- 3.6.5. Constants
- 3.6.6. Attributes (2) (3) (4) (5) (6) (7) (8) (9) (10) (11) (12)
- 3.6.7. Operations (2) (3) (4) (5)
- 3.6.7.1.1. Default toJSON operation (2)
- 3.6.8.3. forEach (2) (3)
- 3.6.9.7. Asynchronous iterator prototype object (2) (3) (4) (5) (6) (7) (8) (9) (10) (11) (12) (13) (14) (15) (16) (17) (18) (19) (20)
- 3.6.10. Maplike declarations (2)
- 3.6.10.4. get and has (2)
- 3.6.10.6. delete (2)
- 3.6.10.7. set (2)
- 3.6.11. Setlike declarations (2)
- 3.6.11.4. has (2)
- 3.6.11.5. add and delete (2)
- 3.7. Platform objects implementing interfaces (2) (3) (4) (5) (6) (7) (8) (9)
- 3.7.1. [[SetPrototypeOf]]
- 3.8.2. [[Set]]
- 3.8.6. [[OwnPropertyKeys]]
- 3.8.7. Abstract operations
- 3.9. Callback interfaces (2) (3)
- 3.9.1. Legacy callback interface object (2) (3)
- 3.10. Invoking callback functions (2) (3)
- 3.11.1. Namespace object (2)
- 3.12.3. Creating and throwing exceptions
- 3.13.3.3. Link (2)
- Document conventions (2)

https://tc39.github.io/ecma262/#sec-well-known-symbols Referenced in:

- 2.5.8. Iterable declarations (2) (3)
- 2.5.9. Asynchronously iterable declarations (2)
- 2.5.10. Maplike declarations
- 2.5.11. Setlike declarations
- 3. ECMAScript binding
- 3.2.20. Sequences — sequence<T>
- 3.2.23. Union types (2)
- 3.3.23. [Unscopable]
- 3.5. Overload resolution algorithm (2)
- 3.6.3. Interface prototype object (2)
- 3.6.8.1. @@iterator (2) (3)
- 3.6.8.2. @@asyncIterator (2) (3)
- 3.6.9.1. entries (2)
- 3.6.9.3. values
- 3.6.10.2. entries
- 3.6.11.2. values

https://tc39.github.io/ecma262/#sec-well-known-symbols Referenced in:

- 2.5.8. Iterable declarations (2) (3)
- 2.5.9. Asynchronously iterable declarations (2)
- 2.5.10. Maplike declarations
- 2.5.11. Setlike declarations
- 3. ECMAScript binding
- 3.2.20. Sequences — sequence<T>
- 3.2.23. Union types (2)
- 3.3.23. [Unscopable]
- 3.5. Overload resolution algorithm (2)
- 3.6.3. Interface prototype object (2)
- 3.6.8.1. @@iterator (2) (3)
- 3.6.8.2. @@asyncIterator (2) (3)
- 3.6.9.1. entries (2)
- 3.6.9.3. values
- 3.6.10.2. entries
- 3.6.11.2. values

https://tc39.github.io/ecma262/#sec-well-known-symbols Referenced in:

- 2.5.8. Iterable declarations (2) (3)
- 2.5.9. Asynchronously iterable declarations (2)
- 2.5.10. Maplike declarations
- 2.5.11. Setlike declarations
- 3. ECMAScript binding
- 3.2.20. Sequences — sequence<T>
- 3.2.23. Union types (2)
- 3.3.23. [Unscopable]
- 3.5. Overload resolution algorithm (2)
- 3.6.3. Interface prototype object (2)
- 3.6.8.1. @@iterator (2) (3)
- 3.6.8.2. @@asyncIterator (2) (3)
- 3.6.9.1. entries (2)
- 3.6.9.3. values
- 3.6.10.2. entries
- 3.6.11.2. values

https://tc39.github.io/ecma262/#sec-well-known-symbols Referenced in:

- 2.5.8. Iterable declarations (2) (3)
- 2.5.9. Asynchronously iterable declarations (2)
- 2.5.10. Maplike declarations
- 2.5.11. Setlike declarations
- 3. ECMAScript binding
- 3.2.20. Sequences — sequence<T>
- 3.2.23. Union types (2)
- 3.3.23. [Unscopable]
- 3.5. Overload resolution algorithm (2)
- 3.6.3. Interface prototype object (2)
- 3.6.8.1. @@iterator (2) (3)
- 3.6.8.2. @@asyncIterator (2) (3)
- 3.6.9.1. entries (2)
- 3.6.9.3. values
- 3.6.10.2. entries
- 3.6.11.2. values

https://tc39.github.io/ecma262/#sec-arraybuffer-objects Referenced in:

- 3.2.24. Buffer source types (2)
- 3.3.1. [AllowShared]

https://tc39.github.io/ecma262/#sec-arraycreate Referenced in:

- 3.6.9.5. Iterator prototype object

https://tc39.github.io/ecma262/#sec-call Referenced in:

- 3.2.22. Promise types — Promise<T>
- 3.2.22.1. Creating and manipulating Promises (2) (3) (4)
- 3.6.6. Attributes
- 3.6.7. Operations
- 3.6.8.3. forEach (2)
- 3.6.9.7. Asynchronous iterator prototype object (2) (3) (4) (5) (6) (7)
- 3.6.10. Maplike declarations
- 3.6.10.4. get and has
- 3.6.10.6. delete
- 3.6.10.7. set
- 3.6.11. Setlike declarations
- 3.6.11.4. has
- 3.6.11.5. add and delete
- 3.9. Callback interfaces (2)
- 3.10. Invoking callback functions (2)

https://tc39.github.io/ecma262/#sec-canonicalnumericindexstring Referenced in:

- 3.8.7. Abstract operations

https://tc39.github.io/ecma262/#sec-completion Referenced in:

- 3.9. Callback interfaces
- 3.13.3.4. Evaluate

https://tc39.github.io/ecma262/#sec-construct Referenced in:

- 3.10. Invoking callback functions
- 3.12.3. Creating and throwing exceptions

https://tc39.github.io/ecma262/#sec-createbuiltinfunction Referenced in:

- 3.2.22.1. Creating and manipulating Promises (2) (3) (4)
- 3.6.1. Interface object
- 3.6.2. Named constructors
- 3.6.6. Attributes (2)
- 3.6.7. Operations
- 3.6.9.7. Asynchronous iterator prototype object (2) (3)
- 3.9.1. Legacy callback interface object

https://tc39.github.io/ecma262/#sec-createdataproperty Referenced in:

- 3.2.16. Dictionary types
- 3.2.20. Sequences — sequence<T>
- 3.2.21. Records — record<K, V>
- 3.6.3. Interface prototype object
- 3.6.6. Attributes
- 3.6.7.1.1. Default toJSON operation
- 3.6.9.5. Iterator prototype object (2)

https://tc39.github.io/ecma262/#sec-createiterresultobject Referenced in:

- 3.6.9.5. Iterator prototype object (2)
- 3.6.9.7. Asynchronous iterator prototype object (2) (3) (4)

https://tc39.github.io/ecma262/#sec-createmapiterator Referenced in:

- 3.6.8.1. @@iterator

https://tc39.github.io/ecma262/#sec-createmethodproperty Referenced in:

- 3.7. Platform objects implementing interfaces (2) (3) (4) (5)
- 3.11.1. Namespace object

https://tc39.github.io/ecma262/#table-15 Referenced in:

- 3.13.2. SetSyntheticModuleExport
- 3.13.3.3. Link (2)

https://tc39.github.io/ecma262/#sec-createsetiterator Referenced in:

- 3.6.8.1. @@iterator

https://tc39.github.io/ecma262/#sec-dataview-objects Referenced in:

- 3.2.24. Buffer source types
- 3.3.1. [AllowShared]

https://tc39.github.io/ecma262/#sec-definepropertyorthrow Referenced in:

- 3.6.1. Interface object
- 3.6.2. Named constructors
- 3.6.3. Interface prototype object (2)
- 3.6.5. Constants
- 3.6.6. Attributes
- 3.6.7. Operations
- 3.7. Platform objects implementing interfaces

https://tc39.github.io/ecma262/#sec-detacharraybuffer Referenced in:

- 3.2.24. Buffer source types

https://tc39.github.io/ecma262/#sec-error-objects Referenced in:

- 2.8. Exceptions (2)
- 3.12.1. DOMException custom bindings

https://tc39.github.io/ecma262/#sec-get-o-p Referenced in:

- 3.2.16. Dictionary types
- 3.2.21. Records — record<K, V>
- 3.6.6. Attributes
- 3.6.10.1. size
- 3.6.10.4. get and has
- 3.6.10.6. delete
- 3.6.10.7. set
- 3.6.11.4. has
- 3.6.11.5. add and delete
- 3.7. Platform objects implementing interfaces
- 3.9. Callback interfaces

https://tc39.github.io/ecma262/#sec-getfunctionrealm Referenced in:

- 3.7. Platform objects implementing interfaces

https://tc39.github.io/ecma262/#sec-getiterator Referenced in:

- 3.2.20.1. Creating a sequence from an iterable

https://tc39.github.io/ecma262/#sec-getmethod Referenced in:

- 3.2.20. Sequences — sequence<T>
- 3.2.23. Union types (2)
- 3.5. Overload resolution algorithm
- 3.6.8.3. forEach
- 3.6.10. Maplike declarations
- 3.6.11. Setlike declarations

https://tc39.github.io/ecma262/#sec-ifabruptrejectpromise Referenced in:

- 3.6.9.7. Asynchronous iterator prototype object (2)

https://tc39.github.io/ecma262/#table-15 Referenced in:

- 3.13.2. SetSyntheticModuleExport
- 3.13.3.3. Link (2)

https://tc39.github.io/ecma262/#sec-iscallable Referenced in:

- 3.1. ECMAScript environment
- 3.2.18. Callback function types
- 3.2.23. Union types
- 3.5. Overload resolution algorithm
- 3.6.8.3. forEach
- 3.7. Platform objects implementing interfaces
- 3.9. Callback interfaces (2) (3)
- 3.10. Invoking callback functions (2)

https://tc39.github.io/ecma262/#sec-isconstructor Referenced in:

- 3.10. Invoking callback functions

https://tc39.github.io/ecma262/#sec-isdatadescriptor Referenced in:

- 3.8.3. [[DefineOwnProperty]] (2)

https://tc39.github.io/ecma262/#sec-isdetachedbuffer Referenced in:

- 3.2.24. Buffer source types

https://tc39.github.io/ecma262/#sec-isinteger Referenced in:

- 3.8.7. Abstract operations

https://tc39.github.io/ecma262/#sec-issharedarraybuffer Referenced in:

- 3.2.24. Buffer source types (2) (3)

https://tc39.github.io/ecma262/#sec-iteratorstep Referenced in:

- 3.2.20.1. Creating a sequence from an iterable

https://tc39.github.io/ecma262/#sec-iteratorvalue Referenced in:

- 3.2.20.1. Creating a sequence from an iterable

https://tc39.github.io/ecma262/#sec-json.stringify Referenced in:

- 2.5.3.1. toJSON

https://tc39.github.io/ecma262/#sec-map-objects Referenced in:

- 2.5.10. Maplike declarations
- 3.6.10. Maplike declarations (2) (3)
- 3.6.10.1. size
- 3.6.10.4. get and has
- 3.6.10.6. delete
- 3.6.10.7. set
- Document conventions

https://tc39.github.io/ecma262/#sec-newmoduleenvironment Referenced in:

- 3.13.3.3. Link

https://tc39.github.io/ecma262/#sec-newpromisecapability Referenced in:

- 3.2.22. Promise types — Promise<T>
- 3.2.22.1. Creating and manipulating Promises (2) (3) (4)
- 3.6.9.7. Asynchronous iterator prototype object (2) (3) (4)

https://tc39.github.io/ecma262/#sec-built-in-function-objects Referenced in:

- 2. Interface definition language
- 2.3. Interface mixins (2) (3)
- 3. ECMAScript binding
- 3.6.1. Interface object (2) (3)
- 3.6.2. Named constructors (2) (3)
- 3.6.7.2. Stringifiers
- 3.6.8.1. @@iterator (2)
- 3.6.8.2. @@asyncIterator
- 3.6.8.3. forEach
- 3.6.9.5. Iterator prototype object
- 3.6.9.7. Asynchronous iterator prototype object (2)
- 3.6.10.1. size
- 3.6.10.3. keys and values
- 3.6.10.4. get and has
- 3.6.10.5. clear
- 3.6.10.6. delete
- 3.6.10.7. set
- 3.6.11. Setlike declarations
- 3.6.11.1. size
- 3.6.11.3. entries and keys
- 3.6.11.4. has
- 3.6.11.5. add and delete
- 3.6.11.6. clear
- 3.9.1. Legacy callback interface object

https://tc39.github.io/ecma262/#sec-objectcreate Referenced in:

- 3.2.16. Dictionary types
- 3.2.21. Records — record<K, V>
- 3.6.1. Interface object
- 3.6.3. Interface prototype object (2)
- 3.6.7.1.1. Default toJSON operation
- 3.11.1. Namespace object

https://tc39.github.io/ecma262/#sec-ordinarydefineownproperty Referenced in:

- 3.8.3. [[DefineOwnProperty]]

https://tc39.github.io/ecma262/#sec-ordinarygetownproperty Referenced in:

- 3.6.4.1. [[GetOwnProperty]]
- 3.8.7. Abstract operations

https://tc39.github.io/ecma262/#sec-ordinarysetwithowndescriptor Referenced in:

- 3.8.2. [[Set]]

https://tc39.github.io/ecma262/#sec-performpromisethen Referenced in:

- 3.2.22.1. Creating and manipulating Promises (2)
- 3.6.9.7. Asynchronous iterator prototype object (2) (3)

https://tc39.github.io/ecma262/#sec-set-objects Referenced in:

- 2.5.11. Setlike declarations
- 3.6.11. Setlike declarations (2) (3)
- 3.6.11.1. size
- 3.6.11.4. has
- 3.6.11.5. add and delete

https://tc39.github.io/ecma262/#sec-setfunctionlength Referenced in:

- 3.6.1. Interface object
- 3.6.2. Named constructors
- 3.6.6. Attributes (2)
- 3.6.7. Operations
- 3.9.1. Legacy callback interface object

https://tc39.github.io/ecma262/#sec-setfunctionname Referenced in:

- 3.6.1. Interface object
- 3.6.2. Named constructors
- 3.6.6. Attributes (2)
- 3.6.7. Operations
- 3.9.1. Legacy callback interface object

https://tc39.github.io/ecma262/#sec-set-immutable-prototype Referenced in:

- 3.6.4.4. [[SetPrototypeOf]]
- 3.7.1. [[SetPrototypeOf]]

https://tc39.github.io/ecma262/#sec-setintegritylevel Referenced in:

- 3.2.25. Frozen arrays — FrozenArray<T>

https://tc39.github.io/ecma262/#table-15 Referenced in:

- 3.13.2. SetSyntheticModuleExport
- 3.13.3.3. Link (2)

https://tc39.github.io/ecma262/#sec-sharedarraybuffer-objects Referenced in:

- 3.2.24. Buffer source types
- 3.3.1. [AllowShared] (2)
- 8. Privacy and Security Considerations

https://tc39.github.io/ecma262/#sec-native-error-types-used-in-this-standard-syntaxerror Referenced in:

- 2.8. Exceptions
- 2.8.1. Error names (2)

https://tc39.github.io/ecma262/#sec-toboolean Referenced in:

- 3.2.3. boolean

https://tc39.github.io/ecma262/#sec-toint32 Referenced in:

- 3.3.2. [Clamp]
- 3.3.4. [EnforceRange]

https://tc39.github.io/ecma262/#sec-tonumber Referenced in:

- 3.2.4.9. Abstract operations
- 3.2.5. float
- 3.2.6. unrestricted float
- 3.2.7. double
- 3.2.8. unrestricted double

https://tc39.github.io/ecma262/#sec-toobject Referenced in:

- 3.6.7.2. Stringifiers
- 3.6.8.1. @@iterator (2)
- 3.6.8.2. @@asyncIterator
- 3.6.8.3. forEach
- 3.6.9.2. keys (2)
- 3.6.9.3. values (2)
- 3.6.9.5. Iterator prototype object
- 3.6.9.7. Asynchronous iterator prototype object (2)

https://tc39.github.io/ecma262/#sec-tostring Referenced in:

- 3. ECMAScript binding (2)
- 3.2.9. DOMString
- 3.2.10. ByteString
- 3.2.17. Enumeration types
- 3.2.20. Sequences — sequence<T>
- 3.6.6. Attributes
- 3.8.6. [[OwnPropertyKeys]]

https://tc39.github.io/ecma262/#sec-touint32 Referenced in:

- 3.3.2. [Clamp]
- 3.3.4. [EnforceRange]
- 3.8.4. [[Delete]]
- 3.8.7. Abstract operations (2)

https://tc39.github.io/ecma262/#sec-ecmascript-data-types-and-values Referenced in:

- 3.2.1. any (2) (3) (4) (5)
- 3.2.12. object
- 3.2.13. symbol
- 3.2.15. Callback interface types
- 3.2.16. Dictionary types (2)
- 3.2.19. Nullable types — T?
- 3.2.20. Sequences — sequence<T>
- 3.2.21. Records — record<K, V>
- 3.2.23. Union types (2) (3) (4) (5) (6)
- 3.2.24. Buffer source types (2) (3)
- 3.5. Overload resolution algorithm (2) (3) (4) (5) (6) (7)
- 3.6.3. Interface prototype object
- 3.6.6. Attributes
- 3.7. Platform objects implementing interfaces (2)
- 3.8.2. [[Set]]
- 3.8.3. [[DefineOwnProperty]]
- 3.8.7. Abstract operations

https://tc39.github.io/ecma262/#sec-native-error-types-used-in-this-standard-typeerror Referenced in:

- 3.2.4.9. Abstract operations (2)
- 3.2.5. float (2)
- 3.2.7. double
- 3.2.10. ByteString
- 3.2.12. object
- 3.2.13. symbol
- 3.2.14. Interface types
- 3.2.15. Callback interface types
- 3.2.16. Dictionary types (2)
- 3.2.17. Enumeration types
- 3.2.18. Callback function types
- 3.2.20. Sequences — sequence<T> (2)
- 3.2.21. Records — record<K, V> (2)
- 3.2.23. Union types
- 3.2.24. Buffer source types (2) (3) (4) (5) (6)
- 3.3.1. [AllowShared]
- 3.5. Overload resolution algorithm (2) (3) (4)
- 3.6.1. Interface object (2)
- 3.6.2. Named constructors
- 3.6.6. Attributes (2) (3) (4) (5) (6) (7)
- 3.6.7. Operations (2)
- 3.6.7.2. Stringifiers
- 3.6.8.1. @@iterator (2)
- 3.6.8.2. @@asyncIterator
- 3.6.8.3. forEach (2) (3)
- 3.6.9.2. keys (2)
- 3.6.9.3. values (2)
- 3.6.9.5. Iterator prototype object
- 3.6.9.7. Asynchronous iterator prototype object (2) (3)
- 3.6.10. Maplike declarations (2)
- 3.6.10.1. size
- 3.6.10.4. get and has
- 3.6.10.6. delete
- 3.6.10.7. set
- 3.6.11. Setlike declarations (2)
- 3.6.11.1. size
- 3.6.11.4. has
- 3.6.11.5. add and delete
- 3.9. Callback interfaces
- 3.9.1. Legacy callback interface object
- 3.10. Invoking callback functions

https://tc39.github.io/ecma262/#sec-completion-record-specification-type Referenced in:

- 3.9. Callback interfaces (2) (3)
- 3.10. Invoking callback functions (2) (3)
- 3.12.4. Handling exceptions
- Document conventions (2) (3) (4) (5) (6)

https://tc39.github.io/ecma262/#eqn-abs Referenced in:

- 3.2.4.9. Abstract operations

https://tc39.github.io/ecma262/#sec-promise.all Referenced in:

- 3.2.22.1. Creating and manipulating Promises

https://tc39.github.io/ecma262/#array-index Referenced in:

- 3.8. Legacy platform objects
- 3.8.7. Abstract operations

https://tc39.github.io/ecma262/#sec-array-iterator-objects Referenced in:

- 2.5.8. Iterable declarations (2)

https://tc39.github.io/ecma262/#sec-built-in-function-objects Referenced in:

- 2. Interface definition language
- 2.3. Interface mixins (2) (3)
- 3. ECMAScript binding
- 3.6.1. Interface object (2) (3)
- 3.6.2. Named constructors (2) (3)
- 3.6.7.2. Stringifiers
- 3.6.8.1. @@iterator (2)
- 3.6.8.2. @@asyncIterator
- 3.6.8.3. forEach
- 3.6.9.5. Iterator prototype object
- 3.6.9.7. Asynchronous iterator prototype object (2)
- 3.6.10.1. size
- 3.6.10.3. keys and values
- 3.6.10.4. get and has
- 3.6.10.5. clear
- 3.6.10.6. delete
- 3.6.10.7. set
- 3.6.11. Setlike declarations
- 3.6.11.1. size
- 3.6.11.3. entries and keys
- 3.6.11.4. has
- 3.6.11.5. add and delete
- 3.6.11.6. clear
- 3.9.1. Legacy callback interface object

https://tc39.github.io/ecma262/#sec-iscallable Referenced in:

- 3.1. ECMAScript environment
- 3.2.18. Callback function types
- 3.2.23. Union types
- 3.5. Overload resolution algorithm
- 3.6.8.3. forEach
- 3.7. Platform objects implementing interfaces
- 3.9. Callback interfaces (2) (3)
- 3.10. Invoking callback functions (2)

https://tc39.github.io/ecma262/#sec-completion-record-specification-type Referenced in:

- 3.9. Callback interfaces (2) (3)
- 3.10. Invoking callback functions (2) (3)
- 3.12.4. Handling exceptions
- Document conventions (2) (3) (4) (5) (6)

https://tc39.github.io/ecma262/#constructor Referenced in:

- 2. Interface definition language
- 2.5.4. Constructor operations
- 3.3.12. [NamedConstructor] (2) (3)
- 3.3.14. [NoInterfaceObject]
- 3.6.1. Interface object (2)
- 3.10. Invoking callback functions
- 3.12.3. Creating and throwing exceptions

https://tc39.github.io/ecma262/#sec-algorithm-conventions Referenced in:

- 3. ECMAScript binding
- 3.2.4. Integer types
- Document conventions

https://tc39.github.io/ecma262/#current-realm Referenced in:

- 3. ECMAScript binding
- 3.12.3. Creating and throwing exceptions (2) (3)

https://tc39.github.io/ecma262/#sec-algorithm-conventions Referenced in:

- 3. ECMAScript binding
- 3.2.4. Integer types
- Document conventions

https://tc39.github.io/ecma262/#sec-built-in-function-objects Referenced in:

- 2. Interface definition language
- 2.3. Interface mixins (2) (3)
- 3. ECMAScript binding
- 3.6.1. Interface object (2) (3)
- 3.6.2. Named constructors (2) (3)
- 3.6.7.2. Stringifiers
- 3.6.8.1. @@iterator (2)
- 3.6.8.2. @@asyncIterator
- 3.6.8.3. forEach
- 3.6.9.5. Iterator prototype object
- 3.6.9.7. Asynchronous iterator prototype object (2)
- 3.6.10.1. size
- 3.6.10.3. keys and values
- 3.6.10.4. get and has
- 3.6.10.5. clear
- 3.6.10.6. delete
- 3.6.10.7. set
- 3.6.11. Setlike declarations
- 3.6.11.1. size
- 3.6.11.3. entries and keys
- 3.6.11.4. has
- 3.6.11.5. add and delete
- 3.6.11.6. clear
- 3.9.1. Legacy callback interface object

https://tc39.github.io/ecma262/#sec-immutable-prototype-exotic-objects Referenced in:

- 3.6.3. Interface prototype object (2)

https://tc39.github.io/ecma262/#sec-ordinary-object-internal-methods-and-internal-slots Referenced in:

- 3. ECMAScript binding (2) (3)
- 3.6.4. Named properties object
- 3.7. Platform objects implementing interfaces

https://tc39.github.io/ecma262/#sec-execution-contexts Referenced in:

- 3.13.3.4. Evaluate

https://tc39.github.io/ecma262/#sec-ecmascript-language-types-string-type Referenced in:

- 3.2.10. ByteString (2)

https://tc39.github.io/ecma262/#sec-property-attributes Referenced in:

- 3.2.21. Records — record<K, V>

https://tc39.github.io/ecma262/#sec-lexical-environments Referenced in:

- 3.13.2. SetSyntheticModuleExport
- 3.13.3.3. Link

https://tc39.github.io/ecma262/#sec-ecmascript-language-types-number-type Referenced in:

- 3.2.4.7. long long
- 3.2.4.8. unsigned long long
- 3.2.4.9. Abstract operations
- 3.2.5. float
- 3.2.6. unrestricted float

https://tc39.github.io/ecma262/#sec-error-objects Referenced in:

- 2.8. Exceptions (2)
- 3.12.1. DOMException custom bindings

https://tc39.github.io/ecma262/#execution-context-stack Referenced in:

- 3.13.3.4. Evaluate (2) (3)

https://tc39.github.io/ecma262/#eqn-floor Referenced in:

- 3.2.4.9. Abstract operations

https://tc39.github.io/ecma262/#table-22 Referenced in:

- 3.13.3.4. Evaluate (2) (3)

https://tc39.github.io/ecma262/#function-object Referenced in:

- 2.4. Callback interfaces
- 2.5.6. Static attributes and operations
- 2.10. Callback functions
- 3. ECMAScript binding
- 3.1. ECMAScript environment (2)
- 3.2.14. Interface types
- 3.2.15. Callback interface types
- 3.2.18. Callback function types
- 3.4. Security
- 3.6.1. Interface object
- 3.6.7.2. Stringifiers (2)
- 3.6.8.1. @@iterator (2) (3) (4) (5) (6)
- 3.6.8.2. @@asyncIterator (2) (3) (4)
- 3.6.8.3. forEach (2) (3) (4)
- 3.6.9.1. entries (2) (3) (4)
- 3.6.9.2. keys (2) (3) (4)
- 3.6.9.3. values (2) (3) (4)
- 3.6.10. Maplike declarations
- 3.6.10.1. size (2)
- 3.6.10.2. entries
- 3.6.10.3. keys and values (2)
- 3.6.10.4. get and has (2)
- 3.6.10.5. clear (2)
- 3.6.10.6. delete (2)
- 3.6.10.7. set (2)
- 3.6.11.1. size (2)
- 3.6.11.2. values
- 3.6.11.3. entries and keys (2)
- 3.6.11.4. has (2)
- 3.6.11.5. add and delete (2)
- 3.6.11.6. clear (2)
- 3.9.1. Legacy callback interface object
- 3.12.3. Creating and throwing exceptions (2)

https://tc39.github.io/ecma262/#sec-immutable-prototype-exotic-objects Referenced in:

- 3.6.3. Interface prototype object (2)

https://tc39.github.io/ecma262/#sec-ordinary-object-internal-methods-and-internal-slots Referenced in:

- 3. ECMAScript binding (2) (3)
- 3.6.4. Named properties object
- 3.7. Platform objects implementing interfaces

https://tc39.github.io/ecma262/#sec-ordinary-object-internal-methods-and-internal-slots Referenced in:

- 3. ECMAScript binding (2) (3)
- 3.6.4. Named properties object
- 3.7. Platform objects implementing interfaces

https://tc39.github.io/ecma262/#table-23 Referenced in:

- 3.13.3.4. Evaluate (2)

https://tc39.github.io/ecma262/#eqn-max Referenced in:

- 2.5.7. Overloading
- 3.2.4.9. Abstract operations

https://tc39.github.io/ecma262/#eqn-min Referenced in:

- 3.2.4.9. Abstract operations

https://tc39.github.io/ecma262/#sec-abstract-module-records Referenced in:

- 3.13.3. Concrete Methods
- 3.13.3.1. GetExportedNames
- 3.13.3.2. ResolveExport
- 3.13.3.3. Link
- 3.13.3.4. Evaluate

https://tc39.github.io/ecma262/#table-36 Referenced in:

- 3.13. Synthetic module records

https://tc39.github.io/ecma262/#eqn-modulo Referenced in:

- 3.2.4.9. Abstract operations

https://tc39.github.io/ecma262/#sec-ecmascript-language-types-number-type Referenced in:

- 3.2.4.7. long long
- 3.2.4.8. unsigned long long
- 3.2.4.9. Abstract operations
- 3.2.5. float
- 3.2.6. unrestricted float

https://tc39.github.io/ecma262/#sec-literals-numeric-literals Referenced in:

- 2.5.1. Constants

https://tc39.github.io/ecma262/#sec-object-type Referenced in:

- 3.7. Platform objects implementing interfaces

https://tc39.github.io/ecma262/#sec-own-property Referenced in:

- 3.2.21. Records — record<K, V>

https://tc39.github.io/ecma262/#sec-promisecapability-records Referenced in:

- 3.2.22. Promise types — Promise<T>

https://tc39.github.io/ecma262/#sec-property-descriptor-specification-type Referenced in:

- 3.6.4.1. [[GetOwnProperty]]
- 3.8.3. [[DefineOwnProperty]]
- 3.8.7. Abstract operations (2)

https://tc39.github.io/ecma262/#table-22 Referenced in:

- 3.13.3.4. Evaluate (2) (3)

https://tc39.github.io/ecma262/#resolvedbinding-record Referenced in:

- 3.13.3.2. ResolveExport

https://tc39.github.io/ecma262/#running-execution-context Referenced in:

- 3.13.3.4. Evaluate (2) (3)

https://tc39.github.io/ecma262/#table-22 Referenced in:

- 3.13.3.4. Evaluate (2) (3)

https://tc39.github.io/ecma262/#sourctextmodule-record Referenced in:

- 3.13.1. CreateSyntheticModule

https://tc39.github.io/ecma262/#table-23 Referenced in:

- 3.13.3.4. Evaluate (2)

https://www.khronos.org/registry/webgl/extensions/EXT_blend_minmax/#ext_blend_minmax Referenced in:

- 3.3.14. [NoInterfaceObject]

https://www.khronos.org/registry/webgl/extensions/EXT_color_buffer_float/#ext_color_buffer_float Referenced in:

- 3.3.14. [NoInterfaceObject]

https://www.khronos.org/registry/webgl/extensions/EXT_disjoint_timer_query/#ext_disjoint_timer_query Referenced in:

- 3.3.14. [NoInterfaceObject]

https://fetch.spec.whatwg.org/#response Referenced in:

- 3.2.22.2. Examples

https://fetch.spec.whatwg.org/#dom-global-fetch Referenced in:

- 3.2.22.2. Examples

https://fullscreen.spec.whatwg.org/#dom-document-fullscreenelement Referenced in:

- 3.3.10. [LenientSetter]

https://fullscreen.spec.whatwg.org/#dom-document-fullscreenenabled Referenced in:

- 3.3.10. [LenientSetter] (2)

https://www.w3.org/TR/geolocation-API/#coordinates Referenced in:

- 3.3.14. [NoInterfaceObject]

https://www.w3.org/TR/geolocation-API/#geolocation Referenced in:

- 3.3.14. [NoInterfaceObject]

https://www.w3.org/TR/geolocation-API/#position Referenced in:

- 3.3.14. [NoInterfaceObject]

https://www.w3.org/TR/geolocation-API/#position-error Referenced in:

- 3.3.14. [NoInterfaceObject]

https://drafts.fxtf.org/geometry-1/#dommatrix Referenced in:

- 3.3.9. [LegacyWindowAlias]

https://drafts.fxtf.org/geometry-1/#dompoint Referenced in:

- 3.3.9. [LegacyWindowAlias]

https://drafts.fxtf.org/geometry-1/#domrect Referenced in:

- 3.3.9. [LegacyWindowAlias]

https://html.spec.whatwg.org/multipage/canvas.html#canvasdrawpath Referenced in:

- 2.5.7.1. Overloading vs. union types (2)

https://html.spec.whatwg.org/multipage/dom.html#domstringmap Referenced in:

- 3.3.15. [OverrideBuiltins]

https://html.spec.whatwg.org/multipage/webappapis.html#eventhandlernonnull Referenced in:

- 3.3.20. [TreatNonObjectAsNull]

https://html.spec.whatwg.org/multipage/common-dom-interfaces.html#htmlallcollection Referenced in:

- 3. ECMAScript binding
- 3.3.8. [LegacyUnenumerableNamedProperties]

https://html.spec.whatwg.org/multipage/media.html#htmlaudioelement Referenced in:

- 3.3.12. [NamedConstructor]

https://html.spec.whatwg.org/multipage/forms.html#htmlformelement Referenced in:

- 3.3.8. [LegacyUnenumerableNamedProperties]
- 3.3.15. [OverrideBuiltins]

https://html.spec.whatwg.org/multipage/embedded-content.html#htmlimageelement Referenced in:

- 3.3.12. [NamedConstructor]

https://html.spec.whatwg.org/multipage/form-elements.html#htmloptionelement Referenced in:

- 3.3.12. [NamedConstructor]

https://html.spec.whatwg.org/multipage/history.html#location Referenced in:

- 3. ECMAScript binding

https://html.spec.whatwg.org/multipage/system-state.html#mimetypearray Referenced in:

- 3.3.8. [LegacyUnenumerableNamedProperties]

https://html.spec.whatwg.org/multipage/webappapis.html#onbeforeunloadeventhandlernonnull Referenced in:

- 3.3.20. [TreatNonObjectAsNull]

https://html.spec.whatwg.org/multipage/webappapis.html#onerroreventhandlernonnull Referenced in:

- 3.3.20. [TreatNonObjectAsNull]

https://html.spec.whatwg.org/multipage/canvas.html#path2d Referenced in:

- 2.5.7.1. Overloading vs. union types

https://html.spec.whatwg.org/multipage/system-state.html#dom-plugin Referenced in:

- 3.3.8. [LegacyUnenumerableNamedProperties]

https://html.spec.whatwg.org/multipage/system-state.html#pluginarray Referenced in:

- 3.3.8. [LegacyUnenumerableNamedProperties]

https://html.spec.whatwg.org/multipage/structured-data.html#serializable Referenced in:

- 4.3. DOMException

https://html.spec.whatwg.org/multipage/window-object.html#window Referenced in:

- 2. Interface definition language
- 3.3.5. [Exposed]
- 3.3.8. [LegacyUnenumerableNamedProperties]
- 3.3.9. [LegacyWindowAlias] (2) (3)
- 3.6. Interfaces
- 3.7. Platform objects implementing interfaces
- 3.7.1. [[SetPrototypeOf]] (2)

https://html.spec.whatwg.org/multipage/webappapis.html#windoworworkerglobalscope Referenced in:

- 2.3.1. Using mixins and partials

https://html.spec.whatwg.org/multipage/window-object.html#windowproxy Referenced in:

- 3.7.1. [[SetPrototypeOf]]

https://html.spec.whatwg.org/multipage/webappapis.html#clean-up-after-running-a-callback Referenced in:

- 3.9. Callback interfaces
- 3.10. Invoking callback functions (2)

https://html.spec.whatwg.org/multipage/webappapis.html#clean-up-after-running-script Referenced in:

- 3.9. Callback interfaces
- 3.10. Invoking callback functions (2)

https://html.spec.whatwg.org/multipage/structured-data.html#deserialization-steps Referenced in:

- 4.3. DOMException

https://html.spec.whatwg.org/multipage/webappapis.html#event-handler-idl-attributes Referenced in:

- 3.3.20. [TreatNonObjectAsNull]

https://html.spec.whatwg.org/multipage/webappapis.html#concept-realm-global Referenced in:

- 2. Interface definition language
- 3.1. ECMAScript environment
- 3.6. Interfaces
- 3.6.4.1. [[GetOwnProperty]]
- 3.6.6. Attributes (2)
- 3.6.7. Operations
- 3.7. Platform objects implementing interfaces
- 3.9.1. Legacy callback interface object
- 3.11. Namespaces

https://html.spec.whatwg.org/multipage/infrastructure.html#in-parallel Referenced in:

- 3.2.22.2. Examples (2) (3) (4) (5) (6)

https://html.spec.whatwg.org/multipage/webappapis.html#incumbent-settings-object Referenced in:

- 2.13.22. Callback interface types
- 2.13.25. Callback function types
- 3.2.15. Callback interface types
- 3.2.18. Callback function types

https://html.spec.whatwg.org/multipage/webappapis.html#handler-onmouseenter Referenced in:

- 3.3.11. [LenientThis]

https://html.spec.whatwg.org/multipage/webappapis.html#handler-onmouseleave Referenced in:

- 3.3.11. [LenientThis]

https://html.spec.whatwg.org/multipage/webappapis.html#handler-onreadystatechange Referenced in:

- 3.3.11. [LenientThis]

https://html.spec.whatwg.org/multipage/webappapis.html#prepare-to-run-a-callback Referenced in:

- 3.9. Callback interfaces
- 3.10. Invoking callback functions (2)

https://html.spec.whatwg.org/multipage/webappapis.html#prepare-to-run-script Referenced in:

- 3.9. Callback interfaces
- 3.10. Invoking callback functions (2)

https://html.spec.whatwg.org/multipage/webappapis.html#queue-a-microtask Referenced in:

- 3.2.22.1. Creating and manipulating Promises

https://html.spec.whatwg.org/multipage/webappapis.html#queue-a-task Referenced in:

- 3.2.22.2. Examples (2)

https://html.spec.whatwg.org/multipage/webappapis.html#concept-relevant-realm Referenced in:

- 3.1. ECMAScript environment
- 3.2.22.2. Examples (2) (3)

https://html.spec.whatwg.org/multipage/webappapis.html#relevant-settings-object Referenced in:

- 3.3.5. [Exposed] (2)

https://html.spec.whatwg.org/multipage/structured-data.html#serializable-objects Referenced in:

- 4.3. DOMException

https://html.spec.whatwg.org/multipage/structured-data.html#serialization-steps Referenced in:

- 4.3. DOMException

https://html.spec.whatwg.org/multipage/webappapis.html#concept-realm-settings-object Referenced in:

- 3.9. Callback interfaces
- 3.10. Invoking callback functions (2)

https://html.spec.whatwg.org/multipage/canvas.html#dom-context-2d-stroke Referenced in:

- 2.5.7.1. Overloading vs. union types

https://html.spec.whatwg.org/multipage/webappapis.html#task-source Referenced in:

- 3.2.22.2. Examples

https://infra.spec.whatwg.org/#set-append Referenced in:

- 2.5.7. Overloading (2) (3)
- 2.13.31. Annotated types (2) (3) (4) (5)

https://infra.spec.whatwg.org/#iteration-break Referenced in:

- 2.5.7. Overloading

https://infra.spec.whatwg.org/#string-concatenate Referenced in:

- 2.2. Interfaces

https://infra.spec.whatwg.org/#list-contain Referenced in:

- 3.7. Platform objects implementing interfaces

https://infra.spec.whatwg.org/#iteration-continue Referenced in:

- 3.6.5. Constants
- 3.6.6. Attributes
- 3.6.7. Operations

https://infra.spec.whatwg.org/#map-entry Referenced in:

- 2.7. Dictionaries (2) (3)
- 2.13.28. Record types — record<K, V>

https://infra.spec.whatwg.org/#map-exists Referenced in:

- 2.7. Dictionaries

https://infra.spec.whatwg.org/#map-iterate Referenced in:

- 3.2.21. Records — record<K, V>
- 3.6.7.1.1. Default toJSON operation

https://infra.spec.whatwg.org/#set-intersection Referenced in:

- 3.3.5. [Exposed] (2) (3) (4)

https://infra.spec.whatwg.org/#list-is-empty Referenced in:

- 2.5.7. Overloading
- 3.6.7.1.1. Default toJSON operation

https://infra.spec.whatwg.org/#list-is-empty Referenced in:

- 2.5.7. Overloading
- 3.6.7.1.1. Default toJSON operation

https://infra.spec.whatwg.org/#struct-item Referenced in:

- 2.5.7. Overloading
- 2.5.8. Iterable declarations (2) (3)

https://infra.spec.whatwg.org/#list-iterate Referenced in:

- 2.5.3.1. toJSON
- 2.5.7. Overloading (2) (3) (4) (5) (6)
- 3.2.21. Records — record<K, V>
- 3.2.22.1. Creating and manipulating Promises
- 3.2.22.2. Examples
- 3.6.3. Interface prototype object
- 3.6.5. Constants
- 3.6.6. Attributes
- 3.6.7. Operations
- 3.7. Platform objects implementing interfaces (2) (3) (4) (5) (6)

https://infra.spec.whatwg.org/#javascript-string Referenced in:

- 4.3. DOMException

https://infra.spec.whatwg.org/#map-key Referenced in:

- 2.7. Dictionaries (2)
- 2.13.28. Record types — record<K, V> (2)

https://infra.spec.whatwg.org/#list Referenced in:

- 2.2. Interfaces
- 2.5.7. Overloading (2) (3)
- 2.5.8. Iterable declarations
- 2.13.27. Sequence types — sequence<T> (2) (3)
- 3.2.22.1. Creating and manipulating Promises (2) (3) (4)
- 3.6.6. Attributes (2) (3)
- 3.6.7. Operations (2) (3)
- 3.6.7.1.1. Default toJSON operation
- 3.7. Platform objects implementing interfaces (2)
- 3.8.6. [[OwnPropertyKeys]] (2) (3) (4) (5) (6) (7) (8) (9)
- 3.9. Callback interfaces (2)

https://infra.spec.whatwg.org/#struct-name Referenced in:

- 2.5.8. Iterable declarations (2)

https://infra.spec.whatwg.org/#ordered-map Referenced in:

- 2.7. Dictionaries (2)
- 2.13.23. Dictionary types
- 2.13.28. Record types — record<K, V> (2) (3)
- 3.6.7.1.1. Default toJSON operation (2) (3)

https://infra.spec.whatwg.org/#ordered-set Referenced in:

- 2.5.7. Overloading (2)
- 2.13.31. Annotated types

https://infra.spec.whatwg.org/#stack-pop Referenced in:

- 3.6.7.1.1. Default toJSON operation

https://infra.spec.whatwg.org/#stack-push Referenced in:

- 3.6.7.1.1. Default toJSON operation (2)

https://infra.spec.whatwg.org/#list-remove Referenced in:

- 3.6.6. Attributes
- 3.6.7. Operations

https://infra.spec.whatwg.org/#map-set Referenced in:

- 3.2.21. Records — record<K, V>
- 3.6.7.1.1. Default toJSON operation

https://infra.spec.whatwg.org/#list-size Referenced in:

- 2.5.7. Overloading (2)
- 3.2.22.1. Creating and manipulating Promises
- 3.5. Overload resolution algorithm
- 3.6.1. Interface object
- 3.6.2. Named constructors
- 3.6.7. Operations
- 3.9. Callback interfaces

https://infra.spec.whatwg.org/#stack Referenced in:

- 3.6.7.1.1. Default toJSON operation (2)

https://infra.spec.whatwg.org/#struct Referenced in:

- 2.5.8. Iterable declarations

https://infra.spec.whatwg.org/#the-range Referenced in:

- 2.5.7. Overloading (2) (3) (4)

https://infra.spec.whatwg.org/#tuple Referenced in:

- 2.5.7. Overloading (2) (3) (4) (5)

https://infra.spec.whatwg.org/#map-value Referenced in:

- 2.5.3.1. toJSON
- 2.7. Dictionaries
- 2.13.28. Record types — record<K, V> (2)

https://infra.spec.whatwg.org/#iteration-while Referenced in:

- 2.5.7. Overloading
- 3.6.7.1.1. Default toJSON operation

https://w3c.github.io/mediacapture-main/#dom-constrainablepattern Referenced in:

- 3.3.14. [NoInterfaceObject]

https://www.khronos.org/registry/webgl/extensions/OES_standard_derivatives/#oes_standard_derivatives Referenced in:

- 3.3.14. [NoInterfaceObject]

https://www.khronos.org/registry/webgl/extensions/OES_vertex_array_object/#oes_vertex_array_object Referenced in:

- 3.3.14. [NoInterfaceObject]

https://w3c.github.io/deviceorientation/spec-source-orientation.html#device_acceleration Referenced in:

- 3.3.14. [NoInterfaceObject]

https://w3c.github.io/deviceorientation/spec-source-orientation.html#device_rotation_rate Referenced in:

- 3.3.14. [NoInterfaceObject]

https://w3c.github.io/webappsec-secure-contexts/#secure-contexts Referenced in:

- 3.3.5. [Exposed] (2)
- 3.3.19. [SecureContext]

http://www.unicode.org/glossary/#unicode_scalar_value Referenced in:

- 2.5.3. Operations
- 2.13.16. DOMString
- 2.13.18. USVString
- 3.2.11. USVString (2)

https://url.spec.whatwg.org/#url Referenced in:

- 3.3.9. [LegacyWindowAlias]

https://www.khronos.org/registry/webgl/extensions/WEBGL_compressed_texture_astc/#webgl_compressed_texture_astc Referenced in:

- 3.3.14. [NoInterfaceObject]

https://www.khronos.org/registry/webgl/extensions/WEBGL_compressed_texture_s3tc_srgb/#webgl_compressed_texture_s3tc_srgb Referenced in:

- 3.3.14. [NoInterfaceObject]

https://www.khronos.org/registry/webgl/extensions/WEBGL_draw_buffers/#webgl_draw_buffers Referenced in:

- 3.3.14. [NoInterfaceObject]

https://www.khronos.org/registry/webgl/extensions/WEBGL_lose_context/#webgl_lose_context Referenced in:

- 3.3.14. [NoInterfaceObject]

https://drafts.css-houdini.org/worklets/#worklet Referenced in:

- 3.3.5. [Exposed]

### Terms defined by reference

- [angle_instanced_arrays] defines the following terms:
  - ANGLE_instanced_arrays
- [CSS3-CONDITIONAL] defines the following terms:
  - supports(conditionText)
  - supports(property, value)
- [CSSOM] defines the following terms:
  - CSS
- [DOM] defines the following terms:
  - Document
  - DocumentOrShadowRoot
  - EventListener
  - HTMLCollection
  - NamedNodeMap
  - createElement(localName)
  - document
  - implementation
  - node tree
- [ECMA-262] defines the following terms:
  - !
  - %ArrayProto_entries%
  - %ArrayProto_forEach%
  - %ArrayProto_keys%
  - %ArrayProto_values%
  - %AsyncIteratorPrototype%
  - %ErrorPrototype%
  - %FunctionPrototype%
  - %IteratorPrototype%
  - %ObjectPrototype%
  - %Promise%
  - %PromiseProto_then%
  - %Promise_reject%
  - ?
  - @@asyncIterator
  - @@iterator
  - @@toStringTag
  - @@unscopables
  - ArrayBuffer
  - ArrayCreate
  - Call
  - CanonicalNumericIndexString
  - Completion
  - Construct
  - CreateBuiltinFunction
  - CreateDataProperty
  - CreateIterResultObject
  - CreateMapIterator
  - CreateMethodProperty
  - CreateMutableBinding
  - CreateSetIterator
  - DataView
  - DefinePropertyOrThrow
  - DetachArrayBuffer
  - Error
  - Get
  - GetFunctionRealm
  - GetIterator
  - GetMethod
  - IfAbruptRejectPromise
  - InitializeBinding
  - IsCallable
  - IsConstructor
  - IsDataDescriptor
  - IsDetachedBuffer
  - IsInteger
  - IsSharedArrayBuffer
  - IteratorStep
  - IteratorValue
  - JSON.stringify()
  - Map
  - NewModuleEnvironment
  - NewPromiseCapability
  - NewTarget
  - ObjectCreate
  - OrdinaryDefineOwnProperty
  - OrdinaryGetOwnProperty
  - OrdinarySetWithOwnDescriptor
  - PerformPromiseThen
  - Set (for ECMAScript)
  - SetFunctionLength
  - SetFunctionName
  - SetImmutablePrototype
  - SetIntegrityLevel
  - SetMutableBinding
  - SharedArrayBuffer
  - SyntaxError
  - ToBoolean
  - ToInt32
  - ToNumber
  - ToObject
  - ToString
  - ToUint32
  - Type
  - TypeError
  - abrupt completion
  - abs
  - all()
  - array index
  - array iterator object
  - built-in function object
  - callable
  - completion record
  - constructor
  - conventions
  - current realm
  - ecma-262 algorithm conventions
  - ecma-262 built-in function objects
  - ecma-262 immutable prototype exotic objects
  - ecma-262 ordinary object internal methods and internal slots
  - ecmascript code execution context
  - element
  - enumerable
  - environmentrecord
  - equally close values
  - error objects
  - execution context stack
  - floor
  - function
  - function object
  - immutable prototype exotic object
  - internal method (for ordinary object)
  - internal slot (for ordinary object)
  - lexicalenvironment
  - max
  - min
  - module record
  - module record fields
  - modulo
  - number type
  - numericliteral
  - object
  - own property
  - promisecapability
  - property descriptor
  - realm (for Execution context)
  - resolvedbinding record
  - running execution context
  - scriptormodule
  - source text module record
  - variableenvironment
- [ext_blend_minmax] defines the following terms:
  - EXT_blend_minmax
- [ext_color_buffer_float] defines the following terms:
  - EXT_color_buffer_float
- [ext_disjoint_timer_query] defines the following terms:
  - EXT_disjoint_timer_query
- [FETCH] defines the following terms:
  - Response
  - fetch(input)
- [FULLSCREEN] defines the following terms:
  - fullscreenElement
  - fullscreenEnabled
- [GEOLOCATION-API] defines the following terms:
  - Coordinates
  - Geolocation
  - Position
  - PositionError
- [GEOMETRY] defines the following terms:
  - DOMMatrix
  - DOMPoint
  - DOMRect
- [HTML] defines the following terms:
  - CanvasDrawPath
  - DOMStringMap
  - EventHandlerNonNull
  - HTMLAllCollection
  - HTMLAudioElement
  - HTMLFormElement
  - HTMLImageElement
  - HTMLOptionElement
  - Location
  - MimeTypeArray
  - OnBeforeUnloadEventHandlerNonNull
  - OnErrorEventHandlerNonNull
  - Path2D
  - Plugin
  - PluginArray
  - Serializable
  - Window
  - WindowOrWorkerGlobalScope
  - WindowProxy
  - clean up after running a callback
  - clean up after running script
  - deserialization steps
  - event handler idl attribute
  - global object
  - in parallel
  - incumbent settings object
  - onmouseenter
  - onmouseleave
  - onreadystatechange
  - prepare to run a callback
  - prepare to run script
  - queue a microtask
  - queue a task
  - relevant realm
  - relevant settings object
  - serializable objects
  - serialization steps
  - settings object
  - stroke()
  - task source
- [INFRA] defines the following terms:
  - append (for set)
  - break
  - concatenation
  - contain
  - continue
  - entry
  - exist
  - for each (for map)
  - intersection
  - is empty
  - is not empty
  - item (for struct)
  - iterate
  - javascript string
  - key
  - list
  - name
  - ordered map
  - ordered set
  - pop
  - push
  - remove
  - set
  - size
  - stack
  - struct
  - the range
  - tuple
  - value
  - while
- [MEDIACAPTURE-STREAMS] defines the following terms:
  - ConstrainablePattern
- [oes_standard_derivatives] defines the following terms:
  - OES_standard_derivatives
- [oes_vertex_array_object] defines the following terms:
  - OES_vertex_array_object
- [ORIENTATION-EVENT] defines the following terms:
  - DeviceAcceleration
  - DeviceRotationRate
- [secure-contexts] defines the following terms:
  - secure contexts
- [UNICODE] defines the following terms:
  - unicode scalar value
- [URL] defines the following terms:
  - URL
- [webgl_compressed_texture_astc] defines the following terms:
  - WEBGL_compressed_texture_astc
- [webgl_compressed_texture_s3tc_srgb] defines the following terms:
  - WEBGL_compressed_texture_s3tc_srgb
- [webgl_draw_buffers] defines the following terms:
  - WEBGL_draw_buffers
- [webgl_lose_context] defines the following terms:
  - WEBGL_lose_context
- [worklets-1] defines the following terms:
  - Worklet

## References

### Normative References

[DOM]
  Anne van Kesteren. DOM Standard. Living Standard. URL: https://dom.spec.whatwg.org/
[ECMA-262]
  ECMAScript Language Specification. URL: https://tc39.github.io/ecma262/
[HTML]
  Anne van Kesteren; et al. HTML Standard. Living Standard. URL: https://html.spec.whatwg.org/multipage/
[IEEE-754]
  IEEE Standard for Floating-Point Arithmetic. 29 August 2008. URL: http://ieeexplore.ieee.org/servlet/opac?punumber=4610933
[INFRA]
  Anne van Kesteren; Domenic Denicola. Infra Standard. Living Standard. URL: https://infra.spec.whatwg.org/
[PERLRE]
  Perl regular expressions (Perl 5.8.8). February 2006. URL: http://search.cpan.org/dist/perl/pod/perlre.pod
[RFC2781]
  P. Hoffman; F. Yergeau. UTF-16, an encoding of ISO 10646. February 2000. Informational. URL: https://tools.ietf.org/html/rfc2781
[RFC3629]
  F. Yergeau. UTF-8, a transformation format of ISO 10646. November 2003. Internet Standard. URL: https://tools.ietf.org/html/rfc3629
[SECURE-CONTEXTS]
  Mike West. Secure Contexts. URL: https://w3c.github.io/webappsec-secure-contexts/
[UNICODE]
  The Unicode Standard. URL: https://www.unicode.org/versions/latest/

### Informative References

[CSS3-CONDITIONAL]
  David Baron. CSS Conditional Rules Module Level 3. URL: https://drafts.csswg.org/css-conditional-3/
[CSSOM]
  Simon Pieters; Glenn Adams. CSS Object Model (CSSOM). URL: https://drafts.csswg.org/cssom/
[FETCH]
  Anne van Kesteren. Fetch Standard. Living Standard. URL: https://fetch.spec.whatwg.org/
[FULLSCREEN]
  Philip Jägenstedt. Fullscreen API Standard. Living Standard. URL: https://fullscreen.spec.whatwg.org/
[GEOLOCATION-API]
  Andrei Popescu. Geolocation API Specification 2nd Edition. URL: http://dev.w3.org/geo/api/spec-source.html
[GEOMETRY]
  Simon Pieters; Chris Harrelson. Geometry Interfaces Module Level 1. URL: https://drafts.fxtf.org/geometry/
[JSSTDLIB]
  Standard Library Proposal. URL: https://github.com/tc39/proposal-javascript-standard-library/
[MEDIACAPTURE-STREAMS]
  Daniel Burnett; et al. Media Capture and Streams. URL: https://w3c.github.io/mediacapture-main/
[OMGIDL]
  CORBA 3.1 – OMG IDL Syntax and Semantics chapter. January 2008. URL: http://www.omg.org/cgi-bin/doc?formal/08-01-04.pdf
[ORIENTATION-EVENT]
  Rich Tibbett; et al. DeviceOrientation Event Specification. URL: https://w3c.github.io/deviceorientation/spec-source-orientation.html
[SERVICE-WORKERS]
  Alex Russell; et al. Service Workers 1. URL: https://w3c.github.io/ServiceWorker/
[URL]
  Anne van Kesteren. URL Standard. Living Standard. URL: https://url.spec.whatwg.org/
[WEBGL]
  Dean Jackson; Jeff Gilbert. WebGL 2.0 Specification. 12 August 2017. URL: https://www.khronos.org/registry/webgl/specs/latest/2.0/
[WORKLETS-1]
  Ian Kilpatrick. Worklets Level 1. URL: https://drafts.css-houdini.org/worklets/
[XML-NAMES]
  Tim Bray; et al. Namespaces in XML 1.0 (Third Edition). 8 December 2009. REC. URL: https://www.w3.org/TR/xml-names/

## IDL Index

    typedef (Int8Array or Int16Array or Int32Array or
             Uint8Array or Uint16Array or Uint32Array or Uint8ClampedArray or
             Float32Array or Float64Array or DataView) ArrayBufferView;

    typedef (ArrayBufferView or ArrayBuffer) BufferSource;
    [Exposed=(Window,Worker),
     Serializable]
    interface DOMException { // but see below note about ECMAScript binding
      constructor(optional DOMString message = "", optional DOMString name = "Error");
      readonly attribute DOMString name;
      readonly attribute DOMString message;
      readonly attribute unsigned short code;

      const unsigned short INDEX_SIZE_ERR = 1;
      const unsigned short DOMSTRING_SIZE_ERR = 2;
      const unsigned short HIERARCHY_REQUEST_ERR = 3;
      const unsigned short WRONG_DOCUMENT_ERR = 4;
      const unsigned short INVALID_CHARACTER_ERR = 5;
      const unsigned short NO_DATA_ALLOWED_ERR = 6;
      const unsigned short NO_MODIFICATION_ALLOWED_ERR = 7;
      const unsigned short NOT_FOUND_ERR = 8;
      const unsigned short NOT_SUPPORTED_ERR = 9;
      const unsigned short INUSE_ATTRIBUTE_ERR = 10;
      const unsigned short INVALID_STATE_ERR = 11;
      const unsigned short SYNTAX_ERR = 12;
      const unsigned short INVALID_MODIFICATION_ERR = 13;
      const unsigned short NAMESPACE_ERR = 14;
      const unsigned short INVALID_ACCESS_ERR = 15;
      const unsigned short VALIDATION_ERR = 16;
      const unsigned short TYPE_MISMATCH_ERR = 17;
      const unsigned short SECURITY_ERR = 18;
      const unsigned short NETWORK_ERR = 19;
      const unsigned short ABORT_ERR = 20;
      const unsigned short URL_MISMATCH_ERR = 21;
      const unsigned short QUOTA_EXCEEDED_ERR = 22;
      const unsigned short TIMEOUT_ERR = 23;
      const unsigned short INVALID_NODE_TYPE_ERR = 24;
      const unsigned short DATA_CLONE_ERR = 25;
    };

    typedef unsigned long long DOMTimeStamp;
    callback Function = any (any... arguments);
    callback VoidFunction = void ();

#dfn-idl-fragment Referenced in:

- 2. Interface definition language (2) (3) (4)
- 2.1. Names (2) (3) (4) (5)
- 2.2. Interfaces (2) (3)
- 2.3. Interface mixins
- 2.5.1. Constants
- 2.5.2. Attributes
- 2.5.3. Operations (2) (3) (4)
- 2.5.3.1. toJSON
- 2.5.5.1. Stringifiers (2)
- 2.5.5.2. Indexed properties
- 2.5.6. Static attributes and operations
- 2.6. Namespaces
- 2.7. Dictionaries
- 2.9. Enumerations
- 2.10. Callback functions
- 2.11. Typedefs
- 2.12. Objects implementing interfaces
- 2.14. Extended attributes
- 3.1. ECMAScript environment (2)
- 3.3.1. [AllowShared]
- 3.3.2. [Clamp]
- 3.3.4. [EnforceRange]
- 3.3.7. [LegacyNamespace]
- 3.3.14. [NoInterfaceObject]
- 3.3.15. [OverrideBuiltins]
- 3.3.16. [PutForwards]
- 3.3.17. [Replaceable]
- 3.3.19. [SecureContext]
- 3.3.20. [TreatNonObjectAsNull]
- 3.3.21. [TreatNullAs]
- 3.3.22. [Unforgeable]
- 3.6.7.1.1. Default toJSON operation
- 3.12.4. Handling exceptions
- 5. Extensibility
- 7. Referencing this specification
- IDL grammar (2)
- Conformance

#dfn-definition Referenced in:

- 2. Interface definition language
- 2.1. Names
- 2.3. Interface mixins (2) (3)
- 2.4. Callback interfaces
- 2.14. Extended attributes

#dfn-named-definition Referenced in:

- 2.1. Names

#dfn-identifier Referenced in:

- 2.1. Names (2) (3) (4) (5) (6) (7) (8)
- 2.2. Interfaces (2) (3)
- 2.3. Interface mixins (2) (3) (4)
- 2.5.1. Constants (2)
- 2.5.2. Attributes (2) (3) (4)
- 2.5.3. Operations (2) (3) (4) (5) (6)
- 2.5.3.1. toJSON
- 2.5.5. Special operations
- 2.5.5.1. Stringifiers
- 2.5.5.2. Indexed properties (2)
- 2.5.5.3. Named properties (2)
- 2.5.7. Overloading (2) (3)
- 2.6. Namespaces
- 2.7. Dictionaries (2) (3) (4) (5)
- 2.10. Callback functions
- 2.11. Typedefs
- 2.13.21. Interface types (2)
- 2.13.22. Callback interface types (2)
- 2.13.23. Dictionary types (2)
- 2.13.24. Enumeration types (2)
- 2.13.25. Callback function types (2)
- 2.13.31. Annotated types
- 3.2.16. Dictionary types (2)
- 3.3.6. [Global]
- 3.3.9. [LegacyWindowAlias] (2)
- 3.3.12. [NamedConstructor]
- 3.3.16. [PutForwards] (2)
- 3.3.22. [Unforgeable] (2)
- 3.4. Security
- 3.6. Interfaces
- 3.6.1. Interface object (2) (3)
- 3.6.2. Named constructors (2)
- 3.6.3. Interface prototype object
- 3.6.4. Named properties object
- 3.6.4.1. [[GetOwnProperty]]
- 3.6.5. Constants
- 3.6.6. Attributes (2) (3) (4)
- 3.6.7. Operations (2) (3) (4) (5)
- 3.6.7.1.1. Default toJSON operation
- 3.6.7.2. Stringifiers
- 3.6.9.5. Iterator prototype object
- 3.6.9.7. Asynchronous iterator prototype object
- 3.7. Platform objects implementing interfaces (2) (3)
- 3.8.4. [[Delete]]
- 3.8.7. Abstract operations (2) (3) (4)
- 3.9. Callback interfaces
- 3.9.1. Legacy callback interface object (2)
- 3.11. Namespaces
- 3.11.1. Namespace object
- IDL grammar

#dfn-reserved-identifier Referenced in:

- 2.1. Names
- 3.3.9. [LegacyWindowAlias]
- 3.3.12. [NamedConstructor]

#dfn-interface Referenced in:

- 2. Interface definition language (2) (3)
- 2.1. Names (2) (3) (4)
- 2.2. Interfaces (2) (3) (4) (5) (6) (7) (8) (9) (10)
- 2.3. Interface mixins (2) (3) (4) (5) (6) (7) (8) (9) (10) (11)
- 2.3.1. Using mixins and partials
- 2.4. Callback interfaces
- 2.5. Members (2) (3) (4) (5) (6) (7)
- 2.5.1. Constants (2) (3) (4)
- 2.5.2. Attributes (2) (3) (4)
- 2.5.3. Operations (2) (3) (4) (5) (6) (7) (8) (9)
- 2.5.3.1. toJSON (2)
- 2.5.4. Constructor operations (2) (3) (4)
- 2.5.5. Special operations (2)
- 2.5.5.1. Stringifiers
- 2.5.5.2. Indexed properties (2)
- 2.5.5.3. Named properties (2)
- 2.5.6. Static attributes and operations
- 2.5.7. Overloading (2) (3) (4) (5)
- 2.5.8. Iterable declarations (2) (3) (4)
- 2.5.9. Asynchronously iterable declarations (2) (3) (4) (5) (6) (7) (8) (9) (10) (11) (12)
- 2.5.10. Maplike declarations
- 2.5.11. Setlike declarations
- 2.7. Dictionaries
- 2.12. Objects implementing interfaces (2)
- 2.13.21. Interface types
- 2.13.26. Nullable types — T?
- 3. ECMAScript binding
- 3.1. ECMAScript environment
- 3.2.14. Interface types
- 3.2.20.1. Creating a sequence from an iterable
- 3.3.5. [Exposed] (2) (3) (4) (5) (6) (7) (8) (9) (10) (11) (12)
- 3.3.6. [Global] (2) (3) (4)
- 3.3.7. [LegacyNamespace] (2)
- 3.3.8. [LegacyUnenumerableNamedProperties] (2)
- 3.3.9. [LegacyWindowAlias] (2) (3) (4)
- 3.3.11. [LenientThis]
- 3.3.12. [NamedConstructor] (2) (3)
- 3.3.14. [NoInterfaceObject] (2) (3) (4)
- 3.3.15. [OverrideBuiltins] (2) (3) (4)
- 3.3.16. [PutForwards] (2)
- 3.3.17. [Replaceable]
- 3.3.19. [SecureContext] (2) (3) (4) (5) (6) (7)
- 3.6. Interfaces (2)
- 3.6.1. Interface object (2) (3) (4) (5) (6) (7) (8) (9) (10) (11)
- 3.6.2. Named constructors (2) (3) (4)
- 3.6.3. Interface prototype object (2) (3) (4) (5)
- 3.6.4. Named properties object (2) (3)
- 3.6.4.1. [[GetOwnProperty]]
- 3.6.5. Constants
- 3.6.6. Attributes (2) (3) (4) (5) (6) (7)
- 3.6.7. Operations (2) (3) (4) (5) (6) (7)
- 3.6.7.1.1. Default toJSON operation (2) (3) (4) (5) (6) (7) (8)
- 3.6.7.2. Stringifiers (2)
- 3.6.8.1. @@iterator (2) (3)
- 3.6.8.2. @@asyncIterator (2)
- 3.6.8.3. forEach (2)
- 3.6.9.1. entries
- 3.6.9.2. keys (2) (3)
- 3.6.9.3. values (2) (3)
- 3.6.9.4. Default iterator objects (2) (3) (4)
- 3.6.9.5. Iterator prototype object (2) (3) (4)
- 3.6.9.6. Default asynchronous iterator objects (2) (3) (4)
- 3.6.9.7. Asynchronous iterator prototype object (2) (3) (4) (5) (6)
- 3.6.10. Maplike declarations (2)
- 3.6.11. Setlike declarations (2)
- 3.7. Platform objects implementing interfaces (2) (3) (4) (5) (6) (7) (8) (9) (10)
- 3.7.1. [[SetPrototypeOf]]
- 3.8. Legacy platform objects
- 3.8.3. [[DefineOwnProperty]] (2)
- 3.8.4. [[Delete]]
- 3.8.6. [[OwnPropertyKeys]]
- 3.11.1. Namespace object
- 3.12.4. Handling exceptions
- IDL grammar

#dfn-interface-member Referenced in:

- 2.1. Names
- 2.5.1. Constants
- 2.5.2. Attributes (2) (3)
- 2.5.3. Operations (2)
- 2.5.8. Iterable declarations
- 2.5.9. Asynchronously iterable declarations (2)
- 2.5.10. Maplike declarations
- 2.5.11. Setlike declarations
- 2.14. Extended attributes
- 3.3.5. [Exposed] (2) (3) (4) (5) (6)
- 3.3.6. [Global] (2) (3)
- 3.3.19. [SecureContext] (2) (3) (4)
- 3.6.7.1.1. Default toJSON operation
- 3.8. Legacy platform objects

#dfn-inherit Referenced in:

- 2.2. Interfaces (2) (3) (4)
- 2.5. Members
- 2.7. Dictionaries
- 3.3.5. [Exposed]
- 3.3.6. [Global] (2)
- 3.3.19. [SecureContext]
- 3.6.7.1.1. Default toJSON operation
- 3.7. Platform objects implementing interfaces

#dfn-inherited-interfaces Referenced in:

- 2.2. Interfaces (2)
- 2.5.3.1. toJSON
- 2.5.8. Iterable declarations (2) (3)
- 2.5.9. Asynchronously iterable declarations (2) (3)
- 2.5.10. Maplike declarations (2) (3) (4)
- 2.5.11. Setlike declarations (2) (3) (4)
- 3.3.22. [Unforgeable]
- 3.6.3. Interface prototype object (2)
- 3.6.4. Named properties object
- 3.6.7.1.1. Default toJSON operation (2)

#interface-inclusive-inherited-interfaces Referenced in:

- 3.7. Platform objects implementing interfaces (2)

#dfn-partial-interface Referenced in:

- 2. Interface definition language
- 2.1. Names
- 2.2. Interfaces (2)
- 2.3. Interface mixins (2)
- 2.3.1. Using mixins and partials
- 2.5.7. Overloading (2)
- 3.3.5. [Exposed] (2) (3) (4) (5) (6)
- 3.3.6. [Global]
- 3.3.15. [OverrideBuiltins] (2)
- 3.3.19. [SecureContext] (2) (3) (4)

#qualified-name Referenced in:

- 3.6.3. Interface prototype object
- 3.7. Platform objects implementing interfaces

#interface-mixin Referenced in:

- 2. Interface definition language
- 2.2. Interfaces
- 2.3. Interface mixins (2) (3) (4) (5) (6) (7) (8) (9) (10) (11) (12) (13) (14) (15) (16) (17) (18) (19)
- 2.3.1. Using mixins and partials (2) (3)
- 2.5. Members (2) (3) (4) (5) (6) (7)
- 2.5.7. Overloading
- 3.3.5. [Exposed] (2) (3) (4) (5) (6) (7) (8) (9) (10)
- 3.3.10. [LenientSetter]
- 3.3.14. [NoInterfaceObject] (2)
- 3.3.19. [SecureContext] (2) (3) (4) (5)
- 3.6.7.1.1. Default toJSON operation (2)
- 3.7. Platform objects implementing interfaces (2) (3) (4)

#interface-mixin-member Referenced in:

- 2.2. Interfaces
- 2.3. Interface mixins (2) (3) (4) (5) (6) (7)
- 2.14. Extended attributes
- 3.3.5. [Exposed] (2) (3) (4) (5) (6) (7) (8) (9) (10) (11)
- 3.3.19. [SecureContext] (2) (3) (4) (5)

#partial-interface-mixin Referenced in:

- 2. Interface definition language
- 2.3. Interface mixins (2) (3)
- 2.3.1. Using mixins and partials
- 2.5.7. Overloading
- 3.3.5. [Exposed] (2) (3) (4) (5) (6) (7) (8)
- 3.3.19. [SecureContext] (2) (3) (4)

#includes-statement Referenced in:

- 2. Interface definition language
- 2.2. Interfaces
- 2.3. Interface mixins (2) (3)
- 3.3.14. [NoInterfaceObject]

#include Referenced in:

- 2.2. Interfaces
- 2.3. Interface mixins (2) (3) (4) (5) (6) (7)
- 2.5. Members (2)
- 3.3.5. [Exposed] (2)
- 3.6.7.1.1. Default toJSON operation
- 3.7. Platform objects implementing interfaces (2)

#host-interfaces Referenced in:

- 2.3. Interface mixins
- 3.3.5. [Exposed] (2) (3)
- 3.3.19. [SecureContext]

#dfn-callback-interface Referenced in:

- 2. Interface definition language
- 2.1. Names (2) (3)
- 2.2. Interfaces (2)
- 2.4. Callback interfaces (2) (3) (4) (5) (6)
- 2.5. Members (2)
- 2.5.1. Constants (2) (3)
- 2.5.2. Attributes
- 2.5.3. Operations (2) (3)
- 2.7. Dictionaries
- 2.10. Callback functions
- 2.12. Objects implementing interfaces
- 2.13.22. Callback interface types (2)
- 3.2.23. Union types
- 3.3.5. [Exposed] (2) (3) (4) (5)
- 3.3.19. [SecureContext] (2) (3)
- 3.6.5. Constants
- 3.7. Platform objects implementing interfaces
- 3.9. Callback interfaces (2) (3)
- 3.9.1. Legacy callback interface object (2) (3) (4)
- 3.10. Invoking callback functions

#callback-interface-member Referenced in:

- 2.5.1. Constants
- 2.5.3. Operations (2)
- 2.14. Extended attributes

#dfn-member Referenced in:

- 2.2. Interfaces
- 2.3. Interface mixins (2) (3) (4) (5)
- 2.4. Callback interfaces
- 2.5. Members (2)
- 2.5.8. Iterable declarations
- 2.5.10. Maplike declarations
- 2.5.11. Setlike declarations
- 3.3.5. [Exposed] (2) (3) (4)
- 3.3.6. [Global] (2)
- 3.3.19. [SecureContext] (2)
- 3.6.3. Interface prototype object (2)
- 3.6.5. Constants
- 3.6.6. Attributes (2) (3)
- 3.6.7. Operations (2) (3)
- 3.6.10.5. clear
- 3.6.10.6. delete
- 3.6.10.7. set
- 3.6.11.5. add and delete
- 3.6.11.6. clear
- 3.7. Platform objects implementing interfaces

#this Referenced in:

- 2.5.2. Attributes
- 2.5.4. Constructor operations
- 3.6.1. Interface object
- 3.6.2. Named constructors
- 3.6.6. Attributes (2)
- 3.6.7. Operations (2)

#the-given-value Referenced in:

- 3.6.6. Attributes

#dfn-constant Referenced in:

- 2.1. Names (2)
- 2.3. Interface mixins (2)
- 2.3.1. Using mixins and partials (2)
- 2.4. Callback interfaces
- 2.5. Members (2) (3)
- 2.5.1. Constants (2) (3) (4) (5) (6) (7)
- 2.5.3. Operations (2)
- 2.5.10. Maplike declarations (2)
- 2.5.11. Setlike declarations (2)
- 2.7. Dictionaries
- 2.10. Callback functions
- 2.13. Types
- 2.13.27. Sequence types — sequence<T>
- 2.13.28. Record types — record<K, V>
- 3.6.1. Interface object
- 3.6.5. Constants (2)
- 3.7. Platform objects implementing interfaces
- 3.9. Callback interfaces
- 3.9.1. Legacy callback interface object (2)

#dfn-attribute Referenced in:

- 2. Interface definition language
- 2.1. Names (2) (3)
- 2.3. Interface mixins
- 2.3.1. Using mixins and partials (2)
- 2.5. Members (2) (3) (4)
- 2.5.2. Attributes (2)
- 2.5.3. Operations
- 2.5.3.1. toJSON
- 2.5.5.1. Stringifiers
- 2.5.5.2. Indexed properties
- 2.5.10. Maplike declarations (2)
- 2.5.11. Setlike declarations (2)
- 2.7. Dictionaries
- 2.9. Enumerations (2) (3) (4)
- 2.13. Types
- 2.13.26. Nullable types — T?
- 2.13.27. Sequence types — sequence<T> (2)
- 2.13.28. Record types — record<K, V>
- 3.2.18. Callback function types
- 3.2.19. Nullable types — T?
- 3.2.20.1. Creating a sequence from an iterable
- 3.2.22.2. Examples
- 3.3.10. [LenientSetter] (2)
- 3.3.11. [LenientThis]
- 3.3.16. [PutForwards] (2) (3) (4)
- 3.3.17. [Replaceable] (2) (3)
- 3.3.18. [SameObject] (2)
- 3.3.20. [TreatNonObjectAsNull]
- 3.3.22. [Unforgeable]
- 3.4. Security
- 3.6.6. Attributes (2) (3) (4) (5)
- 3.6.7.2. Stringifiers

#dfn-regular-attribute Referenced in:

- 2.3. Interface mixins (2)
- 2.5. Members (2) (3)
- 2.5.2. Attributes (2) (3) (4)
- 2.6. Namespaces
- 3.3.10. [LenientSetter] (2)
- 3.3.11. [LenientThis]
- 3.3.16. [PutForwards]
- 3.3.17. [Replaceable]
- 3.3.22. [Unforgeable] (2) (3)
- 3.3.23. [Unscopable] (2)
- 3.6.1. Interface object
- 3.6.6. Attributes (2) (3) (4) (5)
- 3.6.7.1.1. Default toJSON operation

#get-the-underlying-value Referenced in:

- 2.5.3.1. toJSON
- 3.6.6. Attributes
- 3.6.7.1.1. Default toJSON operation

#dfn-read-only Referenced in:

- 2. Interface definition language
- 2.5. Members
- 2.5.2. Attributes (2) (3) (4)
- 2.6. Namespaces
- 3.3.2. [Clamp]
- 3.3.4. [EnforceRange]
- 3.3.10. [LenientSetter] (2)
- 3.3.16. [PutForwards] (2)
- 3.3.17. [Replaceable] (2)
- 3.3.18. [SameObject] (2)
- 3.6.6. Attributes (2) (3) (4)

#dfn-inherit-getter Referenced in:

- 2.5.2. Attributes
- 3.6.7.2. Stringifiers

#dfn-operation Referenced in:

- 2. Interface definition language
- 2.1. Names (2)
- 2.3.1. Using mixins and partials (2)
- 2.5. Members (2)
- 2.5.3. Operations (2)
- 2.5.5.1. Stringifiers
- 2.5.5.2. Indexed properties (2) (3)
- 2.5.5.3. Named properties (2)
- 2.5.7. Overloading (2) (3) (4)
- 2.5.7.1. Overloading vs. union types
- 2.7. Dictionaries (2)
- 2.8. Exceptions
- 2.9. Enumerations (2) (3) (4)
- 2.13. Types
- 2.13.2. void
- 2.13.27. Sequence types — sequence<T>
- 2.14. Extended attributes
- 3.2.20.1. Creating a sequence from an iterable
- 3.2.22.2. Examples (2) (3) (4)
- 3.3.2. [Clamp]
- 3.3.4. [EnforceRange]
- 3.3.5. [Exposed]
- 3.3.13. [NewObject] (2)
- 3.3.17. [Replaceable]
- 3.3.19. [SecureContext] (2)
- 3.3.22. [Unforgeable] (2) (3) (4)
- 3.4. Security
- 3.5. Overload resolution algorithm (2)
- 3.6.7. Operations (2) (3) (4)
- 3.6.7.1.1. Default toJSON operation
- 3.6.7.2. Stringifiers (2)
- 3.6.8.3. forEach
- 3.9. Callback interfaces
- 3.10. Invoking callback functions

#dfn-regular-operation Referenced in:

- 2.1. Names
- 2.3. Interface mixins (2) (3)
- 2.4. Callback interfaces
- 2.5. Members (2)
- 2.5.3. Operations (2) (3) (4)
- 2.5.3.1. toJSON (2) (3) (4)
- 2.5.7. Overloading (2) (3) (4)
- 2.6. Namespaces
- 3.3.3. [Default] (2) (3)
- 3.3.13. [NewObject] (2)
- 3.3.23. [Unscopable] (2)
- 3.6.1. Interface object
- 3.6.7. Operations (2) (3) (4) (5)
- 3.6.7.1. Default operations

#dfn-return-type Referenced in:

- 2.5.5.1. Stringifiers
- 2.8. Exceptions
- 2.13.2. void
- 3.3.13. [NewObject]
- 3.6.7. Operations
- 3.6.7.1.1. Default toJSON operation
- 3.8.4. [[Delete]]
- 3.9. Callback interfaces
- 3.10. Invoking callback functions

#dfn-variadic Referenced in:

- 2.5.3. Operations (2) (3) (4)
- 2.5.5. Special operations
- 2.5.7. Overloading (2) (3) (4)

#dfn-optional-argument Referenced in:

- 2.5.3. Operations (2)
- 2.5.5. Special operations
- 2.5.7. Overloading (2) (3) (4)
- 2.5.7.1. Overloading vs. union types (2) (3) (4) (5) (6) (7) (8) (9) (10)
- 2.13.16. DOMString
- 2.13.17. ByteString
- 2.13.18. USVString
- 2.13.24. Enumeration types

#dfn-optional-argument-default-value Referenced in:

- 2.5.1. Constants
- 2.5.3. Operations (2) (3) (4)
- 2.7. Dictionaries (2)
- 2.13.16. DOMString
- 2.13.17. ByteString
- 2.13.18. USVString
- 2.13.24. Enumeration types
- 3.5. Overload resolution algorithm (2) (3) (4)

#value-of-string-literal-tokens Referenced in:

- 2.13.16. DOMString
- 2.13.17. ByteString
- 2.13.18. USVString
- 2.13.24. Enumeration types

#dfn-code-unit Referenced in:

- 2.13.16. DOMString (2) (3)
- 2.13.18. USVString
- 2.13.24. Enumeration types
- 3.2.9. DOMString
- 3.2.11. USVString (2)
- 3.2.17. Enumeration types

#dfn-json-types Referenced in:

- 2.1. Names
- 2.5.3.1. toJSON (2) (3) (4) (5) (6) (7) (8) (9) (10) (11) (12)
- 3.6.7.1.1. Default toJSON operation

#idl-constructors Referenced in:

- 2. Interface definition language
- 2.5.3. Operations
- 2.5.4. Constructor operations (2) (3) (4) (5) (6)
- 2.5.7. Overloading (2) (3) (4) (5) (6)
- 3.3.6. [Global]
- 3.6.1. Interface object (2) (3) (4) (5)

#dfn-special-operation Referenced in:

- 2.1. Names
- 2.3. Interface mixins
- 2.5. Members
- 2.5.3. Operations

#dfn-special-keyword Referenced in:

- 2.5.3. Operations
- 2.5.5. Special operations

#dfn-getter Referenced in:

- 3.8. Legacy platform objects

#dfn-setter Referenced in:

- 3.8. Legacy platform objects

#dfn-stringifier Referenced in:

- 2.3. Interface mixins (2) (3)
- 2.5. Members
- 2.5.5.1. Stringifiers
- 3.3.6. [Global]
- 3.6.7.2. Stringifiers (2) (3)

#dfn-named-property-getter Referenced in:

- 2.5.5. Special operations
- 2.5.5.3. Named properties (2) (3)
- 3.3.6. [Global]
- 3.3.8. [LegacyUnenumerableNamedProperties]
- 3.3.15. [OverrideBuiltins] (2) (3)

#dfn-named-property-setter Referenced in:

- 2.5.5.3. Named properties (2)
- 3.3.6. [Global]
- 3.8.2. [[Set]]
- 3.8.3. [[DefineOwnProperty]] (2)
- 3.8.7. Abstract operations

#dfn-indexed-property-getter Referenced in:

- 2.5.5.2. Indexed properties (2) (3)
- 2.5.8. Iterable declarations
- 2.5.10. Maplike declarations
- 2.5.11. Setlike declarations
- 3.3.6. [Global]
- 3.6.8.1. @@iterator (2)
- 3.6.8.3. forEach
- 3.8. Legacy platform objects

#dfn-indexed-property-setter Referenced in:

- 2.5.5.2. Indexed properties (2)
- 3.3.6. [Global]
- 3.8. Legacy platform objects
- 3.8.2. [[Set]]
- 3.8.3. [[DefineOwnProperty]]
- 3.8.7. Abstract operations

#dfn-named-property-deleter Referenced in:

- 2.5.5. Special operations (2)
- 2.5.5.3. Named properties (2)
- 3.8.4. [[Delete]]

#dfn-stringification-behavior Referenced in:

- 3.6.7.2. Stringifiers

#idl-indexed-properties Referenced in:

- 2.5.5. Special operations
- 2.5.5.3. Named properties
- 3.8. Legacy platform objects

#dfn-support-indexed-properties Referenced in:

- 2.5.5.2. Indexed properties (2) (3)
- 2.5.8. Iterable declarations (2) (3) (4) (5)
- 2.12. Objects implementing interfaces
- 3.6.9.4. Default iterator objects
- 3.7. Platform objects implementing interfaces
- 3.8.3. [[DefineOwnProperty]]
- 3.8.4. [[Delete]]
- 3.8.6. [[OwnPropertyKeys]]
- 3.8.7. Abstract operations

#dfn-supported-property-indices Referenced in:

- 2.5.5.2. Indexed properties (2) (3)
- 3.8. Legacy platform objects
- 3.8.4. [[Delete]]
- 3.8.6. [[OwnPropertyKeys]]
- 3.8.7. Abstract operations (2)

#dfn-determine-the-value-of-an-indexed-property Referenced in:

- 3.8.7. Abstract operations

#dfn-set-the-value-of-an-existing-indexed-property Referenced in:

- 3.8.7. Abstract operations

#dfn-set-the-value-of-a-new-indexed-property Referenced in:

- 3.8.7. Abstract operations

#idl-named-properties Referenced in:

- 2.5.5. Special operations
- 3.3.6. [Global] (2)
- 3.8. Legacy platform objects

#dfn-support-named-properties Referenced in:

- 2.5.5.3. Named properties (2)
- 2.12. Objects implementing interfaces
- 3.3.8. [LegacyUnenumerableNamedProperties]
- 3.6.3. Interface prototype object
- 3.6.4. Named properties object
- 3.7. Platform objects implementing interfaces
- 3.8.3. [[DefineOwnProperty]]
- 3.8.4. [[Delete]]
- 3.8.6. [[OwnPropertyKeys]]
- 3.8.7. Abstract operations

#dfn-supported-property-names Referenced in:

- 2.5.5.3. Named properties (2)
- 3.3.15. [OverrideBuiltins]
- 3.8.3. [[DefineOwnProperty]]
- 3.8.6. [[OwnPropertyKeys]]
- 3.8.7. Abstract operations (2)

#dfn-determine-the-value-of-a-named-property Referenced in:

- 3.6.4.1. [[GetOwnProperty]]
- 3.8.7. Abstract operations

#dfn-set-the-value-of-an-existing-named-property Referenced in:

- 3.8.7. Abstract operations

#dfn-set-the-value-of-a-new-named-property Referenced in:

- 3.8.7. Abstract operations

#dfn-delete-an-existing-named-property Referenced in:

- 3.8.4. [[Delete]]

#dfn-static-attribute Referenced in:

- 2.3. Interface mixins
- 2.5. Members
- 2.5.2. Attributes (2) (3)
- 2.5.5.1. Stringifiers
- 3.3.11. [LenientThis]
- 3.3.16. [PutForwards]
- 3.3.17. [Replaceable]
- 3.6.6. Attributes (2)

#dfn-static-operation Referenced in:

- 2.3. Interface mixins
- 2.5. Members
- 2.5.3. Operations (2) (3)
- 2.5.7. Overloading (2) (3)
- 3.3.13. [NewObject] (2)
- 3.3.14. [NoInterfaceObject]
- 3.3.22. [Unforgeable] (2) (3)
- 3.6.1. Interface object
- 3.6.7. Operations (2) (3) (4) (5)

#dfn-overloaded Referenced in:

- 2.5.3. Operations
- 2.5.7.1. Overloading vs. union types (2) (3) (4) (5) (6) (7) (8) (9) (10)
- 3.3.5. [Exposed]
- 3.3.19. [SecureContext]

#dfn-effective-overload-set Referenced in:

- 2.5.7. Overloading (2) (3) (4) (5) (6) (7) (8) (9) (10) (11)
- 3.5. Overload resolution algorithm

#effective-overload-set-tuple-callable Referenced in:

- 2.5.7. Overloading

#type-list Referenced in:

- 2.5.7. Overloading (2) (3) (4) (5)

#optionality-list Referenced in:

- 2.5.7. Overloading (2) (3) (4)

#dfn-optionality-value Referenced in:

- 2.5.7. Overloading
- 3.5. Overload resolution algorithm (2) (3) (4)

#compute-the-effective-overload-set Referenced in:

- 2.5.7. Overloading
- 3.6.1. Interface object (2)
- 3.6.2. Named constructors (2)
- 3.6.7. Operations (2)

#dfn-distinguishable Referenced in:

- 2.5.7. Overloading (2) (3)
- 2.13.30. Union types

#dfn-distinguishing-argument-index Referenced in:

- 2.5.7. Overloading (2) (3)
- 3.5. Overload resolution algorithm (2)

#dfn-iterable-declaration Referenced in:

- 2.3. Interface mixins
- 2.5. Members
- 2.5.8. Iterable declarations (2) (3) (4) (5)
- 2.5.9. Asynchronously iterable declarations
- 2.5.10. Maplike declarations
- 2.5.11. Setlike declarations
- 3.3.6. [Global]
- 3.6.8.1. @@iterator (2)
- 3.6.8.3. forEach (2)
- 3.6.9.1. entries
- 3.6.9.2. keys (2)
- 3.6.9.3. values (2)

#dfn-value-iterator Referenced in:

- 2.5.8. Iterable declarations (2) (3) (4) (5) (6)
- 3.6.9.1. entries
- 3.6.9.2. keys
- 3.6.9.3. values
- 3.6.9.4. Default iterator objects

#dfn-pair-iterator Referenced in:

- 2.5.8. Iterable declarations (2) (3)
- 3.6.8.1. @@iterator (2)
- 3.6.8.3. forEach
- 3.6.9.1. entries
- 3.6.9.2. keys
- 3.6.9.3. values
- 3.6.9.4. Default iterator objects
- 3.6.9.5. Iterator prototype object

#value-pair Referenced in:

- 2.5.8. Iterable declarations (2) (3) (4) (5)
- 3.6.9.5. Iterator prototype object

#value-pair-key Referenced in:

- 2.5.8. Iterable declarations
- 3.6.8.3. forEach
- 3.6.9.5. Iterator prototype object (2)

#value-pair-value Referenced in:

- 2.5.8. Iterable declarations
- 3.6.8.3. forEach
- 3.6.9.5. Iterator prototype object (2)

#dfn-value-pairs-to-iterate-over Referenced in:

- 2.5.8. Iterable declarations
- 3.6.8.3. forEach (2)
- 3.6.9.5. Iterator prototype object

#dfn-async-iterable-declaration Referenced in:

- 2.3. Interface mixins
- 2.5. Members
- 2.5.8. Iterable declarations
- 2.5.9. Asynchronously iterable declarations (2) (3) (4) (5) (6) (7)
- 2.5.10. Maplike declarations
- 2.5.11. Setlike declarations
- 3.3.6. [Global]
- 3.6.8.2. @@asyncIterator (2)
- 3.6.9.1. entries (2)
- 3.6.9.2. keys (2) (3)
- 3.6.9.3. values (2) (3)
- 3.6.9.7. Asynchronous iterator prototype object

#dfn-get-the-next-iteration-result Referenced in:

- 2.5.9. Asynchronously iterable declarations
- 3.6.9.7. Asynchronous iterator prototype object

#asynchronous-iterator-return Referenced in:

- 3.6.9.7. Asynchronous iterator prototype object (2)

#asynchronous-iterator-initialization-steps Referenced in:

- 2.5.9. Asynchronously iterable declarations
- 3.6.8.2. @@asyncIterator
- 3.6.9.2. keys
- 3.6.9.3. values

#sessionmanager-async-iterator-current-state Referenced in:

- 2.5.9. Asynchronously iterable declarations (2) (3)

#dfn-maplike Referenced in:

- 2.5.10. Maplike declarations

#dfn-maplike-declaration Referenced in:

- 2.3. Interface mixins
- 2.5. Members
- 2.5.8. Iterable declarations
- 2.5.9. Asynchronously iterable declarations
- 2.5.10. Maplike declarations (2) (3)
- 2.5.11. Setlike declarations
- 3.3.6. [Global]
- 3.6.8.1. @@iterator (2) (3) (4) (5)
- 3.6.8.3. forEach (2) (3) (4)
- 3.6.10. Maplike declarations (2)
- 3.6.10.4. get and has
- 3.6.10.6. delete
- 3.6.10.7. set

#dfn-map-entries Referenced in:

- 2.5.10. Maplike declarations (2)
- 3.6.10. Maplike declarations

#dfn-setlike Referenced in:

- 2.5.11. Setlike declarations

#dfn-setlike-declaration Referenced in:

- 2.3. Interface mixins
- 2.5. Members
- 2.5.8. Iterable declarations
- 2.5.9. Asynchronously iterable declarations
- 2.5.10. Maplike declarations
- 2.5.11. Setlike declarations (2) (3)
- 3.3.6. [Global]
- 3.6.8.1. @@iterator (2) (3) (4)
- 3.6.8.3. forEach (2) (3)
- 3.6.11. Setlike declarations (2)
- 3.6.11.4. has
- 3.6.11.5. add and delete

#dfn-set-entries Referenced in:

- 2.5.11. Setlike declarations (2)
- 3.6.11. Setlike declarations

#dfn-namespace Referenced in:

- 2. Interface definition language
- 2.1. Names (2) (3)
- 2.5. Members (2) (3) (4)
- 2.5.3. Operations
- 2.6. Namespaces (2)
- 3.3.5. [Exposed] (2) (3) (4) (5) (6) (7) (8) (9)
- 3.3.7. [LegacyNamespace] (2)
- 3.3.10. [LenientSetter]
- 3.3.11. [LenientThis]
- 3.3.16. [PutForwards]
- 3.3.17. [Replaceable]
- 3.3.19. [SecureContext] (2) (3) (4) (5) (6)
- 3.3.22. [Unforgeable]
- 3.3.23. [Unscopable]
- 3.6.6. Attributes (2) (3) (4) (5) (6) (7)
- 3.6.7. Operations (2) (3) (4) (5)
- 3.7. Platform objects implementing interfaces
- 3.11. Namespaces
- 3.11.1. Namespace object

#dfn-namespace-member Referenced in:

- 2.5.2. Attributes (2)
- 2.5.3. Operations (2)
- 2.14. Extended attributes
- 3.3.5. [Exposed] (2) (3) (4) (5) (6)
- 3.3.19. [SecureContext] (2) (3) (4)

#dfn-partial-namespace Referenced in:

- 2. Interface definition language
- 2.1. Names
- 3.3.5. [Exposed] (2) (3) (4) (5) (6)
- 3.3.19. [SecureContext] (2) (3) (4)

#dfn-dictionary Referenced in:

- 2. Interface definition language
- 2.1. Names (2) (3)
- 2.3. Interface mixins
- 2.5.3. Operations (2)
- 2.5.5. Special operations
- 2.7. Dictionaries
- 2.13.23. Dictionary types
- 3.2.16. Dictionary types

#dfn-dictionary-member Referenced in:

- 2.1. Names (2)
- 2.5.3.1. toJSON
- 2.7. Dictionaries (2) (3) (4) (5) (6) (7)
- 2.13.16. DOMString
- 2.13.17. ByteString
- 2.13.18. USVString
- 2.13.24. Enumeration types
- 2.14. Extended attributes
- 3.2.16. Dictionary types (2) (3)

#dfn-inherit-dictionary Referenced in:

- 2.7. Dictionaries (2)

#dfn-inherited-dictionaries Referenced in:

- 2.5.3.1. toJSON
- 2.7. Dictionaries (2) (3)
- 3.2.16. Dictionary types (2)

#dfn-present Referenced in:

- 2.5.7.1. Overloading vs. union types (2)
- 2.7. Dictionaries (2)
- 3.2.16. Dictionary types (2) (3) (4)

#dfn-dictionary-member-default-value Referenced in:

- 2.5.1. Constants
- 2.7. Dictionaries (2) (3) (4) (5) (6)
- 2.13.16. DOMString
- 2.13.17. ByteString
- 2.13.18. USVString
- 2.13.24. Enumeration types
- 3.2.16. Dictionary types

#required-dictionary-member Referenced in:

- 2.5.3. Operations
- 3.2.16. Dictionary types

#dfn-partial-dictionary Referenced in:

- 2. Interface definition language
- 2.1. Names

#dfn-exception Referenced in:

- 3.12.4. Handling exceptions

#dfn-exception-error-name Referenced in:

- 2.8. Exceptions (2) (3) (4) (5) (6)
- 3.12.3. Creating and throwing exceptions (2)

#dfn-simple-exception Referenced in:

- 2.8. Exceptions (2) (3) (4)
- 3.12.2. Exception objects
- 3.12.3. Creating and throwing exceptions (2) (3) (4)

#exceptiondef-rangeerror Referenced in:

- 2.8.1. Error names (2)
- 3.2.22.2. Examples

#exceptiondef-typeerror Referenced in:

- 2.5.4. Constructor operations
- 2.5.7.1. Overloading vs. union types
- 2.8. Exceptions (2)
- 2.8.1. Error names (2)
- 3.2.22.2. Examples

#dfn-create-exception Referenced in:

- 2.8. Exceptions (2) (3)
- 3.12.3. Creating and throwing exceptions (2)

#dfn-throw Referenced in:

- 2.8. Exceptions (2)
- 3.12.3. Creating and throwing exceptions

#dfn-error-names-table Referenced in:

- 2.8. Exceptions
- 4.3. DOMException

#dom-domexception-index_size_err Referenced in:

- 4.3. DOMException

#dom-domexception-domstring_size_err Referenced in:

- 4.3. DOMException

#dom-domexception-hierarchy_request_err Referenced in:

- 4.3. DOMException

#dom-domexception-wrong_document_err Referenced in:

- 4.3. DOMException

#dom-domexception-invalid_character_err Referenced in:

- 4.3. DOMException

#dom-domexception-no_data_allowed_err Referenced in:

- 4.3. DOMException

#dom-domexception-no_modification_allowed_err Referenced in:

- 4.3. DOMException

#dom-domexception-not_found_err Referenced in:

- 4.3. DOMException

#notsupportederror Referenced in:

- 2.8.1. Error names
- 3.2.22.2. Examples
- 3.12.3. Creating and throwing exceptions

#dom-domexception-not_supported_err Referenced in:

- 4.3. DOMException

#dom-domexception-inuse_attribute_err Referenced in:

- 4.3. DOMException

#dom-domexception-invalid_state_err Referenced in:

- 4.3. DOMException

#syntaxerror Referenced in:

- 2.8. Exceptions (2)
- 2.8.1. Error names (2) (3) (4)

#dom-domexception-syntax_err Referenced in:

- 4.3. DOMException

#dom-domexception-invalid_modification_err Referenced in:

- 4.3. DOMException

#dom-domexception-namespace_err Referenced in:

- 4.3. DOMException

#dom-domexception-invalid_access_err Referenced in:

- 4.3. DOMException

#dom-domexception-validation_err Referenced in:

- 4.3. DOMException

#dom-domexception-type_mismatch_err Referenced in:

- 4.3. DOMException

#securityerror Referenced in:

- 3.2.22.2. Examples

#dom-domexception-security_err Referenced in:

- 4.3. DOMException

#networkerror Referenced in:

- 3.2.22.2. Examples

#dom-domexception-network_err Referenced in:

- 4.3. DOMException

#aborterror Referenced in:

- 3.2.22.2. Examples

#dom-domexception-abort_err Referenced in:

- 4.3. DOMException

#dom-domexception-url_mismatch_err Referenced in:

- 4.3. DOMException

#dom-domexception-quota_exceeded_err Referenced in:

- 4.3. DOMException

#dom-domexception-timeout_err Referenced in:

- 4.3. DOMException

#dom-domexception-invalid_node_type_err Referenced in:

- 4.3. DOMException

#dom-domexception-data_clone_err Referenced in:

- 4.3. DOMException

#notallowederror Referenced in:

- 2.8. Exceptions (2)
- 2.8.1. Error names

#dfn-enumeration Referenced in:

- 2.1. Names (2) (3)
- 2.5.2. Attributes
- 2.5.3. Operations (2) (3) (4)
- 2.7. Dictionaries (2)
- 2.9. Enumerations (2) (3)
- 2.13.24. Enumeration types (2)
- 3.2.17. Enumeration types (2) (3)
- 3.6.6. Attributes

#dfn-enumeration-value Referenced in:

- 2.5.3. Operations
- 2.7. Dictionaries
- 2.9. Enumerations
- 2.13.24. Enumeration types
- 3.2.17. Enumeration types (2)
- 3.6.6. Attributes

#dfn-callback-function Referenced in:

- 2. Interface definition language
- 2.1. Names (2) (3)
- 2.4. Callback interfaces (2) (3)
- 2.5.2. Attributes
- 2.5.3. Operations (2) (3)
- 2.5.7. Overloading
- 2.7. Dictionaries
- 2.10. Callback functions (2) (3)
- 2.13.25. Callback function types (2)
- 3.2.18. Callback function types
- 3.2.19. Nullable types — T?
- 3.2.23. Union types
- 3.3.20. [TreatNonObjectAsNull] (2) (3) (4) (5)
- 3.5. Overload resolution algorithm
- 3.10. Invoking callback functions
- 4.5. Function
- 4.6. VoidFunction

#dfn-typedef Referenced in:

- 2. Interface definition language
- 2.1. Names (2) (3) (4)
- 2.5.1. Constants
- 2.5.2. Attributes
- 2.5.3. Operations (2)
- 2.5.3.1. toJSON
- 2.5.7.1. Overloading vs. union types
- 2.7. Dictionaries
- 2.11. Typedefs (2) (3)
- 2.13.31. Annotated types

#type-being-given-a-new-name Referenced in:

- 2.5.3.1. toJSON
- 2.13.31. Annotated types

#dfn-platform-object Referenced in:

- 2.5.5.2. Indexed properties
- 2.5.5.3. Named properties
- 2.5.7. Overloading
- 2.7. Dictionaries (2)
- 2.12. Objects implementing interfaces (2) (3) (4)
- 2.13.27. Sequence types — sequence<T>
- 2.13.28. Record types — record<K, V>
- 3. ECMAScript binding
- 3.1. ECMAScript environment
- 3.2. ECMAScript type mapping
- 3.3.17. [Replaceable] (2)
- 3.4. Security
- 3.7. Platform objects implementing interfaces (2) (3) (4) (5) (6) (7) (8) (9)
- 3.7.1. [[SetPrototypeOf]]
- 3.8.6. [[OwnPropertyKeys]]
- 3.12.2. Exception objects

#dfn-legacy-platform-object Referenced in:

- 2.5.5.2. Indexed properties
- 3.3.15. [OverrideBuiltins]
- 3.8. Legacy platform objects (2)
- 3.8.1. [[GetOwnProperty]]
- 3.8.2. [[Set]]
- 3.8.3. [[DefineOwnProperty]]
- 3.8.4. [[Delete]]
- 3.8.5. [[PreventExtensions]] (2)
- 3.8.6. [[OwnPropertyKeys]] (2)

#dfn-integer-type Referenced in:

- 2.5.5.2. Indexed properties
- 2.13. Types
- 3.3.2. [Clamp] (2)
- 3.3.4. [EnforceRange] (2)

#dfn-numeric-type Referenced in:

- 2.5.3.1. toJSON
- 2.5.7. Overloading (2) (3) (4)
- 2.13. Types
- 3.2.23. Union types (2) (3) (4)
- 3.5. Overload resolution algorithm (2) (3) (4)

#dfn-primitive-type Referenced in:

- 2.5.1. Constants

#dfn-string-type Referenced in:

- 2.5.3. Operations
- 2.5.3.1. toJSON
- 2.5.7. Overloading
- 3.2.23. Union types
- 3.5. Overload resolution algorithm

#dfn-typed-array-type Referenced in:

- 2.13. Types
- 3.2.23. Union types
- 3.5. Overload resolution algorithm

#dfn-buffer-source-type Referenced in:

- 2.5.7. Overloading
- 2.13.32. Buffer source types
- 3.2.24. Buffer source types (2)
- 3.3.1. [AllowShared] (2) (3)

#dfn-type-name Referenced in:

- 2.13.1. any
- 2.13.2. void
- 2.13.3. boolean
- 2.13.4. byte
- 2.13.5. octet
- 2.13.6. short
- 2.13.7. unsigned short
- 2.13.8. long
- 2.13.9. unsigned long
- 2.13.10. long long
- 2.13.11. unsigned long long
- 2.13.12. float
- 2.13.13. unrestricted float
- 2.13.14. double
- 2.13.15. unrestricted double
- 2.13.16. DOMString
- 2.13.17. ByteString
- 2.13.18. USVString
- 2.13.19. object
- 2.13.20. symbol
- 2.13.21. Interface types
- 2.13.22. Callback interface types
- 2.13.23. Dictionary types
- 2.13.24. Enumeration types
- 2.13.25. Callback function types
- 2.13.26. Nullable types — T?
- 2.13.27. Sequence types — sequence<T>
- 2.13.28. Record types — record<K, V>
- 2.13.29. Promise types — Promise<T>
- 2.13.30. Union types
- 2.13.31. Annotated types (2)
- 2.13.32. Buffer source types
- 2.13.33. Frozen array types — FrozenArray<T>
- 3.2.24. Buffer source types (2)

#idl-any Referenced in:

- 2.5.7.1. Overloading vs. union types
- 2.5.9. Asynchronously iterable declarations
- 2.13.1. any (2) (3) (4) (5)
- 2.13.26. Nullable types — T?
- 2.13.30. Union types (2)
- 3.2.1. any (2) (3) (4)
- 3.2.22.1. Creating and manipulating Promises (2)
- 3.5. Overload resolution algorithm
- 8. Privacy and Security Considerations

#dfn-specific-type Referenced in:

- 2.13.1. any
- 2.13.30. Union types
- 3.2.1. any
- 3.2.23. Union types

#idl-void Referenced in:

- 2.5.3. Operations
- 2.5.7.1. Overloading vs. union types (2)
- 2.13.2. void (2)
- 3.2.2. void (2) (3)
- 3.2.22.1. Creating and manipulating Promises (2) (3)
- 3.2.22.2. Examples
- 3.10. Invoking callback functions

#idl-boolean Referenced in:

- 2.5.1. Constants
- 2.5.3. Operations
- 2.5.3.1. toJSON
- 2.7. Dictionaries
- 2.13. Types
- 2.13.3. boolean (2) (3)
- 3.2.1. any
- 3.2.3. boolean (2) (3) (4)
- 3.2.23. Union types (2) (3) (4)
- 3.5. Overload resolution algorithm (2) (3) (4)
- 3.8.4. [[Delete]]

#idl-byte Referenced in:

- 2.13. Types
- 2.13.4. byte (2) (3)
- 2.13.17. ByteString
- 3.2.4.1. byte (2) (3) (4)

#idl-octet Referenced in:

- 2.13. Types
- 2.13.5. octet (2) (3)
- 2.13.17. ByteString
- 3.2.4.2. octet (2) (3) (4)
- 3.3.2. [Clamp] (2)
- 3.3.4. [EnforceRange] (2)

#idl-short Referenced in:

- 2.13. Types
- 2.13.6. short (2) (3)
- 3.2.4.3. short (2) (3) (4)

#idl-unsigned-short Referenced in:

- 2.13. Types
- 2.13.7. unsigned short (2) (3)
- 2.13.16. DOMString
- 3.2.4.4. unsigned short (2) (3) (4)
- 4.3. DOMException (2) (3) (4) (5) (6) (7) (8) (9) (10) (11) (12) (13) (14) (15) (16) (17) (18) (19) (20) (21) (22) (23) (24) (25) (26)

#idl-long Referenced in:

- 2.5.7. Overloading (2) (3) (4) (5) (6)
- 2.5.7.1. Overloading vs. union types
- 2.13. Types
- 2.13.1. any
- 2.13.8. long (2) (3)
- 2.13.31. Annotated types
- 3.2.4.5. long (2) (3) (4)

#idl-unsigned-long Referenced in:

- 1. Introduction
- 2.5.5. Special operations
- 2.5.5.2. Indexed properties (2)
- 2.13. Types
- 2.13.1. any
- 2.13.9. unsigned long (2) (3)
- 3.2.4.6. unsigned long (2) (3) (4)
- Document conventions

#idl-long-long Referenced in:

- 2.13. Types
- 2.13.10. long long (2) (3)
- 3.2.4.7. long long (2) (3) (4) (5) (6)
- 3.2.4.9. Abstract operations

#idl-unsigned-long-long Referenced in:

- 2.13. Types
- 2.13.11. unsigned long long (2) (3)
- 3.2.4.8. unsigned long long (2) (3) (4) (5) (6)
- 4.4. DOMTimeStamp

#idl-float Referenced in:

- 2.5.1. Constants (2)
- 2.13. Types
- 2.13.12. float (2) (3) (4)
- 3.2.5. float (2) (3)

#idl-unrestricted-float Referenced in:

- 2.5.1. Constants (2) (3) (4)
- 2.13. Types
- 2.13.13. unrestricted float (2) (3)
- 3.2.6. unrestricted float (2) (3) (4) (5)

#idl-double Referenced in:

- 2.5.1. Constants (2)
- 2.5.7. Overloading (2) (3)
- 2.13. Types
- 2.13.12. float (2)
- 2.13.14. double (2) (3)
- 3.2.7. double (2) (3) (4)

#idl-unrestricted-double Referenced in:

- 2.5.1. Constants (2) (3) (4)
- 2.13. Types
- 2.13.15. unrestricted double (2) (3)
- 3.2.1. any
- 3.2.8. unrestricted double (2) (3) (4) (5) (6)

#idl-DOMString Referenced in:

- 2.5.3. Operations
- 2.5.5. Special operations (2)
- 2.5.5.1. Stringifiers (2)
- 2.5.5.3. Named properties (2)
- 2.5.7. Overloading (2) (3) (4) (5) (6) (7) (8)
- 2.5.7.1. Overloading vs. union types
- 2.8. Exceptions
- 2.9. Enumerations
- 2.13. Types
- 2.13.16. DOMString (2) (3) (4) (5) (6) (7) (8) (9) (10) (11)
- 2.13.17. ByteString
- 2.13.18. USVString (2)
- 2.13.24. Enumeration types (2)
- 2.13.26. Nullable types — T?
- 2.13.28. Record types — record<K, V>
- 3.2.1. any
- 3.2.9. DOMString (2) (3) (4) (5)
- 3.2.11. USVString
- 3.3.21. [TreatNullAs] (2)
- 4.3. DOMException (2) (3) (4)

#dfn-obtain-unicode Referenced in:

- 3.2.11. USVString

#idl-ByteString Referenced in:

- 2.5.3. Operations
- 2.13. Types
- 2.13.17. ByteString (2) (3) (4) (5) (6)
- 2.13.28. Record types — record<K, V>
- 3.2.10. ByteString (2) (3) (4) (5)

#idl-USVString Referenced in:

- 2.5.3. Operations
- 2.5.5.1. Stringifiers
- 2.5.7. Overloading
- 2.13. Types
- 2.13.18. USVString (2) (3) (4) (5)
- 2.13.28. Record types — record<K, V>
- 3.2.11. USVString (2) (3) (4)

#idl-object Referenced in:

- 2.5.3.1. toJSON
- 2.13. Types
- 2.13.19. object (2) (3)
- 2.13.20. symbol
- 3.2.1. any (2) (3) (4)
- 3.2.12. object (2) (3) (4) (5)
- 3.2.23. Union types (2) (3) (4) (5) (6) (7)
- 3.3.18. [SameObject]
- 3.5. Overload resolution algorithm (2) (3) (4) (5) (6)
- 3.6.7.1.1. Default toJSON operation
- 8. Privacy and Security Considerations

#idl-symbol Referenced in:

- 2.13.20. symbol (2) (3)
- 3.2.1. any
- 3.2.13. symbol (2) (3) (4) (5)

#idl-interface Referenced in:

- 2.5.3.1. toJSON
- 2.5.7. Overloading
- 2.5.7.1. Overloading vs. union types
- 2.8. Exceptions
- 2.13. Types
- 3.2.14. Interface types (2) (3) (4) (5)
- 3.2.23. Union types
- 3.3.13. [NewObject]
- 3.3.16. [PutForwards] (2)
- 3.3.18. [SameObject]
- 3.5. Overload resolution algorithm
- 3.6.6. Attributes (2)
- 3.6.7. Operations
- 4.3. DOMException (2)

#idl-callback-interface Referenced in:

- 2.5.7. Overloading
- 2.13. Types
- 2.13.22. Callback interface types (2)
- 2.13.25. Callback function types
- 3.2.15. Callback interface types (2) (3) (4) (5)
- 3.2.23. Union types
- 3.5. Overload resolution algorithm
- 3.9. Callback interfaces

#dfn-callback-context Referenced in:

- 2.13.22. Callback interface types (2)
- 2.13.25. Callback function types (2)
- 3.2.15. Callback interface types
- 3.2.18. Callback function types
- 3.9. Callback interfaces
- 3.10. Invoking callback functions (2)

#idl-dictionary Referenced in:

- 2.5.2. Attributes
- 2.5.3. Operations (2) (3) (4) (5)
- 2.5.3.1. toJSON
- 2.5.7. Overloading (2) (3)
- 2.7. Dictionaries
- 2.13.30. Union types
- 3.2.16. Dictionary types (2) (3)
- 3.2.23. Union types (2)
- 3.5. Overload resolution algorithm (2) (3)

#idl-enumeration Referenced in:

- 2.13. Types
- 3.2.17. Enumeration types

#idl-callback-function Referenced in:

- 3.2.18. Callback function types (2) (3) (4) (5)
- 3.10. Invoking callback functions (2)

#dfn-nullable-type Referenced in:

- 2.5.1. Constants (2)
- 2.5.2. Attributes
- 2.5.3. Operations (2) (3)
- 2.5.3.1. toJSON
- 2.5.7. Overloading (2)
- 2.7. Dictionaries (2)
- 2.13.16. DOMString
- 2.13.19. object
- 2.13.21. Interface types
- 2.13.22. Callback interface types
- 2.13.26. Nullable types — T?
- 2.13.30. Union types (2) (3)
- 3.2.18. Callback function types
- 3.2.19. Nullable types — T? (2) (3) (4) (5) (6) (7) (8)
- 3.3.20. [TreatNonObjectAsNull]
- 3.5. Overload resolution algorithm (2) (3) (4) (5) (6) (7) (8) (9) (10) (11) (12) (13) (14) (15) (16) (17) (18) (19) (20) (21) (22) (23) (24) (25)

#dfn-inner-type Referenced in:

- 2.5.1. Constants
- 2.5.3. Operations (2)
- 2.5.3.1. toJSON
- 2.5.7. Overloading
- 2.7. Dictionaries (2)
- 2.13.26. Nullable types — T? (2) (3)
- 2.13.30. Union types (2)
- 3.2.19. Nullable types — T? (2) (3) (4)

#idl-sequence Referenced in:

- 3.2.22.2. Examples (2)

#sequence-type Referenced in:

- 2.5.2. Attributes
- 2.5.3. Operations (2) (3)
- 2.5.3.1. toJSON
- 2.5.7. Overloading
- 2.7. Dictionaries
- 2.11. Typedefs
- 2.13.16. DOMString
- 2.13.17. ByteString
- 2.13.27. Sequence types — sequence<T>
- 2.13.33. Frozen array types — FrozenArray<T>
- 3.2.20. Sequences — sequence<T> (2) (3)
- 3.2.20.1. Creating a sequence from an iterable (2)
- 3.2.22.1. Creating and manipulating Promises
- 3.2.23. Union types
- 3.2.25. Frozen arrays — FrozenArray<T>
- 3.2.25.1. Creating a frozen array from an iterable
- 3.5. Overload resolution algorithm (2) (3)

#idl-record Referenced in:

- 2.5.3.1. toJSON
- 2.7. Dictionaries
- 3.2.21. Records — record<K, V> (2) (3) (4) (5) (6) (7) (8)

#record-type Referenced in:

- 2.5.2. Attributes
- 2.5.7. Overloading
- 3.2.23. Union types
- 3.5. Overload resolution algorithm

#idl-promise Referenced in:

- 2.5.9. Asynchronously iterable declarations (2)
- 3.2.22. Promise types — Promise<T>
- 3.2.22.1. Creating and manipulating Promises (2) (3) (4) (5) (6) (7) (8) (9) (10) (11) (12) (13) (14)
- 3.2.22.2. Examples
- 3.6.9.6. Default asynchronous iterator objects

#dfn-promise-type Referenced in:

- 2.5.2. Attributes
- 2.5.7. Overloading
- 2.13.2. void
- 2.13.26. Nullable types — T?
- 3.2.22. Promise types — Promise<T> (2) (3)
- 3.3.13. [NewObject]
- 3.6.6. Attributes (2)
- 3.6.7. Operations
- 3.9. Callback interfaces
- 3.10. Invoking callback functions (2)

#dfn-union-type Referenced in:

- 2.5.2. Attributes
- 2.5.3. Operations (2) (3) (4)
- 2.5.3.1. toJSON
- 2.5.7. Overloading (2) (3) (4)
- 2.5.7.1. Overloading vs. union types (2) (3) (4) (5) (6) (7) (8)
- 2.7. Dictionaries
- 2.13.1. any (2)
- 2.13.26. Nullable types — T?
- 2.13.30. Union types (2) (3) (4) (5) (6) (7) (8) (9) (10) (11) (12) (13)
- 2.13.31. Annotated types
- 3.2.23. Union types (2) (3) (4)
- 3.5. Overload resolution algorithm (2) (3) (4) (5) (6) (7) (8) (9) (10) (11) (12) (13)

#dfn-union-member-type Referenced in:

- 2.5.3.1. toJSON
- 2.5.7. Overloading
- 2.5.7.1. Overloading vs. union types
- 2.7. Dictionaries
- 2.13.30. Union types (2) (3) (4) (5) (6)
- 2.13.31. Annotated types
- 3.2.23. Union types

#dfn-flattened-union-member-types Referenced in:

- 2.5.2. Attributes
- 2.5.3. Operations (2) (3) (4)
- 2.5.7. Overloading
- 2.13.26. Nullable types — T?
- 2.13.30. Union types (2) (3) (4)
- 3.2.23. Union types
- 3.5. Overload resolution algorithm (2) (3) (4) (5) (6) (7) (8) (9) (10) (11) (12) (13)

#dfn-number-of-nullable-member-types Referenced in:

- 2.13.30. Union types (2) (3)

#dfn-includes-a-nullable-type Referenced in:

- 2.5.7. Overloading (2)
- 2.13.26. Nullable types — T?
- 3.2.23. Union types
- 3.5. Overload resolution algorithm

#annotated-types Referenced in:

- 2.5.3.1. toJSON
- 2.5.7. Overloading
- 2.13.30. Union types (2) (3)
- 2.13.31. Annotated types
- 2.14. Extended attributes
- 3.2. ECMAScript type mapping
- 3.2.24. Buffer source types
- 3.5. Overload resolution algorithm (2) (3) (4) (5) (6) (7) (8) (9) (10) (11) (12) (13) (14) (15) (16) (17) (18) (19) (20) (21) (22) (23) (24) (25) (26)

#annotated-types-inner-type Referenced in:

- 2.5.3.1. toJSON
- 2.5.7. Overloading
- 2.13.30. Union types (2)
- 2.13.31. Annotated types
- 3.2.24. Buffer source types
- 3.5. Overload resolution algorithm (2) (3) (4) (5) (6) (7) (8) (9) (10) (11) (12) (13)

#extended-attributes-applicable-to-types Referenced in:

- 2.13.31. Annotated types (2) (3) (4) (5)

#idl-type-extended-attribute-associated-with Referenced in:

- 2.13.31. Annotated types (2) (3) (4)
- 3.2.4.9. Abstract operations (2) (3)
- 3.2.9. DOMString
- 3.2.24. Buffer source types (2) (3) (4)
- 3.3.1. [AllowShared]
- 3.3.2. [Clamp] (2)
- 3.3.4. [EnforceRange] (2)
- 3.3.21. [TreatNullAs]

#idl-ArrayBuffer Referenced in:

- 2.13. Types
- 2.13.32. Buffer source types (2) (3) (4) (5) (6) (7) (8)
- 3.2.23. Union types (2)
- 3.2.24. Buffer source types (2) (3) (4)
- 3.5. Overload resolution algorithm
- 4.1. ArrayBufferView
- 4.2. BufferSource (2) (3)

#idl-DataView Referenced in:

- 2.13. Types
- 3.2.23. Union types (2)
- 3.2.24. Buffer source types (2)
- 3.5. Overload resolution algorithm
- 4.1. ArrayBufferView

#idl-Int8Array Referenced in:

- 2.13. Types
- 2.13.17. ByteString
- 3.2.24. Buffer source types
- 4.1. ArrayBufferView

#idl-Int16Array Referenced in:

- 2.13. Types
- 3.2.24. Buffer source types
- 4.1. ArrayBufferView

#idl-Int32Array Referenced in:

- 2.13. Types
- 3.2.24. Buffer source types
- 4.1. ArrayBufferView

#idl-Uint8Array Referenced in:

- 2.13. Types
- 2.13.17. ByteString
- 2.13.32. Buffer source types
- 3.2.24. Buffer source types
- 4.1. ArrayBufferView

#idl-Uint16Array Referenced in:

- 2.13. Types
- 3.2.24. Buffer source types
- 4.1. ArrayBufferView

#idl-Uint32Array Referenced in:

- 2.13. Types
- 3.2.24. Buffer source types
- 4.1. ArrayBufferView

#idl-Uint8ClampedArray Referenced in:

- 2.13. Types
- 3.2.24. Buffer source types
- 4.1. ArrayBufferView

#idl-Float32Array Referenced in:

- 2.13. Types
- 3.2.24. Buffer source types
- 4.1. ArrayBufferView

#idl-Float64Array Referenced in:

- 2.13. Types
- 3.2.24. Buffer source types
- 4.1. ArrayBufferView

#dfn-get-buffer-source-reference Referenced in:

- 2.13.32. Buffer source types
- 3.2.24. Buffer source types

#dfn-get-buffer-source-copy Referenced in:

- 2.13.32. Buffer source types
- 3.2.24. Buffer source types

#idl-frozen-array Referenced in:

- 2.13.33. Frozen array types — FrozenArray<T>
- 3.2.25. Frozen arrays — FrozenArray<T> (2) (3)
- 3.2.25.1. Creating a frozen array from an iterable

#dfn-frozen-array-type Referenced in:

- 2.5.3.1. toJSON
- 2.5.7. Overloading
- 2.7. Dictionaries
- 2.13.17. ByteString
- 3.2.23. Union types
- 3.5. Overload resolution algorithm (2) (3)

#dfn-extended-attribute Referenced in:

- 2. Interface definition language (2)
- 2.2. Interfaces (2) (3) (4) (5)
- 2.3. Interface mixins
- 2.4. Callback interfaces
- 2.5.2. Attributes (2) (3)
- 2.5.3. Operations (2)
- 2.5.3.1. toJSON
- 2.5.7. Overloading (2) (3) (4)
- 2.5.9. Asynchronously iterable declarations
- 2.5.10. Maplike declarations
- 2.5.11. Setlike declarations
- 2.6. Namespaces
- 2.7. Dictionaries
- 2.9. Enumerations
- 2.11. Typedefs
- 2.12. Objects implementing interfaces
- 2.13.31. Annotated types (2) (3) (4) (5) (6)
- 2.14. Extended attributes
- 3.2.4.9. Abstract operations (2)
- 3.2.24. Buffer source types (2) (3)
- 3.3. ECMAScript-specific extended attributes
- 3.3.1. [AllowShared]
- 3.3.2. [Clamp] (2)
- 3.3.3. [Default]
- 3.3.4. [EnforceRange] (2)
- 3.3.5. [Exposed] (2) (3) (4) (5) (6) (7) (8)
- 3.3.6. [Global] (2) (3) (4) (5) (6)
- 3.3.7. [LegacyNamespace] (2)
- 3.3.8. [LegacyUnenumerableNamedProperties] (2) (3)
- 3.3.9. [LegacyWindowAlias] (2) (3)
- 3.3.10. [LenientSetter] (2)
- 3.3.11. [LenientThis] (2)
- 3.3.12. [NamedConstructor] (2) (3) (4)
- 3.3.13. [NewObject]
- 3.3.14. [NoInterfaceObject] (2) (3) (4) (5)
- 3.3.15. [OverrideBuiltins] (2) (3) (4)
- 3.3.16. [PutForwards] (2)
- 3.3.17. [Replaceable]
- 3.3.18. [SameObject]
- 3.3.19. [SecureContext] (2) (3) (4) (5) (6) (7) (8) (9)
- 3.3.20. [TreatNonObjectAsNull] (2) (3) (4)
- 3.3.21. [TreatNullAs] (2)
- 3.3.22. [Unforgeable] (2) (3)
- 3.3.23. [Unscopable]
- 3.5. Overload resolution algorithm (2)
- 3.6. Interfaces
- 3.6.2. Named constructors
- 3.6.3. Interface prototype object (2) (3) (4) (5) (6) (7) (8) (9) (10)
- 3.6.4. Named properties object
- 3.6.4.1. [[GetOwnProperty]]
- 3.6.5. Constants
- 3.6.6. Attributes (2) (3) (4)
- 3.6.7. Operations (2)
- 3.6.7.1. Default operations
- 3.6.7.1.1. Default toJSON operation (2)
- 3.6.7.2. Stringifiers
- 3.6.8.1. @@iterator
- 3.6.8.2. @@asyncIterator
- 3.6.8.3. forEach
- 3.6.9.1. entries
- 3.6.9.2. keys
- 3.6.9.3. values
- 3.7. Platform objects implementing interfaces (2) (3) (4) (5)
- 3.7.1. [[SetPrototypeOf]]
- 3.8.3. [[DefineOwnProperty]] (2) (3)
- 3.8.4. [[Delete]]
- 3.8.7. Abstract operations (2) (3)
- 5. Extensibility
- IDL grammar (2)

#dfn-xattr-no-arguments Referenced in:

- 3.3.1. [AllowShared]
- 3.3.2. [Clamp]
- 3.3.3. [Default]
- 3.3.4. [EnforceRange]
- 3.3.8. [LegacyUnenumerableNamedProperties]
- 3.3.10. [LenientSetter]
- 3.3.11. [LenientThis]
- 3.3.13. [NewObject]
- 3.3.14. [NoInterfaceObject]
- 3.3.15. [OverrideBuiltins]
- 3.3.17. [Replaceable]
- 3.3.18. [SameObject]
- 3.3.19. [SecureContext]
- 3.3.22. [Unforgeable]
- 3.3.23. [Unscopable]

#dfn-xattr-argument-list Referenced in:

- 2.5.3. Operations

#dfn-xattr-named-argument-list Referenced in:

- 2.5.7. Overloading (2)
- 3.3.12. [NamedConstructor]

#dfn-xattr-identifier Referenced in:

- 3.3.5. [Exposed]
- 3.3.6. [Global]
- 3.3.7. [LegacyNamespace]
- 3.3.9. [LegacyWindowAlias]
- 3.3.12. [NamedConstructor]
- 3.3.16. [PutForwards]
- 3.3.21. [TreatNullAs]

#dfn-xattr-identifier-list Referenced in:

- 3.3.5. [Exposed]
- 3.3.6. [Global]
- 3.3.9. [LegacyWindowAlias]

#dfn-class-string Referenced in:

- 3. ECMAScript binding
- 3.6.3. Interface prototype object
- 3.6.4. Named properties object
- 3.6.9.4. Default iterator objects (2)
- 3.6.9.5. Iterator prototype object
- 3.6.9.6. Default asynchronous iterator objects (2)
- 3.6.9.7. Asynchronous iterator prototype object
- 3.7. Platform objects implementing interfaces

#ecmascript-throw Referenced in:

- 3.2.4.9. Abstract operations (2)
- 3.2.5. float (2)
- 3.2.7. double
- 3.2.10. ByteString
- 3.2.12. object
- 3.2.13. symbol
- 3.2.14. Interface types
- 3.2.15. Callback interface types
- 3.2.16. Dictionary types
- 3.2.17. Enumeration types
- 3.2.18. Callback function types
- 3.2.20. Sequences — sequence<T> (2)
- 3.2.21. Records — record<K, V>
- 3.2.23. Union types
- 3.2.24. Buffer source types (2) (3) (4) (5) (6)
- 3.5. Overload resolution algorithm (2)
- 3.6.1. Interface object (2)
- 3.6.2. Named constructors
- 3.6.6. Attributes (2) (3) (4)
- 3.6.7. Operations
- 3.6.7.2. Stringifiers
- 3.6.8.1. @@iterator (2)
- 3.6.8.2. @@asyncIterator
- 3.6.8.3. forEach (2) (3)
- 3.6.9.2. keys (2)
- 3.6.9.3. values (2)
- 3.6.9.5. Iterator prototype object
- 3.6.10. Maplike declarations (2)
- 3.6.10.1. size
- 3.6.10.4. get and has
- 3.6.10.6. delete
- 3.6.10.7. set
- 3.6.11. Setlike declarations (2)
- 3.6.11.1. size
- 3.6.11.4. has
- 3.6.11.5. add and delete
- 3.9.1. Legacy callback interface object

#dfn-initial-object Referenced in:

- 3.1. ECMAScript environment (2)
- 3.3.5. [Exposed]
- 3.7. Platform objects implementing interfaces

#dfn-associated-realm Referenced in:

- 3.9. Callback interfaces
- 3.10. Invoking callback functions (2)

#dfn-convert-ecmascript-to-idl-value Referenced in:

- 3.2.1. any
- 3.2.2. void
- 3.2.3. boolean
- 3.2.4.1. byte
- 3.2.4.2. octet
- 3.2.4.3. short
- 3.2.4.4. unsigned short
- 3.2.4.5. long
- 3.2.4.6. unsigned long
- 3.2.4.7. long long
- 3.2.4.8. unsigned long long
- 3.2.5. float
- 3.2.6. unrestricted float
- 3.2.7. double
- 3.2.8. unrestricted double
- 3.2.9. DOMString
- 3.2.10. ByteString
- 3.2.11. USVString (2)
- 3.2.12. object
- 3.2.13. symbol
- 3.2.14. Interface types
- 3.2.15. Callback interface types
- 3.2.16. Dictionary types (2)
- 3.2.17. Enumeration types
- 3.2.18. Callback function types
- 3.2.19. Nullable types — T? (2)
- 3.2.20. Sequences — sequence<T>
- 3.2.20.1. Creating a sequence from an iterable
- 3.2.21. Records — record<K, V> (2) (3)
- 3.2.22. Promise types — Promise<T>
- 3.2.22.1. Creating and manipulating Promises (2)
- 3.2.23. Union types (2) (3) (4) (5) (6) (7) (8) (9) (10) (11) (12) (13) (14)
- 3.2.24. Buffer source types (2) (3)
- 3.2.25. Frozen arrays — FrozenArray<T> (2)
- 3.5. Overload resolution algorithm (2)
- 3.6.6. Attributes
- 3.6.10.4. get and has
- 3.6.10.6. delete
- 3.6.10.7. set (2)
- 3.6.11.4. has
- 3.6.11.5. add and delete
- 3.8.7. Abstract operations (2)
- 3.9. Callback interfaces (2)
- 3.10. Invoking callback functions (2) (3) (4)

#dfn-convert-idl-to-ecmascript-value Referenced in:

- 3.2.1. any
- 3.2.2. void
- 3.2.3. boolean
- 3.2.4.1. byte
- 3.2.4.2. octet
- 3.2.4.3. short
- 3.2.4.4. unsigned short
- 3.2.4.5. long
- 3.2.4.6. unsigned long
- 3.2.4.7. long long
- 3.2.4.8. unsigned long long
- 3.2.5. float
- 3.2.6. unrestricted float
- 3.2.7. double
- 3.2.8. unrestricted double
- 3.2.9. DOMString
- 3.2.10. ByteString
- 3.2.11. USVString
- 3.2.12. object
- 3.2.13. symbol
- 3.2.14. Interface types
- 3.2.15. Callback interface types
- 3.2.16. Dictionary types (2)
- 3.2.17. Enumeration types
- 3.2.18. Callback function types
- 3.2.19. Nullable types — T? (2)
- 3.2.20. Sequences — sequence<T> (2)
- 3.2.21. Records — record<K, V> (2) (3)
- 3.2.22. Promise types — Promise<T>
- 3.2.22.1. Creating and manipulating Promises (2) (3) (4)
- 3.2.23. Union types
- 3.2.24. Buffer source types
- 3.2.25. Frozen arrays — FrozenArray<T> (2)
- 3.6.1. Interface object
- 3.6.2. Named constructors
- 3.6.4.1. [[GetOwnProperty]]
- 3.6.5. Constants
- 3.6.6. Attributes
- 3.6.7. Operations
- 3.6.7.1.1. Default toJSON operation (2)
- 3.6.7.2. Stringifiers
- 3.6.9.5. Iterator prototype object (2) (3) (4)
- 3.6.10.4. get and has
- 3.6.10.6. delete
- 3.6.10.7. set (2)
- 3.6.11.4. has
- 3.6.11.5. add and delete
- 3.8.7. Abstract operations (2)
- 3.9. Callback interfaces

#abstract-opdef-integerpart Referenced in:

- 3.2.4.9. Abstract operations (2)

#abstract-opdef-converttoint Referenced in:

- 3.2.4.1. byte
- 3.2.4.2. octet
- 3.2.4.3. short
- 3.2.4.4. unsigned short
- 3.2.4.5. long
- 3.2.4.6. unsigned long
- 3.2.4.7. long long
- 3.2.4.8. unsigned long long

#create-sequence-from-iterable Referenced in:

- 3.2.20. Sequences — sequence<T>
- 3.2.23. Union types
- 3.2.25.1. Creating a frozen array from an iterable
- 3.5. Overload resolution algorithm

#a-new-promise Referenced in:

- 3.2.22.1. Creating and manipulating Promises
- 3.2.22.2. Examples (2) (3) (4) (5)

#a-promise-rejected-with Referenced in:

- 3.2.22.2. Examples (2) (3) (4) (5)

#resolve Referenced in:

- 3.2.22.1. Creating and manipulating Promises (2)
- 3.2.22.2. Examples (2) (3) (4) (5)

#reject Referenced in:

- 3.2.22.1. Creating and manipulating Promises
- 3.2.22.2. Examples (2) (3)

#dfn-perform-steps-once-promise-is-settled Referenced in:

- 3.2.22.1. Creating and manipulating Promises (2)
- 3.2.22.2. Examples

#wait-for-all Referenced in:

- 3.2.22.1. Creating and manipulating Promises

#waiting-for-all-promise Referenced in:

- 3.2.22.2. Examples (2)

#environment-ready-promise Referenced in:

- 3.2.22.2. Examples (2) (3) (4)

#dfn-detach Referenced in:

- 2.13.32. Buffer source types

#dfn-create-frozen-array Referenced in:

- 3.2.25. Frozen arrays — FrozenArray<T>
- 3.2.25.1. Creating a frozen array from an iterable

#create-frozen-array-from-iterable Referenced in:

- 3.2.23. Union types
- 3.5. Overload resolution algorithm

#AllowShared Referenced in:

- 2.13.31. Annotated types
- 3.2.24. Buffer source types (2) (3) (4)
- 3.3.1. [AllowShared] (2) (3) (4) (5)

#Clamp Referenced in:

- 2.13.31. Annotated types (2)
- 3.2.4.9. Abstract operations (2)
- 3.3.2. [Clamp] (2) (3) (4) (5) (6) (7)
- 3.3.4. [EnforceRange]

#Default Referenced in:

- 2.5.3. Operations
- 2.5.3.1. toJSON
- 3.3.3. [Default] (2) (3) (4)
- 3.6.7. Operations
- 3.6.7.1. Default operations
- 3.6.7.1.1. Default toJSON operation (2)

#EnforceRange Referenced in:

- 2.13.31. Annotated types
- 3.2.4.9. Abstract operations (2)
- 3.3.2. [Clamp]
- 3.3.4. [EnforceRange] (2) (3) (4) (5) (6) (7)

#Exposed Referenced in:

- 2. Interface definition language
- 2.2. Interfaces (2) (3)
- 2.3. Interface mixins
- 2.4. Callback interfaces
- 2.5.1. Constants
- 2.5.2. Attributes
- 2.5.3. Operations
- 2.5.8. Iterable declarations
- 2.5.9. Asynchronously iterable declarations
- 2.6. Namespaces (2)
- 3.3.5. [Exposed] (2) (3) (4) (5) (6) (7) (8) (9) (10) (11) (12) (13) (14) (15) (16)
- 3.3.6. [Global] (2)
- 4.3. DOMException

#own-exposure-set Referenced in:

- 3.3.5. [Exposed] (2) (3) (4) (5) (6) (7) (8) (9) (10) (11) (12)

#dfn-exposure-set Referenced in:

- 3.3.5. [Exposed] (2) (3) (4) (5) (6) (7) (8) (9) (10) (11) (12) (13)
- 3.3.9. [LegacyWindowAlias]

#dfn-exposed Referenced in:

- 2.3.1. Using mixins and partials
- 3.1. ECMAScript environment (2)
- 3.3.19. [SecureContext] (2)
- 3.6. Interfaces (2) (3)
- 3.6.3. Interface prototype object
- 3.6.5. Constants
- 3.6.6. Attributes
- 3.6.7. Operations (2)
- 3.6.7.1.1. Default toJSON operation
- 3.6.7.2. Stringifiers
- 3.7. Platform objects implementing interfaces (2) (3) (4)
- 3.9.1. Legacy callback interface object
- 3.11. Namespaces
- 3.11.1. Namespace object

#Global Referenced in:

- 2.2. Interfaces
- 2.12. Objects implementing interfaces
- 3.3.6. [Global] (2) (3) (4) (5) (6) (7) (8) (9)
- 3.3.12. [NamedConstructor]
- 3.3.15. [OverrideBuiltins]
- 3.6.3. Interface prototype object (2) (3) (4) (5)
- 3.6.4. Named properties object
- 3.6.5. Constants
- 3.6.6. Attributes
- 3.6.7. Operations
- 3.6.7.2. Stringifiers
- 3.6.8.1. @@iterator
- 3.6.8.2. @@asyncIterator
- 3.6.8.3. forEach
- 3.6.9.1. entries
- 3.6.9.2. keys
- 3.6.9.3. values
- 3.7. Platform objects implementing interfaces (2)
- 3.7.1. [[SetPrototypeOf]]
- 3.8.3. [[DefineOwnProperty]] (2)
- 3.8.4. [[Delete]]

#dfn-global-name Referenced in:

- 3.3.5. [Exposed]

#LegacyNamespace Referenced in:

- 2.2. Interfaces (2)
- 3.3.7. [LegacyNamespace] (2) (3) (4) (5)
- 3.3.9. [LegacyWindowAlias]
- 3.6. Interfaces
- 3.7. Platform objects implementing interfaces
- 3.11.1. Namespace object

#LegacyUnenumerableNamedProperties Referenced in:

- 3.3.8. [LegacyUnenumerableNamedProperties] (2) (3) (4) (5) (6)
- 3.6.4.1. [[GetOwnProperty]]
- 3.8.7. Abstract operations

#LegacyWindowAlias Referenced in:

- 2.2. Interfaces
- 3.3.9. [LegacyWindowAlias] (2) (3) (4) (5) (6) (7) (8) (9) (10) (11) (12)
- 3.3.12. [NamedConstructor]
- 3.6. Interfaces (2)
- 3.7. Platform objects implementing interfaces (2)

#legacywindowalias-identifier Referenced in:

- 3.3.9. [LegacyWindowAlias]
- 3.3.12. [NamedConstructor]
- 3.6. Interfaces (2) (3)
- 3.7. Platform objects implementing interfaces (2)

#LenientSetter Referenced in:

- 2.5.2. Attributes (2)
- 3.3.10. [LenientSetter] (2) (3) (4) (5) (6) (7) (8) (9)
- 3.3.16. [PutForwards]
- 3.3.17. [Replaceable]
- 3.6.6. Attributes (2)

#LenientThis Referenced in:

- 2.5.2. Attributes
- 3.3.11. [LenientThis] (2) (3) (4) (5) (6) (7)
- 3.6.6. Attributes (2) (3) (4)
- 3.6.7. Operations

#NamedConstructor Referenced in:

- 2.2. Interfaces
- 2.5.3. Operations
- 2.5.7. Overloading (2) (3) (4)
- 3.3.9. [LegacyWindowAlias]
- 3.3.12. [NamedConstructor] (2) (3) (4) (5) (6) (7) (8) (9) (10)
- 3.3.14. [NoInterfaceObject]
- 3.6. Interfaces (2)
- 3.6.2. Named constructors (2)
- 3.7. Platform objects implementing interfaces (2)
- IDL grammar

#namedconstructor-identifier Referenced in:

- 3.3.9. [LegacyWindowAlias]
- 3.3.12. [NamedConstructor]
- 3.6. Interfaces
- 3.6.2. Named constructors (2)
- 3.7. Platform objects implementing interfaces (2)

#NewObject Referenced in:

- 2.5.3. Operations
- 3.3.13. [NewObject] (2) (3)

#NoInterfaceObject Referenced in:

- 2.2. Interfaces (2)
- 3.3.7. [LegacyNamespace]
- 3.3.9. [LegacyWindowAlias]
- 3.3.14. [NoInterfaceObject] (2) (3) (4) (5) (6) (7) (8) (9) (10) (11)
- 3.6. Interfaces
- 3.6.3. Interface prototype object (2) (3)
- 3.7. Platform objects implementing interfaces

#OverrideBuiltins Referenced in:

- 2.2. Interfaces (2)
- 3.3.6. [Global] (2)
- 3.3.15. [OverrideBuiltins] (2) (3) (4) (5) (6)
- 3.8.3. [[DefineOwnProperty]]
- 3.8.7. Abstract operations (2) (3) (4)

#PutForwards Referenced in:

- 2.5.2. Attributes (2)
- 3.3.10. [LenientSetter]
- 3.3.16. [PutForwards] (2) (3) (4) (5) (6) (7) (8) (9) (10) (11)
- 3.3.17. [Replaceable]
- 3.6.6. Attributes (2) (3)

#Replaceable Referenced in:

- 2.5.2. Attributes (2)
- 3.3.10. [LenientSetter]
- 3.3.16. [PutForwards]
- 3.3.17. [Replaceable] (2) (3) (4) (5) (6) (7)
- 3.6.6. Attributes (2)

#SameObject Referenced in:

- 2.5.2. Attributes (2)
- 3.3.18. [SameObject] (2) (3)

#SecureContext Referenced in:

- 2.2. Interfaces (2)
- 2.3. Interface mixins
- 2.5.1. Constants
- 2.5.2. Attributes
- 2.5.3. Operations
- 2.5.8. Iterable declarations
- 2.5.9. Asynchronously iterable declarations
- 2.6. Namespaces
- 3.3.19. [SecureContext] (2) (3) (4) (5) (6) (7) (8) (9) (10) (11) (12) (13) (14)

#available-in-both-secure-and-non-secure-contexts Referenced in:

- 3.3.5. [Exposed]

#dfn-available-only-in-secure-contexts Referenced in:

- 3.3.19. [SecureContext] (2)

#TreatNonObjectAsNull Referenced in:

- 2.10. Callback functions
- 3.2.18. Callback function types (2)
- 3.2.19. Nullable types — T?
- 3.3.20. [TreatNonObjectAsNull] (2) (3) (4) (5)
- 3.10. Invoking callback functions

#TreatNullAs Referenced in:

- 2.13.31. Annotated types
- 3.2.9. DOMString
- 3.3.21. [TreatNullAs] (2) (3) (4) (5) (6)

#Unforgeable Referenced in:

- 2.5.2. Attributes
- 2.5.3. Operations
- 3.3.22. [Unforgeable] (2) (3) (4) (5) (6) (7)

#dfn-unforgeable-on-an-interface Referenced in:

- 3.3.22. [Unforgeable]
- 3.6.6. Attributes (2) (3) (4)
- 3.6.7. Operations (2) (3) (4)
- 3.6.7.2. Stringifiers (2)
- 3.8. Legacy platform objects

#Unscopable Referenced in:

- 3.3.23. [Unscopable] (2) (3) (4) (5)
- 3.6.3. Interface prototype object (2)

#dfn-perform-a-security-check Referenced in:

- 3.6.6. Attributes (2)
- 3.6.7. Operations
- 3.6.7.2. Stringifiers
- 3.6.8.1. @@iterator (2)
- 3.6.8.2. @@asyncIterator
- 3.6.8.3. forEach
- 3.6.9.2. keys (2)
- 3.6.9.3. values (2)
- 3.6.9.5. Iterator prototype object
- 3.6.9.7. Asynchronous iterator prototype object (2)
- 3.6.10. Maplike declarations
- 3.6.10.1. size
- 3.6.10.4. get and has
- 3.6.10.6. delete
- 3.6.10.7. set
- 3.6.11. Setlike declarations
- 3.6.11.1. size
- 3.6.11.4. has
- 3.6.11.5. add and delete

#dfn-overload-resolution-algorithm Referenced in:

- 2.5.7.1. Overloading vs. union types (2) (3)
- 3.6.1. Interface object
- 3.6.2. Named constructors
- 3.6.7. Operations

#dfn-interface-object Referenced in:

- 2.5.1. Constants
- 2.5.6. Static attributes and operations
- 3.1. ECMAScript environment
- 3.3.7. [LegacyNamespace]
- 3.3.9. [LegacyWindowAlias] (2) (3)
- 3.3.12. [NamedConstructor]
- 3.3.14. [NoInterfaceObject]
- 3.6. Interfaces
- 3.6.1. Interface object (2) (3) (4) (5) (6) (7) (8)
- 3.6.3. Interface prototype object (2)
- 3.6.5. Constants
- 3.6.6. Attributes
- 3.6.7. Operations
- 3.7. Platform objects implementing interfaces
- 3.12.3. Creating and throwing exceptions

#dfn-named-constructor Referenced in:

- 2.5.7. Overloading
- 3.1. ECMAScript environment
- 3.6.2. Named constructors (2)

#overridden-constructor-steps Referenced in:

- 3.6.1. Interface object (2)

#create-an-interface-object Referenced in:

- 3.7. Platform objects implementing interfaces
- 3.11.1. Namespace object

#create-a-named-constructor Referenced in:

- 3.7. Platform objects implementing interfaces

#dfn-interface-prototype-object Referenced in:

- 2.3. Interface mixins
- 2.5.8. Iterable declarations (2)
- 2.5.9. Asynchronously iterable declarations (2)
- 3.1. ECMAScript environment
- 3.3.6. [Global]
- 3.3.17. [Replaceable]
- 3.3.23. [Unscopable]
- 3.6.1. Interface object
- 3.6.2. Named constructors
- 3.6.3. Interface prototype object (2) (3) (4) (5)
- 3.6.4. Named properties object
- 3.6.5. Constants
- 3.6.6. Attributes
- 3.6.7. Operations
- 3.6.7.2. Stringifiers
- 3.6.8.1. @@iterator
- 3.6.8.2. @@asyncIterator
- 3.6.8.3. forEach
- 3.6.9.1. entries
- 3.6.9.2. keys
- 3.6.9.3. values
- 3.6.10. Maplike declarations
- 3.6.10.1. size
- 3.6.10.2. entries
- 3.6.10.3. keys and values
- 3.6.10.4. get and has
- 3.6.10.5. clear
- 3.6.10.6. delete
- 3.6.10.7. set
- 3.6.11. Setlike declarations
- 3.6.11.1. size
- 3.6.11.2. values
- 3.6.11.3. entries and keys
- 3.6.11.4. has
- 3.6.11.5. add and delete
- 3.6.11.6. clear
- 3.7. Platform objects implementing interfaces (2) (3)
- 3.12.1. DOMException custom bindings

#create-an-interface-prototype-object Referenced in:

- 3.6.1. Interface object
- 3.12.1. DOMException custom bindings

#dfn-named-properties-object Referenced in:

- 3.1. ECMAScript environment
- 3.3.6. [Global] (2)
- 3.6.4. Named properties object (2)
- 3.6.4.1. [[GetOwnProperty]] (2)
- 3.6.4.2. [[DefineOwnProperty]]
- 3.6.4.3. [[Delete]]
- 3.6.4.4. [[SetPrototypeOf]]
- 3.6.4.5. [[PreventExtensions]] (2)
- 3.8.7. Abstract operations

#create-a-named-properties-object Referenced in:

- 3.6.3. Interface prototype object

#define-the-constants Referenced in:

- 3.6.1. Interface object
- 3.6.3. Interface prototype object
- 3.9.1. Legacy callback interface object

#define-the-regular-attributes Referenced in:

- 3.6.3. Interface prototype object
- 3.7. Platform objects implementing interfaces
- 3.11.1. Namespace object

#define-the-static-attributes Referenced in:

- 3.6.1. Interface object

#define-the-unforgeable-regular-attributes Referenced in:

- 3.6.1. Interface object

#define-the-attributes Referenced in:

- 3.6.6. Attributes (2) (3)

#dfn-attribute-getter Referenced in:

- 3.1. ECMAScript environment
- 3.6.1. Interface object
- 3.6.6. Attributes

#dfn-attribute-setter Referenced in:

- 3.1. ECMAScript environment
- 3.6.1. Interface object
- 3.6.6. Attributes (2) (3)

#define-the-regular-operations Referenced in:

- 3.6.3. Interface prototype object
- 3.7. Platform objects implementing interfaces
- 3.11.1. Namespace object

#define-the-static-operations Referenced in:

- 3.6.1. Interface object

#define-the-unforgeable-regular-operations Referenced in:

- 3.6.1. Interface object

#define-the-operations Referenced in:

- 3.6.7. Operations (2) (3)

#dfn-create-operation-function Referenced in:

- 3.6.1. Interface object
- 3.6.7. Operations
- 3.7. Platform objects implementing interfaces

#corresponding-default-operation Referenced in:

- 3.3.3. [Default] (2)
- 3.6.7. Operations
- 3.6.7.1.1. Default toJSON operation

#default-tojson-operation Referenced in:

- 2.5.3.1. toJSON
- 3.6.7.1.1. Default toJSON operation (2)

#collect-attribute-values-of-an-inheritance-stack Referenced in:

- 3.6.7.1.1. Default toJSON operation (2)

#collect-attribute-values Referenced in:

- 3.6.7.1.1. Default toJSON operation

#create-an-inheritance-stack Referenced in:

- 3.6.7.1.1. Default toJSON operation

#dfn-default-iterator-object Referenced in:

- 3.6.8.1. @@iterator
- 3.6.9.2. keys
- 3.6.9.3. values
- 3.6.9.4. Default iterator objects (2) (3) (4)
- 3.6.9.5. Iterator prototype object (2)

#dfn-iterator-prototype-object Referenced in:

- 3.1. ECMAScript environment
- 3.6.9.4. Default iterator objects (2)
- 3.6.9.5. Iterator prototype object (2) (3) (4)

#iterator-result Referenced in:

- 3.6.9.5. Iterator prototype object
- 3.6.9.7. Asynchronous iterator prototype object

#dfn-default-asynchronous-iterator-object Referenced in:

- 3.6.8.2. @@asyncIterator
- 3.6.9.2. keys
- 3.6.9.3. values
- 3.6.9.6. Default asynchronous iterator objects (2) (3)
- 3.6.9.7. Asynchronous iterator prototype object (2) (3)

#default-asynchronous-iterator-object-target Referenced in:

- 3.6.8.2. @@asyncIterator
- 3.6.9.2. keys
- 3.6.9.3. values
- 3.6.9.7. Asynchronous iterator prototype object (2)

#default-asynchronous-iterator-object-kind Referenced in:

- 3.6.8.2. @@asyncIterator
- 3.6.9.2. keys
- 3.6.9.3. values
- 3.6.9.7. Asynchronous iterator prototype object

#default-asynchronous-iterator-object-ongoing-promise Referenced in:

- 3.6.9.7. Asynchronous iterator prototype object (2) (3) (4) (5) (6)

#default-asynchronous-iterator-object-is-finished Referenced in:

- 3.6.8.2. @@asyncIterator
- 3.6.9.2. keys
- 3.6.9.3. values
- 3.6.9.7. Asynchronous iterator prototype object (2) (3) (4)

#dfn-asynchronous-iterator-prototype-object Referenced in:

- 3.6.9.6. Default asynchronous iterator objects (2)
- 3.6.9.7. Asynchronous iterator prototype object (2) (3) (4) (5) (6)

#dfn-forwards-to-the-internal-map-object Referenced in:

- 3.6.10.3. keys and values
- 3.6.10.5. clear

#dfn-map-size-getter Referenced in:

- 3.1. ECMAScript environment
- 3.6.10.1. size

#dfn-forwards-to-the-internal-set-object Referenced in:

- 3.6.11.3. entries and keys
- 3.6.11.6. clear

#dfn-set-size-getter Referenced in:

- 3.6.11.1. size

#is-a-platform-object Referenced in:

- 3.2.23. Union types
- 3.5. Overload resolution algorithm
- 3.6.6. Attributes (2)
- 3.6.7. Operations
- 3.6.7.2. Stringifiers
- 3.6.8.1. @@iterator (2)
- 3.6.8.2. @@asyncIterator
- 3.6.8.3. forEach
- 3.6.9.2. keys (2)
- 3.6.9.3. values (2)
- 3.6.9.5. Iterator prototype object
- 3.6.9.7. Asynchronous iterator prototype object (2)
- 3.6.10. Maplike declarations
- 3.6.10.1. size
- 3.6.10.4. get and has
- 3.6.10.6. delete
- 3.6.10.7. set
- 3.6.11. Setlike declarations
- 3.6.11.1. size
- 3.6.11.4. has
- 3.6.11.5. add and delete
- 3.7. Platform objects implementing interfaces

#implements Referenced in:

- 2.5.4. Constructor operations (2)
- 2.5.9. Asynchronously iterable declarations
- 3.2.14. Interface types
- 3.2.23. Union types
- 3.3.6. [Global]
- 3.3.11. [LenientThis]
- 3.3.12. [NamedConstructor]
- 3.3.23. [Unscopable]
- 3.5. Overload resolution algorithm
- 3.6.1. Interface object (2)
- 3.6.2. Named constructors
- 3.6.4.1. [[GetOwnProperty]] (2)
- 3.6.5. Constants
- 3.6.6. Attributes (2) (3)
- 3.6.7. Operations (2)
- 3.6.7.2. Stringifiers (2)
- 3.6.8.1. @@iterator (2) (3)
- 3.6.8.2. @@asyncIterator (2)
- 3.6.8.3. forEach (2)
- 3.6.9.1. entries
- 3.6.9.2. keys (2) (3)
- 3.6.9.3. values (2) (3)
- 3.6.10. Maplike declarations (2)
- 3.6.10.1. size
- 3.6.10.4. get and has
- 3.6.10.6. delete
- 3.6.10.7. set
- 3.6.11. Setlike declarations (2)
- 3.6.11.1. size
- 3.6.11.4. has
- 3.6.11.5. add and delete
- 3.7. Platform objects implementing interfaces (2) (3) (4)
- 3.8.2. [[Set]] (2)
- 3.8.3. [[DefineOwnProperty]] (2)
- 3.8.7. Abstract operations (2) (3) (4)

#new Referenced in:

- 3.2.22.2. Examples

#internally-create-a-new-object-implementing-the-interface Referenced in:

- 3.6.1. Interface object
- 3.6.2. Named constructors
- 3.7. Platform objects implementing interfaces

#define-the-global-property-references Referenced in:

- 3.7. Platform objects implementing interfaces

#dfn-primary-interface Referenced in:

- 3.7. Platform objects implementing interfaces (2)

#dfn-unforgeable-property-name Referenced in:

- 3.8.3. [[DefineOwnProperty]]

#legacy-platform-object-getownproperty Referenced in:

- 3.3.8. [LegacyUnenumerableNamedProperties]
- 3.7. Platform objects implementing interfaces
- 3.8. Legacy platform objects (2)

#is-an-array-index Referenced in:

- 3.8.2. [[Set]]
- 3.8.3. [[DefineOwnProperty]]
- 3.8.4. [[Delete]]
- 3.8.7. Abstract operations

#dfn-named-property-visibility Referenced in:

- 3.6.4.1. [[GetOwnProperty]]
- 3.8.4. [[Delete]]
- 3.8.6. [[OwnPropertyKeys]]
- 3.8.7. Abstract operations

#invoke-indexed-setter Referenced in:

- 3.8.2. [[Set]]
- 3.8.3. [[DefineOwnProperty]]

#invoke-named-setter Referenced in:

- 3.8.2. [[Set]]
- 3.8.3. [[DefineOwnProperty]]

#LegacyPlatformObjectGetOwnProperty Referenced in:

- 3.8.1. [[GetOwnProperty]]
- 3.8.2. [[Set]]

#web-idl-arguments-list Referenced in:

- 3.9. Callback interfaces (2)
- 3.10. Invoking callback functions (2)

#web-idl-arguments-list-converting Referenced in:

- 3.9. Callback interfaces
- 3.10. Invoking callback functions (2)

#dfn-callback-this-value Referenced in:

- 3.6.8.3. forEach
- 3.10. Invoking callback functions

#dfn-legacy-callback-interface-object Referenced in:

- 3.1. ECMAScript environment
- 3.6.5. Constants
- 3.9.1. Legacy callback interface object (2) (3) (4)

#create-a-legacy-callback-interface-object Referenced in:

- 3.7. Platform objects implementing interfaces

#invoke-a-callback-function Referenced in:

- 3.6.8.3. forEach

#create-a-namespace-object Referenced in:

- 3.7. Platform objects implementing interfaces

#es-exception-objects Referenced in:

- 3.8.6. [[OwnPropertyKeys]]
- 3.12.3. Creating and throwing exceptions

#an-exception-was-thrown Referenced in:

- 3.6.6. Attributes
- 3.6.7. Operations
- Document conventions

#synthetic-module-record Referenced in:

- 3.13. Synthetic module records (2) (3)
- 3.13.1. CreateSyntheticModule (2)
- 3.13.3. Concrete Methods
- 3.13.3.1. GetExportedNames (2)
- 3.13.3.2. ResolveExport (2)
- 3.13.3.3. Link (2)
- 3.13.3.4. Evaluate (2)

#abstract-opdef-createsyntheticmodule Referenced in:

- 3.13. Synthetic module records (2)

#abstract-opdef-setsyntheticmoduleexport Referenced in:

- 3.13. Synthetic module records (2)

#abstract-opdef-synthetic-module-record-link Referenced in:

- 3.13.1. CreateSyntheticModule (2)

#ArrayBufferView Referenced in:

- 4.1. ArrayBufferView (2)
- 4.2. BufferSource

#BufferSource Referenced in:

- 2.13.32. Buffer source types
- 4.2. BufferSource (2)

#idl-DOMException Referenced in:

- 2.8. Exceptions (2) (3) (4) (5) (6) (7) (8) (9) (10) (11)
- 2.8.1. Error names (2) (3) (4) (5) (6) (7) (8)
- 3.2.22.2. Examples (2) (3) (4)
- 3.6.3. Interface prototype object
- 3.12.1. DOMException custom bindings (2) (3)
- 3.12.2. Exception objects (2)
- 3.12.3. Creating and throwing exceptions (2) (3) (4) (5) (6) (7)
- 4.3. DOMException (2) (3) (4) (5) (6) (7)

#domexception-name Referenced in:

- 4.3. DOMException (2) (3) (4) (5)

#domexception-message Referenced in:

- 4.3. DOMException (2) (3) (4)

#dom-domexception-domexception Referenced in:

- 4.3. DOMException

#dom-domexception-name Referenced in:

- 4.3. DOMException

#dom-domexception-message Referenced in:

- 4.3. DOMException

#dom-domexception-code Referenced in:

- 4.3. DOMException

#DOMTimeStamp Referenced in:

- 4.4. DOMTimeStamp (2)

#Function Referenced in:

- 4.5. Function (2)

#VoidFunction Referenced in:

- 4.6. VoidFunction (2)

#dfn-example-term Referenced in:

- Document conventions

#dfn-conforming-set-of-idl-fragments Referenced in:

- Conformance (2) (3)

#dfn-conforming-implementation Referenced in:

- 4. Common definitions
- 7. Referencing this specification
- Conformance

#dfn-conforming-ecmascript-implementation Referenced in:

- Conformance