[1] 窓は、 Webブラウザーにおいて利用者にレンダリングを提示するための基本的な単位です。
:hover や :focus の状態にあるハイパーリンクの
URL を表示したりします。[5] 実装によっては、相当するものが存在しないかもしれません。例えば、 サイドバーに相当するものが無いかもしれません。
[6] 実装によっては、複数の窓でこれら構成要素の一部を共有しているかもしれません。 例えばタブブラウザーでは、ここでいう窓はタブに当たり、 アドレスバーはそのタブを含む窓全体で共有しているかもしれません。 Mac OS では、メニューバーはプラットフォーム全体で共有しているかもしれません。
[8] 一般的なWebブラウザーでは、最上位閲覧文脈が補助閲覧文脈かどうかで、 構成要素の表示の有無や機能が変化します。例えばアドレスバーは、 補助閲覧文脈なら利用者が書き換えできなくなります。
[29] 他に、窓は次の状態を持ちます。title。
本窓がプラットフォームの窓としてレンダリングされるなら、
プラットフォームの窓システムに対して、 (必要があれば)
本窓の名前として提示するものです。
例えば Windows では、タスクバーやタスクマネージャーの表示に使われます。
本窓がタブとしてレンダリングされるなら、
タブの名前として表示されるかもしれません。<meta name=theme-color>
で指定された値 (あれば)。
本窓がプラットフォームの窓としてレンダリングされるなら、
プラットフォームの窓システムに対して、 (必要があれば)
本窓の色として提示するものです。
本窓がタブとしてレンダリングされるなら、
タブの色として使われるかもしれません。
その他、タイトルバーなどのレンダリングにも使うかもしれません。visibilitychange が発火されるかもしれません。visibilitychange が発火されるかもしれません。
[2] そのまま窓として実装するのが初期の方法でしたが、 現在ではタブとして実装するのが一般的になっています。 あるいは MDI におけるサブウィンドウとして表現されることもあります。 その他の表現方法も可能でしょう。 いずれにせよ、 CSSOM の定義上は一括して窓と呼ばれています。
[7] かつては、モーダルダイアログとして表示される窓もありました
(showModalDialog)。
[9] かつては、二次的閲覧文脈として、1つの窓に複数の最上位閲覧文脈が存在する形態も想定されていました。 これは本体の画面の他にサイドバーにも別の画面が埋め込まれた状態を表していました。
[18] 画面における窓の位置に関する次の操作が定義されています >>17。
[19] 窓自体の大きさに関する次の操作が定義されています >>17。
[25] resizeTo は viewport の大きさを指定することで、
窓の大きさを変更します >>17。 resizeBy
は窓の大きさの差分を指定して変更します >>17。
[26] window.open において、left と top
は窓の左辺と上辺の位置を指定するものとされています。
一方 width と height は、
viewport の幅と高さを指定するものとされています。 >>17
[27] これらの有用性や整合性を考慮すると、 viewport の大きさと窓の大きさが連動することが期待されているようです。
[28] outerWidth と outerHeight
は、窓の幅と高さを返します >>17。
[24] 位置の表現については、座標系を参照。 マルチディスプレイ環境については、画面を参照。
[37] 画面の表示範囲外に窓を配置できるかどうか、 できるとして画面からどれだけ離れられるかは、 プラットフォームに依存します。プラットフォームによる制約がない場合であっても、 利用者の不便を防ぐため、また悪意ある著者による濫用を防ぐため、 窓は利用者の閲覧可能な範囲に入るように配置するべきです。
[38] window.open で画面よりも大きな width
が指定された場合には、利用者の不便を防ぐため、プラットフォームまたは
Webブラウザーは画面の幅 (正確には左端位置を考慮した残りの幅)
に収まるように調整するべきです。実際利用者の画面サイズを考慮せず大画面想定の
width や height を指定して操作困難な Webサイトが存在しています。
[30] プラットフォームによっては、窓を非表示状態にすることができ、 「最小化」、「アイコン化」などと呼ばれています。
[44] プラットフォームによっては、 利用者の操作によって、あるいは他のアプリケーションの指示により、 窓の寸法が変化することがあります。 細かな変化のほか、 最大化と通常サイズ化の状態も多くのプラットフォームにあります。
[43]
窓の寸法が変化すると、普通、viewport もそれに応じた適切な寸法に変更されます。
それによってレンダリングの更新があり resize
イベントが発火されたりします。
[45] プラットフォームによっては、他のアプリケーションに切り替えたり、 最小化したりできます。 Webブラウザーによってはタブなどの形で同様の機能を Webブラウザーのアプリケーション内部で実装していることが多いです。
[33] 固定状態では、窓の外側も含め、マウスの操作によってプラットフォームのフォーカスが移動しないことが期待されています。
[34] その実現のためにはプラットフォームにそのような機能が必要です。 Webブラウザーは、 Pointer Lock の状態の変化にあわせて窓外のフォーカスの扱いを変更するよう、 適宜プラットフォームの API を通じて指示する必要があります。
[35] しかし他の操作や、利用者の操作以外の理由でフォーカスが失われることがあります。 その場合利用者エージェントは固定状態を解除する必要があります。
[12] 窓を閉じることを選択すると、最上位閲覧文脈について閲覧文脈を捨てる操作を実行することが期待されています。
[4] 実際上、これはタブブラウザーならタブを閉じる操作かもしれませんし、 窓を閉じる操作によりその窓のすべてのタブを同時に閉じるのかもしれません。
[13] 閲覧文脈を捨てる際に、スクリプトを無効にしても構わないとされています
(閲覧文脈を捨てる参照)。つまりスクリプト実行中など閲覧文脈が通常の利用者の操作を直ちに受け付けない状態であっても、
閲覧文脈を捨てる機能を提供できます。実際、スクリプトの暴走や、
モーダルダイアログの乱用、 onbeforeunload や onunload
の処理が長い場合などを想定すると、通常の「閉じる」操作と、
それにより閉じられない場合に強制的に「閉じる」操作の両方を利用者に提供する方が良さそうです。
[20] 閲覧文脈は、窓を持ちます。
最上位閲覧文脈では、窓が値となります。
入れ子閲覧文脈では、 null です。
[23] 閲覧文脈の窓は、作成時に決まり、以後変化しません。
[21] CSSOM View 仕様書は、「閲覧文脈's window」 のような表現を使っています >>17 が、その定義は与えていません。
[22] CSSOM View の outerWidth と outerHeight
は、「client window」という語を使っています >>17 が、
その定義は与えていません。
[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