HTML: The Living Standard

次のグローバルオブジェクトのペアは、それぞれ同じエージェントクラスター内にあるため、SharedArrayBufferインスタンスを使用して互いにメモリーを共有できる：

• Windowオブジェクトおよびそれが作成した専用ワーカー。

• （任意のタイプの）ワーカーおよびそれが作成した専用のワーカー。

• WindowオブジェクトAおよび、Aが作成したiframe要素のWindowオブジェクトで、Aと同一生成元ドメインである可能性があるもの。

• Windowオブジェクトおよび、それを開いた同一生成元ドメインのWindow オブジェクト。

• Windowオブジェクトおよび、それが作成したワークレット。

次のグローバルオブジェクトのペアは、同じエージェントクラスター内には存在しないため、メモリーを共有することはできない：

• Windowオブジェクトとそれが作成した共有ワーカー。

• （任意のタイプの）ワーカーおよび、それが作成した共有ワーカー。

• Windowオブジェクトおよび、作成したサービスワーカー。

• A Window object A and the Window object of an iframe element that A created that cannot be same origin-domain with A.

• オープナーまたは祖先の関係がない任意の2つのWindowオブジェクト。これは、2つのWindowオブジェクトが同一生成元であっても保持される。

The simplest use of import maps is to globally remap a bare module specifier:

{
  "imports": {
    "moment": "/node_modules/moment/src/moment.js"
  }
}

This enables statements like import moment from "moment"; to work, fetching and evaluating the JavaScript module at the /node_modules/moment/src/moment.js URL.

An import map can remap a class of module specifiers into a class of URLs by using trailing slashes, like so:

{
  "imports": {
    "moment/": "/node_modules/moment/src/"
  }
}

This enables statements like import localeData from "moment/locale/zh-cn.js"; to work, fetching and evaluating the JavaScript module at the /node_modules/moment/src/locale/zh-cn.js URL. Such trailing-slash mappings are often combined with bare-specifier mappings, e.g.

{
  "imports": {
    "moment": "/node_modules/moment/src/moment.js",
    "moment/": "/node_modules/moment/src/"
  }
}

so that both the "main module" specified by "moment" and the "submodules" specified by paths such as "moment/locale/zh-cn.js" are available.

Bare specifiers are not the only type of module specifiers which import maps can remap. "URL-like" specifiers, i.e., those that are either parseable as absolute URLs or start with "/", "./", or "../", can be remapped as well:

{
  "imports": {
    "https://cdn.example.com/vue/dist/vue.runtime.esm.js": "/node_modules/vue/dist/vue.runtime.esm.js",
    "/js/app.mjs": "/js/app-8e0d62a03.mjs",
    "../helpers/": "https://cdn.example/helpers/"
  }
}

Note how the URL to be remapped, as well as the URL being mapped to, can be specified either as absolute URLs, or as relative URLs starting with "/", "./", or "../". (They cannot be specified as relative URLs without those starting sigils, as those help distinguish from bare module specifiers.) Also note how the trailing slash mapping works in this context as well.

Such remappings operate on the post-canonicalization URL, and do not require a match between the literal strings supplied in the import map key and the imported module specifier. So for example, if this import map was included on https://example.com/app.html, then not only would import "/js/app.mjs" be remapped, but so would import "./js/app.mjs" and import "./foo/../js/app.mjs".

All previous examples have globally remapped module specifiers, by using the top-level "imports" key in the import map. The top-level "scopes" key can be used to provide localized remappings, which only apply when the referring module matches a specific URL prefix. たとえば：

{
  "scopes": {
    "/a/" : {
      "moment": "/node_modules/moment/src/moment.js"
    },
    "/b/" : {
      "moment": "https://cdn.example.com/moment/src/moment.js"
    }
  }
}

With this import map, the statement import "moment" will have different meanings depending on which referrer script contains the statement:

• Inside scripts located under /a/, this will import /node_modules/moment/src/moment.js.

• Inside scripts located under /b/, this will import https://cdn.example.com/moment/src/moment.js.

• Inside scripts located under /c/, this will fail to resolve and thus throw an exception.

A typical usage of scopes is to allow multiple versions of the "same" module to exist in a web application, with some parts of the module graph importing one version, and other parts importing another version.

Scopes can overlap each other, and overlap the global "imports" specifier map. At resolution time, scopes are consulted in order of most- to least-specific, where specificity is measured by sorting the scopes using the code unit less than operation. So, for example, "/scope2/scope3/" is treated as more specific than "/scope2/", which is treated as more specific than the top-level (unscoped) mappings.

The following import map illustrates this:

{
  "imports": {
    "a": "/a-1.mjs",
    "b": "/b-1.mjs",
    "c": "/c-1.mjs"
  },
  "scopes": {
    "/scope2/": {
      "a": "/a-2.mjs"
    },
    "/scope2/scope3/": {
      "b": "/b-3.mjs"
    }
  }
}

