Make creation of all initial objects/properties/methods/etc. imperative

[domenic]

We've been doing this piecemeal. For example, https://heycam.github.io/webidl/#namespace-object provides a procedure for creating namespace objects given a namespace and realm. We did the same for interface object: https://heycam.github.io/webidl/#interface-object , but did not do it for interface members (like we did for namespace members). This will be a great clarity improvement, consolidating various sprinkled prose which tells you what global properties exist and what their property descriptors are and so on.

Once this is done completely for all initial objects, we can replace

Each ECMAScript global environment must have its own unique set of each of the initial objects, created before control enters any ECMAScript execution context associated with the environment, but after the global object for that environment is created.

with a procedure that is given a realm and ... a set of all IDL definitions on the web platform? ... and loops over all exposed definitions and creates them on that realm's global object.

Then, I suppose, we can call that procedure from places like https://html.spec.whatwg.org/#creating-a-new-browsing-context as a customization for InitializeHostDefinedRealm(). Although that might be overkill, as the hand-wavey manner in which things currently work allows you to "automatically" get the right set of globals without having to add an explicit step when creating your global. (Thus making it easier to define new globals.) We can cross that bridge when we get there.

[tobie]

See also: https://www.w3.org/Bugs/Public/show_bug.cgi?id=27355

[annevk]

FWIW, I think we actually want to define when new globals are created as we can then also define when agents and agent clusters are created, and how those all relate. That is rather indirect at the moment (in part due to how hard it is to sort out navigation properly).

[domenic]

Class string (cf. #357) is a small thing that would be easy to make imperative. However, doing so in a non-confusing way is blocked on first making iterator prototype objects and async iterator prototype objects imperative, since for those two there's currently no algorithm to slot the "create a @@toStringTag property" step into.