Audit host hook points in HTML

[syg]

For the most part, HTML integration into ecma262 is done via host hooks. Host hooks are used very much like an embedder passing custom callbacks to an engine. However, some hook points are more ad-hoc, like realm creation.

We should discuss whether these ad-hoc patterns are acceptable editorially, or if we should introduce more formal hook points.

[michaelficarra]

If we mark host hook AOs as such, we can also lint for unused AOs.

[jmdyck]

However, some hook points are more ad-hoc, like realm creation.

There are a couple different things that are ad hoc about the realm creation hook:

(1) HTML invokes InitializeHostDefinedRealm (IHDR) with 'customizations', e.g.:

For the global object, create a new Window object.

IHDR then has ad hoc steps to 'access' these customizations, e.g.:

If the host requires use of an exotic object to serve as realm's global object, let global be such an object created in a host-defined manner.

We could make this less ad hoc by giving IHDR two parameters (e.g., global and thisValue), and have HTML pass its customizations as objects (or *undefined*, to get the default).

Or is there something important about not creating the objects in question until after the first 6 steps of IHDR?

---

(2) The spec doesn't invoke IHDR, so it isn't like a callback hook. Instead, the model is that the host invokes it directly. But the circumstances/constraints under which it can/may be invoked aren't spelled out.

If you're thinking that IHDR should be converted to a callback-style hook, I think that might be undoing some of PR #1597. (But maybe not.)

[michaelficarra]

We could make this less ad hoc by giving IHDR two parameters

This is exactly the kind of thing I wanted an audit to turn up, and this solution sounds like the right direction to me.

the circumstances/constraints under which it can/may be invoked aren't spelled out

Yes, this seems important to elaborate on.