This results in the following resolutions (using relative URLs for brevity):

		Specifier
		"a"	"b"	"c"
Referrer	/scope1/r.mjs	/a-1.mjs	/b-1.mjs	/c-1.mjs
	/scope2/r.mjs	/a-2.mjs	/b-1.mjs	/c-1.mjs
	/scope2/scope3/r.mjs	/a-2.mjs	/b-3.mjs	/c-1.mjs

Import maps can also be used to provide modules with integrity metadata to be used in Subresource Integrity checks. [SRI]

The following import map illustrates this:

{
  "imports": {
    "a": "/a-1.mjs",
    "b": "/b-1.mjs",
    "c": "/c-1.mjs"
  },
  "integrity": {
    "/a-1.mjs": "sha384-Li9vy3DqF8tnTXuiaAJuML3ky+er10rcgNR/VqsVpcw+ThHmYcwiB1pbOxEbzJr7",
    "/d-1.mjs": "sha384-MBO5IDfYaE6c6Aao94oZrIOiC6CGiSN2n4QUbHNPhzk5Xhm0djZLQqTpL0HzTUxk"
  }
}

The above example provides integrity metadata to be enforced on the modules /a-1.mjs and /d-1.mjs, even if the latter is not defined as an import in the map.

Since module maps are keyed by (URL, module type), the following code will create three separate entries in the module map, since it results in three different (URL, module type) tuples (all with "javascript-or-wasm" type):

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

つまり、URLクエリーおよびフラグメントは、を変更して、モジュールマップに個別のエントリーを作成するために変化させることができ、それらは無視されない。よって、3つの別々のフェッチおよび3つの別々のモジュール評価が実行される。

対照的に、次のコードは、モジュールマップに単一のエントリーのみを作成する。これは、これらの入力にURLパーサーを適用した後、結果のURLレコードが等しくなるためである。

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

そのため、この2番目の例では、1つのフェッチと1つのモジュール評価のみが発生する。

この動作は、共有ワーカーが解析されたコンストラクターURLによって入力される方法と同じであることに注意する。

Since module type is also part of the module map key, the following code will create two separate entries in the module map (the type is "javascript-or-wasm" for the first, and "css" for the second):

<script type=module>
  import "https://example.com/module";
</script>
<script type=module>
  import "https://example.com/module" with { type: "css" };
</script>

これにより、2つの別々のフェッチと2つの別々のモジュール評価が実行される可能性がある。

実際には、まだ指定されていないメモリーキャッシュ（issue #6110を参照）のため、リソースはWebKitおよびBlinkベースのブラウザーで1回のみフェッチしてもよい。さらに、すべてのモジュールタイプが相互に排他的である限り、単一のモジュールスクリプトをフェッチする際のモジュールタイプチェックは、少なくとも1つのインポートで失敗するため、最大で1つのモジュール評価が行われる。

モジュールマップキーにタイプを含める目的は、間違ったタイプ属性を持つインポートが、同じ指定子で正しいタイプを持つ別のインポートの成功を妨げないようにすることにある。

JavaScriptモジュールスクリプトは、別のJavaScriptモジュールからインポートするときのデフォルトのインポートタイプである。つまり、 importステートメントにtypeインポート属性がない場合、インポートされたモジュールスクリプトのタイプはJavaScriptになる。typeインポート属性を持つimportステートメントを使用してJavaScriptリソースをインポートしようとすると失敗する：

<script type="module">
    // All of the following will fail, assuming that the imported .mjs files are served with a
    // JavaScript MIME type. JavaScript module scripts are the default and cannot be imported with
    // any import type attribute.
    import foo from "./foo.mjs" with { type: "javascript" };
    import foo2 from "./foo2.mjs" with { type: "js" };
    import foo3 from "./foo3.mjs" with { type: "" };
    await import("./foo4.mjs", { with: { type: null } });
    await import("./foo5.mjs", { with: { type: undefined } });
</script>

この例は、イベントリスナーが呼び出される順序を示す。この例でボタンがユーザーによってクリックされる場合、ページはそれぞれテキスト"ONE"、"TWO"、"THREE"、"FOUR"をもつ4つの警告を表示する。

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

しかし、次の例では、イベントハンドラーは、最初のアクティブ化の後（およびイベントリスナーが削除された後）、後で再アクティブにされる前に非アクティブにされる。このページには、"ONE"、"TWO"、"THREE"、"FOUR"、"FIVE"の順に5つのアラートが表示される。

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

たとえば、次の文書断片で：

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

文書がロードされるときに"[object Window]"という警告を、ページでユーザーが何かをクリックするときはいつでも"[object HTMLBodyElement]"という警告を流す。

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

開発者は、location.originよりもself.originを使用することを強く勧める。前者は環境の生成元を、後者は環境のURLを返す。https://stargate.example/文書で次のスクリプトを実行することを想像してみる：

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

self.originの方がより信頼性の高いセキュリティ指標となる。