-
Notifications
You must be signed in to change notification settings - Fork 67
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Define host environment interactions for modules #225
Comments
Here's a very rough outline of how I could picture Realms working for HTML:
|
Note, I don't consider passing up a base URL and import maps to be strong requirements; we could say that module specifiers always have to be absolute URLs in Realms. However, we should have the host hook in place to set up the Realm, which HTML can use to initialize an empty module map and set the base URL to null. |
No, we can’t say that, because module specifiers are not URLs in the language - only in specific hosts. |
@ljharb This is clear. What I'm suggesting is that we could pass a string up to the host, which it could interpret how it wants--I think many hosts have a concept of a "base directory" that modules are resolved relative to, so it will be useful in a broadly similar way. Just like module specifiers themselves are not specified in their interpretation, this "base" string would not be either. |
Part of addressing tc39#225 In HTML, this host hook would probably do something related to [setting up a window environment settings object](https://html.spec.whatwg.org/#set-up-a-window-environment-settings-object). I wouldn't propose that this would add properties to the global object in HTML. This PR makes a new host hook section, as another hook may be needed for new modules (in the context of tc39#224)
Based on the comment at https://github.com/tc39/proposal-realms/pull/223/files#r385853699 , my understanding is that the champion group's proposal for HTML is that the base URL of Realms created with the Realm API be the base URL of the surrounding document, and that there not be an API to set the base URL (maybe this would come from a future compartments/evaluator API). This seems like a fine design to me. |
Hi @littledan yes. This would be a job for host hooks, and the champions of both proposals agreed that all host hooks that would naturally apply to either Realm or Compartment be migrated into the SES / Compartment proposal, which is proceeding on that basis. |
* Layering: Host hook to initialize new Realms Part of addressing #225 In HTML, this host hook would probably do something related to [setting up a window environment settings object](https://html.spec.whatwg.org/#set-up-a-window-environment-settings-object). I wouldn't propose that this would add properties to the global object in HTML. This PR makes a new host hook section, as another hook may be needed for new modules (in the context of #224) * Note the purpose of the hook
@erights OK, I'm glad to hear that the champion group is comfortable for Realms to, initially in HTML, inherit these settings from their enclosing environment. This makes the integration much more straightforward, and makes me comfortable punting on things like |
@wycats and I discussed this, and he was a bit skeptical of each Realm having its own, entirely separate, module graph. He says it doesn't match their current usage of the Node |
See HTML proposal at whatwg/html#5339 , implementing the plan at #225 (comment) . To follow up on @wycats's concern, we may consider that module graphs with more sharing could be provided by the Evaluator/Compartment proposal's import trap. Short of that, it's hard for me to think of a concrete API that would allow more control over sharing. Personally, I like the current division of the Realm proposal vs the future Evaluator/Compartment proposal, but I can understand if some people are eager for the more complete featureset. |
I believe the EcmaScript part is well defined and @littledan is doing a good follow up in whatwg/html#5339 as mentioned and agreed in the plenaries. I believe it's best to sunset this discussion in order to focus the following discussion in the integration part only. Otherwise, we can reopen this to track status. |
This patch gives the TC39 JavaScript ShadowRealm proposal semantics in HTML. ShadowRealms are given an environment settings object; in general, ShadowRealms inherit their settings from the outer environment. When modules are used in ShadowRealms, module specifiers are interpreted with respect to the base URL of the surrounding environment, but when a module is imported within a ShadowRealm, it is a separate copy from what may be loaded in the surrounding environment or other ShadowRealms. This patch implements the plan described earlier at <tc39/proposal-shadowrealm#225 (comment)>. The ShadowRealm proposal is currently at Stage 3.
This patch gives the TC39 JavaScript ShadowRealm proposal semantics in HTML. ShadowRealms are given an environment settings object; in general, ShadowRealms inherit their settings from the outer environment. When modules are used in ShadowRealms, module specifiers are interpreted with respect to the base URL of the surrounding environment, but when a module is imported within a ShadowRealm, it is a separate copy from what may be loaded in the surrounding environment or other ShadowRealms. This patch implements the plan described earlier at <tc39/proposal-shadowrealm#225 (comment)>. The ShadowRealm proposal is currently at Stage 3.
This patch gives the TC39 JavaScript ShadowRealm proposal semantics in HTML. ShadowRealms are given an environment settings object; in general, ShadowRealms inherit their settings from the outer environment. When modules are used in ShadowRealms, module specifiers are interpreted with respect to the base URL of the surrounding environment, but when a module is imported within a ShadowRealm, it is a separate copy from what may be loaded in the surrounding environment or other ShadowRealms. This patch implements the plan described earlier at <tc39/proposal-shadowrealm#225 (comment)>. The ShadowRealm proposal is currently at Stage 3.
This patch gives the TC39 JavaScript ShadowRealm proposal semantics in HTML. ShadowRealms are given an environment settings object; in general, ShadowRealms inherit their settings from the outer environment. When modules are used in ShadowRealms, module specifiers are interpreted with respect to the base URL of the surrounding environment, but when a module is imported within a ShadowRealm, it is a separate copy from what may be loaded in the surrounding environment or other ShadowRealms. This patch implements the plan described earlier at <tc39/proposal-shadowrealm#225 (comment)>. The ShadowRealm proposal is currently at Stage 3.
This patch gives the TC39 JavaScript ShadowRealm proposal semantics in HTML. ShadowRealms are given an environment settings object; in general, ShadowRealms inherit their settings from the outer environment. When modules are used in ShadowRealms, module specifiers are interpreted with respect to the base URL of the surrounding environment, but when a module is imported within a ShadowRealm, it is a separate copy from what may be loaded in the surrounding environment or other ShadowRealms. This patch implements the plan described earlier at <tc39/proposal-shadowrealm#225 (comment)>. The ShadowRealm proposal is currently at Stage 3.
This patch gives the TC39 JavaScript ShadowRealm proposal semantics in HTML. ShadowRealms are given an environment settings object; in general, ShadowRealms inherit their settings from the outer environment. When modules are used in ShadowRealms, module specifiers are interpreted with respect to the base URL of the surrounding environment, but when a module is imported within a ShadowRealm, it is a separate copy from what may be loaded in the surrounding environment or other ShadowRealms. This patch implements the plan described earlier at <tc39/proposal-shadowrealm#225 (comment)>. The ShadowRealm proposal is currently at Stage 3.
This patch gives the TC39 JavaScript ShadowRealm proposal semantics in HTML. ShadowRealms are given an environment settings object; in general, ShadowRealms inherit their settings from the outer environment. When modules are used in ShadowRealms, module specifiers are interpreted with respect to the base URL of the surrounding environment, but when a module is imported within a ShadowRealm, it is a separate copy from what may be loaded in the surrounding environment or other ShadowRealms. This patch implements the plan described earlier at <tc39/proposal-shadowrealm#225 (comment)>. The ShadowRealm proposal is currently at Stage 3.
This patch gives the TC39 JavaScript ShadowRealm proposal semantics in HTML. ShadowRealms are given an environment settings object; in general, ShadowRealms inherit their settings from the outer environment. When modules are used in ShadowRealms, module specifiers are interpreted with respect to the base URL of the surrounding environment, but when a module is imported within a ShadowRealm, it is a separate copy from what may be loaded in the surrounding environment or other ShadowRealms. This patch implements the plan described earlier at <tc39/proposal-shadowrealm#225 (comment)>. The ShadowRealm proposal is currently at Stage 3.
This patch gives the TC39 JavaScript ShadowRealm proposal semantics in HTML. ShadowRealms are given an environment settings object; in general, ShadowRealms inherit their settings from the outer environment. When modules are used in ShadowRealms, module specifiers are interpreted with respect to the base URL of the surrounding environment, but when a module is imported within a ShadowRealm, it is a separate copy from what may be loaded in the surrounding environment or other ShadowRealms. This patch implements the plan described earlier at <tc39/proposal-shadowrealm#225 (comment)>. The ShadowRealm proposal is currently at Stage 3.
This patch gives the TC39 JavaScript ShadowRealm proposal semantics in HTML. ShadowRealms are given an environment settings object; in general, ShadowRealms inherit their settings from the outer environment. When modules are used in ShadowRealms, module specifiers are interpreted with respect to the base URL of the surrounding environment, but when a module is imported within a ShadowRealm, it is a separate copy from what may be loaded in the surrounding environment or other ShadowRealms. This patch implements the plan described earlier at <tc39/proposal-shadowrealm#225 (comment)>. The ShadowRealm proposal is currently at Stage 3.
This patch gives the TC39 JavaScript ShadowRealm proposal semantics in HTML. ShadowRealms are given an environment settings object; in general, ShadowRealms inherit their settings from the outer environment. When modules are used in ShadowRealms, module specifiers are interpreted with respect to the base URL of the surrounding environment, but when a module is imported within a ShadowRealm, it is a separate copy from what may be loaded in the surrounding environment or other ShadowRealms. This patch implements the plan described earlier at <tc39/proposal-shadowrealm#225 (comment)>. The ShadowRealm proposal is currently at Stage 3.
This patch gives the TC39 JavaScript ShadowRealm proposal semantics in HTML. ShadowRealms are given an environment settings object; in general, ShadowRealms inherit their settings from the outer environment. When modules are used in ShadowRealms, module specifiers are interpreted with respect to the base URL of the surrounding environment, but when a module is imported within a ShadowRealm, it is a separate copy from what may be loaded in the surrounding environment or other ShadowRealms. This patch implements the plan described earlier at <tc39/proposal-shadowrealm#225 (comment)>. The ShadowRealm proposal is currently at Stage 3.
This patch gives the TC39 JavaScript ShadowRealm proposal semantics in HTML. ShadowRealms are given an environment settings object; in general, ShadowRealms inherit their settings from the outer environment. When modules are used in ShadowRealms, module specifiers are interpreted with respect to the base URL of the surrounding environment, but when a module is imported within a ShadowRealm, it is a separate copy from what may be loaded in the surrounding environment or other ShadowRealms. This patch implements the plan described earlier at <tc39/proposal-shadowrealm#225 (comment)>. The ShadowRealm proposal is currently at Stage 3.
This patch gives the TC39 JavaScript ShadowRealm proposal semantics in HTML. ShadowRealms are given an environment settings object; in general, ShadowRealms inherit their settings from the outer environment. When modules are used in ShadowRealms, module specifiers are interpreted with respect to the base URL of the surrounding environment, but when a module is imported within a ShadowRealm, it is a separate copy from what may be loaded in the surrounding environment or other ShadowRealms. This patch implements the plan described earlier at <tc39/proposal-shadowrealm#225 (comment)>. The ShadowRealm proposal is currently at Stage 3.
This patch gives the TC39 JavaScript ShadowRealm proposal semantics in HTML. ShadowRealms are given an environment settings object; in general, ShadowRealms inherit their settings from the outer environment. When modules are used in ShadowRealms, module specifiers are interpreted with respect to the base URL of the surrounding environment, but when a module is imported within a ShadowRealm, it is a separate copy from what may be loaded in the surrounding environment or other ShadowRealms. This patch implements the plan described earlier at <tc39/proposal-shadowrealm#225 (comment)>. The ShadowRealm proposal is currently at Stage 3.
This patch gives the TC39 JavaScript ShadowRealm proposal semantics in HTML. ShadowRealms are given an environment settings object; in general, ShadowRealms inherit their settings from the outer environment. When modules are used in ShadowRealms, module specifiers are interpreted with respect to the base URL of the surrounding environment, but when a module is imported within a ShadowRealm, it is a separate copy from what may be loaded in the surrounding environment or other ShadowRealms. This patch implements the plan described earlier at <tc39/proposal-shadowrealm#225 (comment)>. The ShadowRealm proposal is currently at Stage 3.
This patch gives the TC39 JavaScript ShadowRealm proposal semantics in HTML. ShadowRealms are given an environment settings object; in general, ShadowRealms inherit their settings from the outer environment. When modules are used in ShadowRealms, module specifiers are interpreted with respect to the base URL of the surrounding environment, but when a module is imported within a ShadowRealm, it is a separate copy from what may be loaded in the surrounding environment or other ShadowRealms. This patch implements the plan described earlier at <tc39/proposal-shadowrealm#225 (comment)>. The ShadowRealm proposal is currently at Stage 3.
This patch gives the TC39 JavaScript ShadowRealm proposal semantics in HTML. ShadowRealms are given an environment settings object; in general, ShadowRealms inherit their settings from the outer environment. When modules are used in ShadowRealms, module specifiers are interpreted with respect to the base URL of the surrounding environment, but when a module is imported within a ShadowRealm, it is a separate copy from what may be loaded in the surrounding environment or other ShadowRealms. This patch implements the plan described earlier at <tc39/proposal-shadowrealm#225 (comment)>. The ShadowRealm proposal is currently at Stage 3.
This patch gives the TC39 JavaScript ShadowRealm proposal semantics in HTML. ShadowRealms are given an environment settings object; in general, ShadowRealms inherit their settings from the outer environment. When modules are used in ShadowRealms, module specifiers are interpreted with respect to the base URL of the surrounding environment, but when a module is imported within a ShadowRealm, it is a separate copy from what may be loaded in the surrounding environment or other ShadowRealms. This patch implements the plan described earlier at <tc39/proposal-shadowrealm#225 (comment)>. The ShadowRealm proposal is currently at Stage 3.
This patch gives the TC39 JavaScript ShadowRealm proposal semantics in HTML. ShadowRealms are given an environment settings object; in general, ShadowRealms inherit their settings from the outer environment. When modules are used in ShadowRealms, module specifiers are interpreted with respect to the base URL of the surrounding environment, but when a module is imported within a ShadowRealm, it is a separate copy from what may be loaded in the surrounding environment or other ShadowRealms. This patch implements the plan described earlier at <tc39/proposal-shadowrealm#225 (comment)>. The ShadowRealm proposal is currently at Stage 2, pending the landing of this PR.
This patch gives the TC39 JavaScript ShadowRealm proposal semantics in HTML. ShadowRealms are given an environment settings object; in general, ShadowRealms inherit their settings from the outer environment. When modules are used in ShadowRealms, module specifiers are interpreted with respect to the base URL of the surrounding environment, but when a module is imported within a ShadowRealm, it is a separate copy from what may be loaded in the surrounding environment or other ShadowRealms. This patch implements the plan described earlier at <tc39/proposal-shadowrealm#225 (comment)>. The ShadowRealm proposal is currently at Stage 2, pending the landing of this PR.
This patch gives the TC39 JavaScript ShadowRealm proposal semantics in HTML. ShadowRealms are given an environment settings object; in general, ShadowRealms inherit their settings from the outer environment. When modules are used in ShadowRealms, module specifiers are interpreted with respect to the base URL of the surrounding environment, but when a module is imported within a ShadowRealm, it is a separate copy from what may be loaded in the surrounding environment or other ShadowRealms. This patch implements the plan described earlier at <tc39/proposal-shadowrealm#225 (comment)>. The ShadowRealm proposal is currently at Stage 2. Once this PR has been approved, it should be able to advance to Stage 3.
This patch gives the TC39 JavaScript ShadowRealm proposal semantics in HTML. ShadowRealms are given an environment settings object; in general, ShadowRealms inherit their settings from the outer environment. When modules are used in ShadowRealms, module specifiers are interpreted with respect to the base URL of the surrounding environment, but when a module is imported within a ShadowRealm, it is a separate copy from what may be loaded in the surrounding environment or other ShadowRealms. This patch implements the plan described earlier at <tc39/proposal-shadowrealm#225 (comment)>. The ShadowRealm proposal is currently at Stage 2. Once this PR has been approved, it should be able to advance to Stage 3.
This patch gives the TC39 JavaScript ShadowRealm proposal semantics in HTML. ShadowRealms are given an environment settings object; in general, ShadowRealms inherit their settings from the outer environment. When modules are used in ShadowRealms, module specifiers are interpreted with respect to the base URL of the surrounding environment, but when a module is imported within a ShadowRealm, it is a separate copy from what may be loaded in the surrounding environment or other ShadowRealms. This patch implements the plan described earlier at <tc39/proposal-shadowrealm#225 (comment)>. The ShadowRealm proposal is currently at Stage 2. Once this PR has been approved, it should be able to advance to Stage 3.
This patch gives the TC39 JavaScript ShadowRealm proposal semantics in HTML. ShadowRealms are given an environment settings object; in general, ShadowRealms inherit their settings from the outer environment. When modules are used in ShadowRealms, module specifiers are interpreted with respect to the base URL of the surrounding environment, but when a module is imported within a ShadowRealm, it is a separate copy from what may be loaded in the surrounding environment or other ShadowRealms. This patch implements the plan described earlier at <tc39/proposal-shadowrealm#225 (comment)>. The ShadowRealm proposal is currently at Stage 2. Once this PR has been approved, it should be able to advance to Stage 3.
This patch gives the TC39 JavaScript ShadowRealm proposal semantics in HTML. ShadowRealms are given an environment settings object; in general, ShadowRealms inherit their settings from the outer environment. When modules are used in ShadowRealms, module specifiers are interpreted with respect to the base URL of the surrounding environment, but when a module is imported within a ShadowRealm, it is a separate copy from what may be loaded in the surrounding environment or other ShadowRealms. This patch implements the plan described earlier at <tc39/proposal-shadowrealm#225 (comment)>. The ShadowRealm proposal is currently at Stage 2. Once this PR has been approved, it should be able to advance to Stage 3.
This patch gives the TC39 JavaScript ShadowRealm proposal semantics in HTML. ShadowRealms are given an environment settings object; in general, ShadowRealms inherit their settings from the outer environment. When modules are used in ShadowRealms, module specifiers are interpreted with respect to the base URL of the surrounding environment, but when a module is imported within a ShadowRealm, it is a separate copy from what may be loaded in the surrounding environment or other ShadowRealms. This patch implements the plan described earlier at <tc39/proposal-shadowrealm#225 (comment)>. The ShadowRealm proposal is currently at Stage 2. Once this PR has been approved, it should be able to advance to Stage 3.
This patch gives the TC39 JavaScript ShadowRealm proposal semantics in HTML. ShadowRealms are given an environment settings object; in general, ShadowRealms inherit their settings from the outer environment. When modules are used in ShadowRealms, module specifiers are interpreted with respect to the base URL of the surrounding environment, but when a module is imported within a ShadowRealm, it is a separate copy from what may be loaded in the surrounding environment or other ShadowRealms. This patch implements the plan described earlier at <tc39/proposal-shadowrealm#225 (comment)>. The ShadowRealm proposal is currently at Stage 2. Once this PR has been approved, it should be able to advance to Stage 3.
This patch gives the TC39 JavaScript ShadowRealm proposal semantics in HTML. ShadowRealms are given an environment settings object; in general, ShadowRealms inherit their settings from the outer environment. When modules are used in ShadowRealms, module specifiers are interpreted with respect to the base URL of the surrounding environment, but when a module is imported within a ShadowRealm, it is a separate copy from what may be loaded in the surrounding environment or other ShadowRealms. This patch implements the plan described earlier at <tc39/proposal-shadowrealm#225 (comment)>. The ShadowRealm proposal is currently at Stage 2. Once this PR has been approved, it should be able to advance to Stage 3.
Whether or not #223 lands (I'm a fan!), Realms have the ability to import modules through
import()
. I think we should have a somewhat clear idea of what this means in some environments, which has some amount of buy-in from those environments, to get to Stage 3.Maybe this doesn't need host environment spec text to block Stage 3, but at least thought through and written down. There may be implications for host hooks needed. It'd be good to avoid repeating the experience with modules and Promises where the layering and full spec text took time to nail down after standardization.
I don't know much about many JS environments, so it'd be great to have some more help from the committee.
The text was updated successfully, but these errors were encountered: