Window

窓 (Web)

[1] (ウィンドウ) (window) は、 Webブラウザーにおいて利用者レンダリングを提示するための基本的な単位です。

仕様書

構成要素

[3] は、次の構成要素を持ちます。

アドレスバー
最上位閲覧文脈文書番地HTTPS状態などを表示します。また、利用者の操作により最上位閲覧文脈navigate の指示をします。
タイトルバー
題名表示します。
メニューバー
機能ツールバー
リンクツールバー
ブックマークの一部または全部を表示し、 利用者の指示により最上位閲覧文脈navigate の指示をします。
状態バー
最上位閲覧文脈における navigate の進捗を表示したり、 :hover:focus の状態にあるハイパーリンクURL を表示したりします。
busy indicator
最上位閲覧文脈における navigate の進捗を表示します。
サイドバー
viewport
最上位閲覧文脈レンダリングします。
音声再生中か否か
Chromeタブ音声再生しているかどうかを表示します。

[5] 実装によっては、相当するものが存在しないかもしれません。例えば、 サイドバーに相当するものが無いかもしれません。

[6] 実装によっては、複数のでこれら構成要素の一部を共有しているかもしれません。 例えばタブブラウザーでは、ここでいうタブに当たり、 アドレスバーはそのタブを含む全体で共有しているかもしれません。 Mac OS では、メニューバープラットフォーム全体で共有しているかもしれません。

[8] 一般的なWebブラウザーでは、最上位閲覧文脈補助閲覧文脈かどうかで、 構成要素の表示の有無や機能が変化します。例えばアドレスバーは、 補助閲覧文脈なら利用者が書き換えできなくなります。

[29] 他に、は次の状態を持ちます。

最上位閲覧文脈
最上位閲覧文脈への強い参照を保持します (最上位閲覧文脈参照)。
X
画面上の左辺の位置。
Y
画面上の上辺の位置。
画面上の
高さ
画面上の高さ
題名
最上位閲覧文脈文書title。 本プラットフォームとしてレンダリングされるなら、 プラットフォーム窓システムに対して、 (必要があれば) 本の名前として提示するものです。 例えば Windows では、タスクバータスクマネージャーの表示に使われます。 本タブとしてレンダリングされるなら、 タブの名前として表示されるかもしれません。
最上位閲覧文脈文書<meta name=theme-color> で指定された値 (あれば)。 本プラットフォームとしてレンダリングされるなら、 プラットフォーム窓システムに対して、 (必要があれば) 本として提示するものです。 本タブとしてレンダリングされるなら、 タブとして使われるかもしれません。 その他、タイトルバーなどのレンダリングにも使うかもしれません。
favicon
最上位閲覧文脈文書favicon (あれば)。 なければWebブラウザー依存のアイコン。 現在の一般的な Webブラウザーでは、タブに表示されます。 アドレスバープラットフォーム一覧などに表示されることもあります。
最小化
最小化状態かどうかを表します。 文書可視性状態に影響します。 値が変化した時 visibilitychange発火されるかもしれません。
前景
同じの他のタブによって隠れた状態でないかどうかを表します。 文書可視性状態に影響します。 値が変化した時 visibilitychange発火されるかもしれません。
プラットフォームの焦点を持つ
ウィンドウマネージャーフォーカスを持った状態かどうかを表します。 Pointer Lock 状態への移行時に参照されます。 フォーカスを持っていても他のタブが前景にあれば、 とするべきと思われます。 同じ内に複数の最上位閲覧文脈が同時に表示された状態で本閲覧文脈フォーカスがない時も、 とするべきと思われます。

レンダリング

[2] そのままとして実装するのが初期の方法でしたが、 現在ではタブとして実装するのが一般的になっています。 あるいは MDI におけるサブウィンドウとして表現されることもあります。 その他の表現方法も可能でしょう。 いずれにせよ、 CSSOM の定義上は一括してと呼ばれています。

[7] かつては、モーダルダイアログとして表示されるもありました (showModalDialog)。

[9] かつては、二次的閲覧文脈として、1つのに複数の最上位閲覧文脈が存在する形態も想定されていました。 これは本体の画面の他にサイドバーにも別の画面が埋め込まれた状態を表していました。

[10] この仕様は削除されましたが、1つのに複数の最上位閲覧文脈を埋め込むこと自体が禁止されたわけではありません (どのようなの構成にし、どのように利用者に提供するかは、 Webブラウザーの裁量の範囲内です)。ただ、それは何らかの関係を持った閲覧文脈同士ではなく、 たまたま画面表示上並んでいるだけの別個の閲覧文脈でしかないものとしなければならない、ということです。

窓と画面

[16] は、画面上に表示されます。

[18] 画面におけるの位置に関する次の操作が定義されています >>17

[19] 自体の大きさに関する次の操作が定義されています >>17

[25] resizeToviewport の大きさを指定することで、 の大きさを変更します >>17resizeByの大きさの差分を指定して変更します >>17

[26] window.open において、lefttop左辺上辺の位置を指定するものとされています。 一方 widthheight は、 viewport の幅と高さを指定するものとされています。 >>17

[27] これらの有用性や整合性を考慮すると、 viewport の大きさとの大きさが連動することが期待されているようです。

[28] outerWidthouterHeight は、高さを返します >>17

[24] 位置の表現については、座標系を参照。 マルチディスプレイ環境については、画面を参照。

[37] 画面の表示範囲外にを配置できるかどうか、 できるとして画面からどれだけ離れられるかは、 プラットフォームに依存します。プラットフォームによる制約がない場合であっても、 利用者の不便を防ぐため、また悪意ある著者による濫用を防ぐため、 利用者の閲覧可能な範囲に入るように配置するべきです。

[38] window.open画面よりも大きな width が指定された場合には、利用者の不便を防ぐため、プラットフォームまたは Webブラウザー画面の幅 (正確には左端位置を考慮した残りの幅) に収まるように調整するべきです。実際利用者画面サイズを考慮せず大画面想定の widthheight を指定して操作困難な Webサイトが存在しています。

[39] 画面から完全に隠れたを開けると、利用者はそれに気づかないかもしれません。 回線利用料や電力消費量を利用者の気づかないうちに増大させたり、 意図しない音声再生が開始されて操作困難になったりする危険性があります。

[40] タスクバーメニューバーなどの画面上に最前面で表示されるプラットフォームの機能が存在しているときは、 それに隠れて操作不能となることも避ける必要があります。

最小化

[30] プラットフォームによっては、を非表示状態にすることができ、 「最小化」、「アイコン化」などと呼ばれています。

変化への反応

[44] プラットフォームによっては、 利用者の操作によって、あるいは他のアプリケーションの指示により、 寸法が変化することがあります。 細かな変化のほか、 最大化と通常サイズ化の状態も多くのプラットフォームにあります。

プラットフォームからの変化の通知に対して・・・

[43] 寸法が変化すると、普通、viewport もそれに応じた適切な寸法に変更されます。 それによってレンダリングの更新があり resize イベント発火されたりします。


[45] プラットフォームによっては、他のアプリケーションに切り替えたり、 最小化したりできます。 Webブラウザーによってはタブなどの形で同様の機能を Webブラウザーアプリケーション内部で実装していることが多いです。

[46] 完全に非表示となる場合以外に、 他のに一部または全部が隠されながら裏側で表示されていることもあります。

フォーカス

[33] 固定状態では、の外側も含め、マウスの操作によってプラットフォームフォーカスが移動しないことが期待されています。

固定状態参照。

[34] その実現のためにはプラットフォームにそのような機能が必要です。 Webブラウザーは、 Pointer Lock の状態の変化にあわせて外のフォーカスの扱いを変更するよう、 適宜プラットフォームAPI を通じて指示する必要があります。

[35] しかし他の操作や、利用者の操作以外の理由でフォーカスが失われることがあります。 その場合利用者エージェント固定状態を解除する必要があります。

閉じる

[11] には、「閉じる」操作が必要です。

[12] を閉じることを選択すると、最上位閲覧文脈について閲覧文脈を捨てる操作を実行することが期待されています。

[4] 実際上、これはタブブラウザーならタブを閉じる操作かもしれませんし、 を閉じる操作によりそののすべてのタブを同時に閉じるのかもしれません。

[13] 閲覧文脈を捨てる際に、スクリプトを無効にしても構わないとされています (閲覧文脈を捨てる参照)。つまりスクリプト実行中など閲覧文脈が通常の利用者の操作を直ちに受け付けない状態であっても、 閲覧文脈を捨てる機能を提供できます。実際、スクリプトの暴走や、 モーダルダイアログの乱用、 onbeforeunloadonunload の処理が長い場合などを想定すると、通常の「閉じる」操作と、 それにより閉じられない場合に強制的に「閉じる」操作の両方を利用者に提供する方が良さそうです。

閲覧文脈の窓

[20] 閲覧文脈は、を持ちます。 最上位閲覧文脈では、が値となります。 入れ子閲覧文脈では、 null です。

[23] 閲覧文脈は、作成時に決まり、以後変化しません。

[21] CSSOM View 仕様書は、「閲覧文脈's window」 のような表現を使っています >>17 が、その定義は与えていません。

[22] CSSOM ViewouterWidthouterHeight は、「client window」という語を使っています >>17 が、 その定義は与えていません。

DnD

[36] DnD 参照。

関連

[14] Window は、に対応する機能として作られたものですが、 現在では閲覧文脈に近いものとして規定されています。

歴史

[32] security: suggest ux element to identify automation windows (andreastt著, ) https://github.com/w3c/webdriver/commit/a8ac274c1124ff24568d3579614dc65ff0c0d1c9

[41] Add FullscreenOptions dictionary to requestFullscreen by dtapuska · Pull Request #129 · whatwg/fullscreen () https://github.com/whatwg/fullscreen/pull/129

[42] Request Fullscreen take additional options · Issue #123 · whatwg/fullscreen () https://github.com/whatwg/fullscreen/issues/123