1. はじめに
このセクションは規定ではありません。
1997年、HTML4 [HTML401]は、異なるメディアタイプごとに調整された、メディア依存のスタイルシートをサポートする仕組みを定義しました。 例えば、ドキュメントは画面用と印刷用で異なるスタイルシートを使用できます。 HTMLでは、次のように記述できます:
<link rel="stylesheet" type="text/css" media="screen" href="style.css"> <link rel="stylesheet" type="text/css" media="print" href="print.css">
CSSは@mediaや@import規則でこの機能を発展・拡張し、個別機能の値を問い合わせる能力を追加しました:
@media screen { * { font-family: sans-serif } }
同様に、メディアクエリに基づいてスタイルシートを条件付きでインポートできます:
@import "print-styles.css" print;
メディアクエリは、HTML、XHTML、XML [xml-stylesheet]、およびCSSの@importや@media規則で利用できます。
<link media="screen and (color), projection and (color)" rel="stylesheet" href="example.css"> <link media="screen and (color), projection and (color)" rel="stylesheet" href="example.css" /> <?xml-stylesheet media="screen and (color), projection and (color)" rel="stylesheet" href="example.css" ?> @import url(example.css) screen and (color), projection and (color); @media screen and (color), projection and (color) { … }
1.1. モジュール間の連携
このモジュールは[MEDIAQUERIES-4]およびその前身[MEDIAQUERIES-3]を拡張し、置き換えます。 これらは、CSS2 § 7 Media typesを基盤に構築・置換したものです。
1.2. 値
この仕様で定義されていない値型、例えば<integer>、<number>、<resolution>などは[CSS-VALUES-4]で定義されています。他のCSSモジュールがこれらの値型の定義を拡張することもあります。
1.3. 単位
メディアクエリで使われる単位は、[CSS-VALUES-4]で定義されているCSSの他の部分と同じです。例えば、ピクセル単位はCSSピクセルを表し、物理ピクセルではありません。
相対長単位は、初期値に基づきます。 つまり、単位は宣言の結果に基づくことはありません。
注: 例えばHTMLでは、 em単位はfont-sizeの初期値(UAやユーザー設定による)に対して相対的です。 ページのスタイリングには依存しません。 この値はユーザーが適用する追加制約(最小フォントサイズなど)も考慮されます。
1.4. Prefers-* メディア機能のセキュリティとプライバシー
この仕様を実装するUAや開発者は、このベクトルに注意し、機能利用時に考慮する必要があります。 特に `prefers-reduced-motion`、`prefers-color-scheme`、`prefers-reduced-data` は悪用の懸念があります。
2. メディア クエリ
メディアクエリは、ユーザーエージェントやドキュメントが表示されるデバイスの特定の側面をテストする方法です。メディアクエリは(ほぼ)常にドキュメントの内容・スタイリング・その他内部的な側面に依存せず、 「外部」情報のみに依存します(他の機能が明示的にメディアクエリの解決に影響すると指定しない限り)。
メディアクエリの構文は、 オプションのメディアクエリ修飾子、 オプションのメディアタイプ、 0個以上のメディア機能からなります:
メディアクエリは真偽値を返す論理式です。 メディアクエリがtrueになる条件:
このセクションでのメディアクエリに関する記述は構文セクションが順守されることを前提とします。 構文に準拠しないメディアクエリについては§ 3.2 エラー処理で扱います。 すなわち、構文がこのセクションの要件より優先されます。
<link rel="stylesheet" media="screen and (color)" href="example.css" />
この例は、特定のスタイルシート(example.css
)が、特定のメディアタイプ(screen)かつ「カラー画面」の機能を持つデバイスに適用されることを示します。
同じメディアクエリをCSSの@import規則で書くと:
@import url(example.css) screen and (color);
ユーザーエージェントは、認識できるユーザー環境の変化(例:デバイスがランドスケープからポートレートに切り替わる等)に応じてメディアクエリを再評価し、 それらのメディアクエリに依存する構造の挙動を適切に変更しなければなりません。
他の機能が明示的にメディアクエリ解決に影響すると指定しない限り、式の評価のためにスタイルシートを適用する必要はありません。
2.1. メディアクエリの組み合わせ
複数のメディアクエリは、カンマ区切りでメディアクエリリストとして組み合わせることができます。
メディアクエリリストは、その構成要素のいずれかのメディアクエリがtrueの場合にtrueとなり、 構成要素のメディアクエリがすべてfalseの場合のみfalseになります。
@media screen and (color), projection and (color) { … }
空のメディアクエリリストはtrueと評価されます。
2.2. メディアクエリ修飾子
メディアクエリは、単一のメディアクエリ修飾子を前置することができます。 これは、続くメディアクエリの意味を変更する単一キーワードです。
2.2.1. メディアクエリの否定:notキーワード
個々のメディアクエリは、 notキーワードを前置することで結果を否定できます。 メディアクエリが通常trueと評価される場合、 notを前置するとfalseとなり、 逆も同様です。
<link rel="stylesheet" media="not screen and (color)" href="example.css" />
2.2.2. レガシーUAからのメディアクエリ隠蔽:onlyキーワード
メディアクエリの概念はHTML4[HTML401]に由来します。 この仕様ではメディアタイプのみ定義されましたが、将来的なメディア機能追加を考慮した前方互換構文がありました: クエリ文字列の最初の非英数字文字までをメディアクエリとして解釈し、それをメディアタイプとして扱い、残りは無視されます。 例えば、media query screen and (color)はscreenだけに切り詰められます。
このため、レガシーUAはこのエラー処理により、 メディア機能を含むメディアクエリを無視します。 これは、クエリ内のメディアタイプよりも重要な場合でも、スタイルが意図しない状況で適用される原因となります。
こうしたメディアクエリをレガシーUAから隠すには、 メディアクエリにonlyキーワードを前置します。 onlyキーワードはメディアクエリの結果に影響しませんが、 レガシーUAは未知のメディアタイプ「only」としてパースし、無視されます。
<link>
要素で指定されたスタイルシートは、
レガシーUAには適用されません。
本来screenメディアタイプに一致する場合でも同様です。
<link rel="stylesheet" media="only screen and (color)" href="example.css" />
注: onlyキーワードはメディアタイプの前にのみ使用できます。 メディアクエリがメディア機能のみの場合や、notなど他の修飾子を使った場合は、レガシーUAで自動的にfalseと扱われます。
注: この仕様公開時点で、こうしたレガシーUAは非常に稀であり、 only修飾子を使う必要はほとんどありません。
2.3. メディアタイプ
メディアタイプは、ドキュメントが表示されるユーザーエージェントデバイスの大まかなカテゴリです。
元々のメディアタイプはHTML4で、
<link>
要素のmedia
属性用に定義されました。
しかし、メディアタイプだけでは、異なるスタイリングが必要なデバイスを区別する手段として不十分と判明しました。 もともと区別が明確だったカテゴリ(screenやhandheldなど)は、近年その境界が大きく曖昧になりました。 他にもttyやtvなどは、通常の高機能モニターとは異なる有用な違いを示すため、別スタイリングの対象として有用ですが、 メディアタイプが互いに排他的に定義されているため、現実的な使い方が難しくなっています。 代わりに、こうした排他的な側面はmedia feature(例:gridやscan)で表現する方が適しています。
このため、メディアタイプは、メディアクエリで以下のものが定義されています:
- all
- すべてのデバイスに一致します。
- プリンター、および印刷表示を再現するためのデバイス(例:ウェブブラウザの「印刷プレビュー」)に一致します。
- screen
- printに一致しないすべてのデバイスに一致します。
加えて、以下の非推奨メディアタイプも定義されています。 著者はこれらのメディアタイプを使用しないでください。 代わりに、対象デバイスの特徴をより適切に表すメディア機能を選択するのがおすすめです。
ユーザーエージェントは、以下のメディアタイプを有効として認識しなければなりませんが、何にも一致しないようにしなければなりません。
注: 今後すべてのメディアタイプは順次非推奨となる見込みであり、 重要な違いを捉える適切なメディア機能が定義され次第置き換えられる予定です。
2.4. メディア機能
メディア機能は、メディアタイプよりも細かい粒度で、ユーザーエージェントや表示デバイスの特定の機能をテストします。
構文的には、メディア機能はCSSプロパティに似ています: 機能名、コロン、テストする値で構成されます。 また、機能名のみで真偽型(ブール型)として書いたり、比較演算子を使った範囲型として書くこともできます。
ただし、プロパティとメディア機能にはいくつか重要な違いがあります:
- プロパティはドキュメントの表示方法に関する情報を与えます。 メディア機能は出力デバイスの要件を記述します。
- メディア機能は常に括弧で囲み、andやorキーワードで組み合わせます。 例:(color) and (min-width: 600px)。セミコロンで区切りません。
- メディア機能は機能名のみ(コロンと値を省略)で書くこともでき、真偽型コンテキストで評価されます。 0や「none」を適切に表す値がある場合、簡便な省略記法です。 例えば、(color)はcolor メディア機能がゼロ以外の場合trueです。
- 「range」型のメディア機能は範囲コンテキストで、コロンの代わりに標準的な数学比較演算子を使ったり、機能名に「min-」や「max-」を接頭できます。
- プロパティは複雑な値(複数値の計算など)を受け入れることがありますが、メディア機能は単一値のみ受け入れます:キーワード1つ、数値1つなど。
メディア機能がUAの動作するデバイス上に存在しない概念を参照した場合(例:音声UAに「width」の概念はない)、 メディア機能は常にfalseとなります。
<link media="speech and (device-aspect-ratio: 16/9)" rel="stylesheet" href="example.css">
2.4.1. メディア機能の型:「range」と「discrete」
各メディア機能は定義表で「range」または「discrete」の型を指定します。
「discrete」メディア機能(例:pointer)は、値が集合から選ばれます。 値はキーワードやブール数(0, 1)ですが、値同士に順序性(大小関係)はありません。
「range」メディア機能(例:width)は、値が範囲を持ちます。 2つの値を比較してどちらが大きいか判定できます。
両者の主な違いは、「range」型メディア機能は範囲コンテキスト評価や「min-」「max-」接頭辞を受け付けることです。 これらを使うと、値が完全一致した場合だけtrueではなく、「より大きい/より小さい/等しい」場合にtrueとなります。
一方、(width: 600px)は幅が600pxぴったりのときだけtrueです。 それ以外はfalseになります。
2.4.2. メディア機能の真偽型コンテキストでの評価
メディア機能は通常CSSプロパティに似た構文ですが、 機能名だけで簡易記述することもできます(例:(color))。
この場合、メディア機能は真偽型コンテキストで評価されます。 値が0以外、<dimension>の値が0、 キーワードnone、またはそのメディア機能の仕様でfalseと定義される値以外ならtrueになります。 それ以外はfalseです。
例えば、updateは通常(update)で任意の更新機能の有無を判定したり、not (update)でその逆を判定します。
明示値を与えることもでき、(update: fast)や(update: slow)は(update)と等価、 (update: none)はnot (update)と等価です。
例えば、(pointer)は便利で、pointerにはポインティングデバイスが一切ないことを示すnone値があります。 一方、(scan)は「false」を意味する値がないため、常にtrueかfalseです(デバイスに適用可能かによる)。
2.4.3. 範囲コンテキストでのメディア機能評価
「range」型メディア機能は、値に順序性があることを利用し、通常の数学比較演算子を使う範囲コンテキストとして書くこともできます:
注: この構文はMediaqueries Level 4で新しく導入されたため、現時点ではmin-/max-接頭辞ほど広くサポートされていません。
基本形は、機能名、比較演算子、値で構成され、関係が成り立てばtrueとなります。
機能名が2つの値比較の間に入る形は、両方の比較がtrueならtrueを返します。
「range」型メディア機能の中には負の範囲でfalseとなるものもあります。 これは、負の値が有効でパースされるべきであり、 メディア機能が負値と等しい・より小さい・以下かどうかを判定する場合は必ずfalseとなることを意味します。 負値より大きい・以上かどうかは、関係が成り立てばtrueです。
注: 負値をパース時に却下した場合は、エラー処理規則によりunknown扱いになります。 しかし実際は、デバイスのresolutionが-300dpiかどうかは「不明」ではなくfalseです。 同様に、視覚デバイスならwidthは-200pxより大きいことが確定しています。 このルールはUAの直感的な動作と一致させるためのものです。
@media not ( width <= -100 px ) {
body { background : green; }
}
@media ( height > -100 px ) {
body { background : green; }
}
@media not ( resolution: -300 dpi ) {
body { background : green; }
}
2.4.4. 範囲型機能で「min-」「max-」接頭辞を使う方法
上記のように「range」型メディア機能を範囲コンテキストで評価する代わりに、 通常のメディア機能として、 機能名に「min-」または「max-」接頭辞を付けて記述できます。
これは範囲コンテキストで機能を評価するのと同等です。具体的には:
- 機能名に「min-」接頭辞を使うのは「>=」演算子と同等です。 例えば、(min-height: 600px)は''(height >= 600px)''と同じです。
- 機能名に「max-」接頭辞を使うのは「<=」演算子と同等です。 例えば、(max-width: 40em)は''(width <= 40em)''と同じです。
注: 「min-」や「max-」は値を含む範囲比較に相当するため、状況によっては制約が生じます。
@media (max-width: 320px) { /* ビューポートが 320px 以下のスタイル */ } @media (min-width: 321px) { /* ビューポートが 321px 以上のスタイル */ }
これで、ビューポート幅が320pxのとき同時適用を防げますが、 実際には非整数ピクセル密度(高DPIディスプレイやズーム・スケール等)による分数サイズも考慮する必要があります。 320pxと321pxの間のビューポート幅だと、どちらのスタイルも適用されません。
この問題の回避策として、比較値の精度を上げる方法があります。上記の例で、二つ目の比較値を320.01pxにすると、 デバイスの幅がその隙間に入る確率を大幅に減らせます。
@media (max-width: 320px) { /* ビューポートが 320px 以下のスタイル */ } @media (min-width: 320.01px) { /* ビューポートが 320.01px 以上のスタイル */ }
しかしこのような場合、範囲コンテキストクエリ(「>=」「<=」以外も使える)はより適切な解決策になります:
@media (width <= 320px) { /* ビューポートが 320px 以下のスタイル */ } @media (width > 320px) { /* ビューポートが 320px より大きいスタイル */ }
「discrete」型プロパティは「min-」「max-」接頭辞を受け付けません。 「discrete」型メディア機能にこの接頭辞を付けると、未知の機能名となります。
min/max接頭辞付きメディア機能を真偽型コンテキストで評価するのは無効で、構文エラーとなります。
2.5. メディア機能の組み合わせ
複数のメディア機能を、完全なブール代数(not, and, or)を使ってメディア条件として組み合わせることができます。
-
任意のメディア機能は、notを前置することで否定できます。 例えば、not (color)は(color)の意味を反転します。(color)が色表示可能なデバイスに一致するなら、not (color)は色表示できないデバイスに一致します。
-
2つ以上のメディア機能を「and」で連結すると、全てがtrueの時のみtrueになります。 例えば、(width < 600px) and (height < 600px)は、幅・高さともに600px未満のデバイスに一致します。
-
また、2つ以上のメディア機能を「or」で連結すると、いずれかがtrueであればtrueになります。 例えば、(update: slow) or (hover: none)は、画面更新が遅い(電子書籍端末など)またはホバー機能のない主要ポインティングデバイスの場合に一致します。 (ユーザーがホバーするまで情報を隠すより、常に表示した方が良い場合に使えます。)
-
メディア条件は括弧()でグループ化し、単一メディアクエリと同様に入れ子にできます。 例えば、(not (color)) or (hover)は、モノクロデバイスかつ/またはホバー機能があるデバイスでtrueです。 一方、モノクロかつホバー機能なしのデバイスを問い合わせるなら、not ((color) or (hover))(または等価な(not (color)) and (not (hover)))と書きます。
andとorとnotを同じ「レベル」で混在させるのは無効です。 例:(color) and (pointer) or (hover)は不正で、意味が曖昧です。 括弧でグループ化して特定の結合キーワードだけにすれば、(color) and ((pointer) or (hover))や((color) and (pointer)) or (hover)となります。 両者は意味が大きく異なり、(hover)だけがtrueの場合、前者はfalse、後者はtrueになります。
3. 構文
メディアクエリ構文の非公式な説明は、前セクションの本文やレイルロード図に記載されています。 ここでは正式な構文を示します。規則・プロパティ文法の構文は[CSS-SYNTAX-3]と[CSS-VALUES-4]で定義されています。
<media-query-list>生成式をパースするには、コンマ区切りコンポーネント値のパースを行い、 返されたリストの各要素を<media-query>としてパースします。 その値は生成された<media-query>のリストです。
注: <media-query-list>パースのこの明示定義は、メディアクエリリストのエラーリカバリー挙動を明確にするために必要です。
注: この<media-query-list>パース定義は空リストも明示的に受け付けます。
注: [CSS-SYNTAX-3]に従い、トークンはASCII大文字小文字非区別です。
<media-query> = <media-condition> | [ not | only ]? <media-type> [ and <media-condition-without-or> ]? <media-type> = <ident> <media-condition> = <media-not> | <media-in-parens> [ <media-and>* | <media-or>* ] <media-condition-without-or> = <media-not> | <media-in-parens> <media-and>* <media-not> = not <media-in-parens> <media-and> = and <media-in-parens> <media-or> = or <media-in-parens> <media-in-parens> = ( <media-condition> ) | <media-feature> | <general-enclosed> <media-feature> = ( [ <mf-plain> | <mf-boolean> | <mf-range> ] ) <mf-plain> = <mf-name> : <mf-value> <mf-boolean> = <mf-name> <mf-range> = <mf-name> <mf-comparison> <mf-value> | <mf-value> <mf-comparison> <mf-name> | <mf-value> <mf-lt> <mf-name> <mf-lt> <mf-value> | <mf-value> <mf-gt> <mf-name> <mf-gt> <mf-value> <mf-name> = <ident> <mf-value> = <number> | <dimension> | <ident> | <ratio> <mf-lt> = '<' '='? <mf-gt> = '>' '='? <mf-eq> = '=' <mf-comparison> = <mf-lt> | <mf-gt> | <mf-eq> <general-enclosed> = [ <function-token> <any-value> ) ] | ( <ident> <any-value> )
<media-type>生成式には、キーワードonly、 not、and、orは含まれません。
「<」や「>」<delim-token>の後ろに「=」<delim-token>がある場合、間に空白は許されません。
注: not、and、orキーワードの後ろに「(」文字が続く場合は空白必須です。 空白なしだと<function-token>と解釈されるためです。 これは文法で既に無効扱いなので明示的無効にはしません。 「)」の後ろにキーワードが来る場合は空白があっても問題ありません。
<media-in-parens>生成式のパース時、 <general-enclosed>分岐は、入力が前の分岐に一致しない場合のみ選択されます。<general-enclosed>は将来の文法拡張に互換性を持たせるために存在します。
3.1. メディアクエリの評価
<media-condition>や<media-condition-without-or>の主要な各部分式は、以下のようにブール値が割り当てられます:
- <media-condition>
- <media-condition-without-or>
- 子部分式の評価結果です。
- <media-in-parens>
- 子項の評価結果です。
- <media-not>
- <media-in-parens>項の否定です。 unknownの否定はunknownです。
- <media-in-parens> <media-and>*
- <media-in-parens>子項と、<media-in-parens>子項を持つ<media-and>子項全てがtrueならtrue、 いずれかがfalseならfalse、それ以外はunknownです。
- <media-in-parens> <media-or>*
- <media-in-parens>子項と、<media-in-parens>子項を持つ<media-or>子項全てがfalseならfalse、 いずれかがtrueならtrue、それ以外はunknownです。
- <general-enclosed>
-
評価結果はunknownです。
著者は<general-enclosed>をスタイルシートで使用してはいけません。これは将来互換性のためだけに存在し、古いUAで新しい構文追加によって<media-condition>全体が無効になるのを防ぐためです。
- <media-feature>
- 指定されたメディア機能の評価結果です。
上記生成式の評価結果が二値ブール型で期待されるコンテキストで使われる場合、 「unknown」は「false」に変換されなければなりません。
注: 例えば、 メディアクエリが@media規則で使われる場合、 「unknown」なら「false」として扱われ、一致しません。
一般に、式中にunknown値が現れるとその式もunknownになります。 unknownをtrueに置き換える場合とfalseに置き換える場合で結果が異なるためです。 唯一unknown値を消せるのは、unknownをtrue/falseどちらにしても結果が変わらない式の場合です。 例えば「false AND unknown」は必ずfalse、「true OR unknown」は必ずtrueです。
このロジックは<general-enclosed>に真偽値を割り当てる必要があるから導入されました。 標準ブール論理では「false」しか割り当てられませんが、これだとnot unknown(function)がtrueになってしまい、直感的でない場合があります。 Kleeneの三値論理ならunknownなものがあると、その値が最終結果に無関係でない限り一致しません。
3.2. エラー処理
前節の文法に一致しないメディアクエリは、パース時にnot allで置き換えられます。
注: 文法不一致はメディアクエリリスト全体を無効にするのではなく、問題のあるメディアクエリリストだけです。 上で定義されたパース挙動により、次のトップレベルのカンマで自動的に回復します。
@media (example, all,), speech { /* 音声デバイス専用 */ } @media &test, speech { /* 音声デバイス専用 */ }
上記のメディアクエリリストはいずれもパース時にnot all, speechに変換され、 speechだけと同じ真偽値になります。
エラー回復はメディアクエリのトップレベルでのみ起きます。 無効な括弧ブロックの中身はグループごとnot allに変換されます。 例:
@media (example, speech { /* 音声デバイス用ルール */ }
括弧ブロックが閉じられていないため、 その時点以降のスタイルシート全体が含まれ (スタイルシート内で一致しない「)」が現れないかぎり)、 全体がnot allなメディアクエリになります。
未知の<media-type>は一致しないものとして扱います。
ただしnot unknownはtrueになります。notでfalseなメディアタイプが反転されるためです。
未知の<mf-name>や<mf-value>、または許可されていない<mf-value>は「unknown」値となります。 値が「unknown」の<media-query>はnot allで置き換えます。
<link media="screen and (max-weight: 3kg) and (color), (color)"rel="stylesheet" href="example.css" />
max-weightが未知のメディア機能なので、 このメディアクエリリストはnot all, (color)に変換され、 (color)だけと同じ意味となります。
@media (min-orientation:portrait) { … }
orientation機能は接頭辞を受け付けないため、 これは未知のメディア機能とみなされ、not allに変換されます。
@media test;,all { body { background:lime } }
メディアクエリtest;,allは単独でパースするとnot all, allと等価で、常にtrueです。 しかし、CSSのパース規則では@media規則(つまりメディアクエリ)はセミコロンで終了します。 残りのテキストは不正なセレクタ・内容を持つスタイルルールとして扱われます。
4. ビューポート・ページ特性メディア機能
4.1. 幅: width機能
名称: | width |
---|---|
対象: | @media |
値: | <length> |
型: | range |
widthメディア機能は、出力デバイスの対象表示領域の幅を表します。 連続メディアの場合は、ビューポート(CSS2 9.1.1節[CSS2]で説明)、 レンダリングされたスクロールバーのサイズも含みます(あれば)。 ページメディアの場合は、ページボックスの幅です (CSS2 13.2節[CSS2]で説明)。
widthは負の範囲でfalseです。
<link rel="stylesheet" media="print and (min-width: 25cm)" href="http://…" />
@media (400px <= width <= 700px) { … }
4.2. 高さ: height機能
名称: | height |
---|---|
対象: | @media |
値: | <length> |
型: | range |
heightメディア機能は、出力デバイスの対象表示領域の高さを表します。 連続メディアの場合は、ビューポートの高さ(レンダリングされたスクロールバーのサイズも含む)、 ページメディアの場合はページボックスの高さです。
heightは負の範囲でfalseです。
4.3. アスペクト比: aspect-ratio 機能
名称: | aspect-ratio |
---|---|
対象: | @media |
値: | <ratio> |
型: | range |
aspect-ratioメディア機能は、 widthメディア機能の値を heightメディア機能の値で割った比率として定義されています。
4.4. 向き: orientation 機能
名称: | orientation |
---|---|
対象: | @media |
値: | portrait | landscape |
型: | discrete |
- portrait
- orientationメディア機能は、portraitとなります。heightメディア機能の値が widthメディア機能の値以上の場合です。
- landscape
- それ以外の場合、orientationはlandscapeです。
4.5. ブロック軸のオーバーフロー: overflow-block 機能
名称: | overflow-block |
---|---|
対象: | @media |
値: | none | scroll | paged |
型: | discrete |
overflow-blockメディア機能は、 ブロック軸方向で 初期包含ブロックからコンテンツがあふれた場合のデバイスの挙動を示します。
- none
- ブロック軸方向でオーバーフローする場合、 何の表示手段もありません。あふれたコンテンツは表示されません。 例:ビルボード
- scroll
- ブロック軸方向の オーバーフローしたコンテンツは、ユーザーがスクロールできることで表示されます。 例:コンピュータ画面
- paged
- コンテンツは個々のページに分割されます。 ブロック軸方向で 1ページからあふれたコンテンツは次ページに表示されます。 例:プリンター、電子書籍リーダー
noneやscroll に一致するメディアは連続メディア、 pagedに一致するものはページメディアと呼ばれます。
注: このメディア機能には将来、 連続メディアとページメディア の両方の挙動を持つハイブリッド型ユーザーエージェントを表現する値が追加される可能性があります。 例:Prestoレイアウトエンジン(現在は廃止)はセミページ化した表示モードを持ち、基本はcontinuousだが強制改ページは尊重しました。 現在このような挙動のUAは存在しないため、誤った分類を避けるため本レベルでは追加しません。 上記で十分に記述できないUAを実装する場合は、作業グループまでご連絡ください。拡張の検討を行います。
4.6. インライン軸のオーバーフロー: overflow-inline 機能
名称: | overflow-inline |
---|---|
対象: | @media |
値: | none | scroll |
型: | discrete |
overflow-inlineメディア機能は、 インライン軸方向で 初期包含ブロックからコンテンツがあふれた場合のデバイスの挙動を示します。
- none
- インライン軸方向でオーバーフローする場合、 何の表示手段もありません。あふれたコンテンツは表示されません。
- scroll
- インライン軸方向の オーバーフローしたコンテンツは、ユーザーがスクロールできることで表示されます。
注: インライン方向のオーバーフローをページ分割する実装例は知られておらず、その概念自体も妥当性が薄いので、 paged値はoverflow-inlineに意図的にありません。
4.7. 水平ビューポートセグメント: horizontal-viewport-segments 機能
名称: | horizontal-viewport-segments |
---|---|
対象: | @media |
値: | <integer> |
型: | range |
horizontal-viewport-segmentsメディア機能は ビューポートの水平方向に論理的に分割されたセグメント数を示します。
horizontal-viewport-segmentsメディア機能は 負の範囲でfalseです。
ビューポートが、折り目や複数画面間のヒンジなどのハードウェア要素で分割される場合、 セグメントはページで論理的に区別できる領域です。
4.8. 垂直ビューポートセグメント: vertical-viewport-segments 機能
名称: | vertical-viewport-segments |
---|---|
対象: | @media |
値: | <integer> |
型: | range |
vertical-viewport-segmentsメディア機能は ビューポートの垂直方向に論理的に分割されたセグメント数を示します。
vertical-viewport-segmentsメディア機能は 負の範囲でfalseです。
@media (horizontal-viewport-segments: 2) and (vertical-viewport-segments: 1) { … }
4.9. 表示モード: display-modeメディア機能
名称: | display-mode |
---|---|
対象: | @media |
値: | fullscreen | standalone | minimal-ui | browser |
型: | discrete |
display-modeメディア機能は、ウェブアプリケーションの表示モードを表します。 子ブラウジングコンテキストは、display modeを自身のトップレベルブラウジングコンテキストから反映します。
表示モードは、ウェブアプリケーションがOSのコンテキスト内でどのように表示されているか(例:フルスクリーンなど)を示します。 表示モードは、プラットフォーム上のユーザーインターフェース(UI)のメタファーや機能性に対応します。 表示モードのUI慣習はあくまで推奨であり、実装者は自由に解釈できます。
本仕様では以下の表示モードを定義します:
- fullscreen
- ブラウザのUI要素が非表示となり、利用可能な表示領域全体にウェブアプリが表示されます。
- standalone
- ウェブアプリがネイティブアプリのような見た目・操作性で表示されます。 これは、アプリが別ウィンドウを持つ、ランチャーに独自アイコンが表示される等を含みます。 このモードでは、ユーザーエージェントは標準的なブラウザUI(URLバー等)を除外しますが、 ウィンドウ装飾やシステムステータスバー、システムの戻るボタンなど標準システムUIは利用可能です。
- minimal-ui
- このモードはstandaloneに似ていますが、 ナビゲーション(戻る・進む・再読み込み・アドレス表示等)を制御する最低限のUI要素にアクセスできるようになっています。 ユーザーエージェントは、プラットフォーム固有のUI(共有・印刷ボタンなど)を追加する場合もあります。
- browser
- ウェブアプリが、ユーザーエージェントがハイパーリンクを開く時のプラットフォーム固有の慣習で表示されます (例えば、ブラウザタブや新しいウィンドウなど)。
fullscreen 表示モードは、Fullscreen APIとは異なります。
fullscreen 表示モードはブラウザのビューポートのフルスクリーン状態を示し、
Fullscreen APIはビューポート内の要素に対して操作します。
そのため、ウェブアプリのdisplay modeが
fullscreenであっても、
fullscreenElement
はnull
を返し、
fullscreenEnabled
はfalse
を返すことがあります。
fullscreen 表示モードは、CSSの:fullscreen疑似クラスとも直接関連しません。
:fullscreenは、要素がフルスクリーン要素スタックに入った時のみ一致します。
ただし、Fullscreen APIで
requestFullscreen()
を呼び出すと、ブラウザがOSレベルのフルスクリーンモードに入る場合があり、
その場合:fullscreenと(display-mode: fullscreen)の両方が一致します。
/* ビューポートがフルスクリーンの時に適用 */ @media ( display-mode: fullscreen) { ...} /* 要素がフルスクリーンの時に適用 */ #game:fullscreen{ ...}
5. 表示品質メディア機能
5.1. 表示解像度: resolution 機能
名称: | resolution |
---|---|
対象: | @media |
値: | <resolution> | infinite |
型: | range |
resolutionメディア機能は、出力デバイスの解像度(ピクセル密度)を表します。ページズームを考慮しますが、 ピンチズームは1.0と仮定します。
resolutionメディア機能は負の範囲でfalseです。
非正方ピクセルのメディアをクエリする場合、resolutionは縦方向の密度を判定します。
プリンターの場合は、スクリーニング解像度(任意色のドット印刷解像度)に対応します。 グレースケール印刷では解像度が異なる場合もあります。
解像度に物理的制約がない出力媒体(ベクターグラフィックス等)の場合、この機能はinfinite値に一致します。 範囲コンテキストでの評価では、infiniteは任意の<resolution>より大きいものとして扱われます。 (つまり、(resolution > 1000dpi)のクエリはinfiniteなメディアでtrueになります。)
@media print and (min-resolution: 300dpi) { … }
このメディアクエリは、CSS cm単位を使った場合と等価です:
@media print and (min-resolution: 118dpcm) { … }
ユーザーエージェントが物理ピクセルのジオメトリを知らない場合、または知っていて物理ピクセルがほぼ正方であれば、 各軸でCSSピクセルあたりのデバイスピクセル数に違いはありません。 そのため、縦横解像度の違いはありません。
一方、UAが軸ごとに異なるマッピングを選ぶ場合は、物理ピクセルが正方でないことへの対応です。どうUAがその情報を得るかは範囲外ですが、必要情報を得ているなら、デバイスを90度回転した場合などマッピングも反転可能です。
5.2. 表示タイプ: scan機能
名称: | scan |
---|---|
対象: | @media |
値: | interlace | progressive |
型: | discrete |
scanメディア機能は、出力デバイスの走査方式を示します。
- interlace
-
CRTや一部プラズマTV画面は「インターレース」描画を使用します。
映像フレームが「偶数行」と「奇数行」を交互に指定し、脳の自動補正効果で滑らかな動きを生み出します。
これにより高FPS放送を帯域半分でシミュレートできました。
インターレース画面表示時は、画面上を高速に動くオブジェクトは「櫛形」現象を避けるため控えめにし、細かいディテールは1px以上としてください(“twitter”を防ぐため)。
- progressive
-
「プログレッシブ」描画を使う画面は全体を一度に描画するため、特別な対応は不要です。
ほとんどの現代的な画面、そしてすべてのコンピュータ画面はプログレッシブ描画です。
@media (scan: interlace) { body { font-family: sans-serif; } }
注:
現時点の実装例はすべてscan: progressive
に一致し、scan: interlace
には一致しません。
5.3. コンソール表示検出: grid機能
名称: | grid |
---|---|
対象: | @media |
値: | <mq-boolean> |
型: | discrete |
gridメディア機能は、出力デバイスがグリッド型かビットマップ型かを判定するために使います。 出力デバイスがグリッド型(例:tty端末や固定フォントしか使えない携帯画面)の場合は値が1、 それ以外は0になります。
<mq-boolean>値型は、値が0または1の<integer>です。 他の整数値は不正です。なお、-0はCSSでは常に0と等価なので、 <mq-boolean>値としても有効です。
注: <mq-boolean>型はレガシー目的のみ存在します。 新規設計なら値に正しいキーワードを使ったはずです。
注: 現時点の実装例はすべてgrid: 0
に一致し、grid: 1
には一致しません。
5.4. 表示更新頻度: update機能
名称: | update |
---|---|
対象: | @media |
値: | none | slow | fast |
型: | discrete |
updateメディア機能は、出力デバイスがレンダリング後にコンテンツの見た目を変更できる能力を問い合わせるために使います。 次の値が指定できます:
- none
- 一度レンダリングされるとレイアウトの更新はできません。 例:紙に印刷された文書。
- slow
- レイアウトは通常のCSSルールに従い動的に変化することがありますが、 出力デバイスが変化を滑らかなアニメーションとして認識できるほど速く描画・表示することはできません。 例:E-ink画面や極端に性能の低いデバイス。
- fast
- レイアウトは通常のCSSルールに従い動的に変化でき、 出力デバイスの速度に特別な制約がないため、CSSアニメーションなどの定期更新が利用可能です。 例:コンピュータ画面。
@media (update) { a { text-decoration: none; } a:hover, a:focus { text-decoration: underline; } } /* 非更新型UAでは、リンクは常時デフォルトの下線が表示されます。 */
5.5. 表示技術検出: environment-blending機能
名称: | environment-blending |
---|---|
対象: | @media |
値: | opaque | additive | subtractive |
型: | discrete |
environment-blendingメディア機能は、ユーザーの表示デバイスの特性を問い合わせて、 著者がドキュメントのスタイルを調整できるようにします。 著者は表示技術によって、ページの見栄えや可読性向上のためにビジュアルやレイアウトを調整することがあります。
有効な値は以下の通りです:
- opaque
- 文書は不透明な媒体(従来型モニターや紙など)にレンダリングされます。 黒は暗く、白は100%明るいです。
- additive
-
表示デバイスはキャンバスの色と現実世界を加法混色でブレンドします。
黒は完全に透明、白は100%明るいです。
例:自動車のヘッドアップディスプレイ。
- subtractive
-
表示デバイスはキャンバスの色と現実世界を減法混色でブレンドします。
白は完全に透明、暗色が最もコントラストが高いです。
例:浴室ミラー内蔵型LCDディスプレイ。
subtractive値は必要でしょうか?
body { background-color: white; } p { color: black; } @media(environment-blending: additive) { body { background-color: black; } p { color: white; font-size: 16px; font-weight: 1000; } }
6. カラーメディア機能
6.1. カラー深度: color機能
名称: | color |
---|---|
対象: | @media |
値: | <integer> |
型: | range |
colorメディア機能は、出力デバイスの各カラー成分ごとのビット数を表します。 デバイスがカラー対応でなければ値は0です。
colorは負の範囲でfalseです。
@media (color) { … } @media (min-color: 1) { … }
異なるカラー成分が異なるビット数で表現される場合は、最小値を使用します。
インデックスカラー対応デバイスでは、参照テーブル内の各カラー成分の最小ビット数を使います。
注: この機能で記述できるのはカラー能力の表面的なレベルのみです。color-gamutの方が著者のニーズに合う場合が多いです。 さらなる機能が必要な場合は、RFC2879 [RFC2879] により、より詳細なメディア機能が規定されており、将来的にサポートされる可能性があります。
6.2. パレットカラー画面: color-index機能
名称: | color-index |
---|---|
対象: | @media |
値: | <integer> |
型: | range |
color-indexメディア機能は、出力デバイスのカラー参照テーブルのエントリ数を表します。 デバイスがカラー参照テーブルを使わない場合、値は0です。
@media (color-index) { … } @media (color-index >= 1) { … }
<?xml-stylesheet media="(min-color-index: 256)" href="http://www.example.com/…" ?>
6.3. モノクロ画面: monochrome機能
名称: | monochrome |
---|---|
対象: | @media |
値: | <integer> |
型: | range |
monochromeメディア機能は、モノクロフレームバッファの1ピクセルあたりのビット数を表します。 デバイスがモノクロ対応でなければ出力値は0です。
<link rel="stylesheet" media="print and (color)" href="http://…" /> <link rel="stylesheet" media="print and (monochrome)" href="http://…" />
6.4. カラー表示品質: color-gamut 機能
名称: | color-gamut |
---|---|
対象: | @media |
値: | srgb | p3 | rec2020 |
型: | discrete |
color-gamutメディア機能は、UAおよび出力デバイスがサポートするおおよその色域範囲を表します。 つまり、UAが指定された色空間の色コンテンツを受け取った場合、 出力デバイスで適切な色(または十分近い色)を表示できます。
注: このクエリはおおよその範囲を使っています。その理由はいくつかあります。 まず、ディスプレイハードウェアの差異が多く、例えばデバイスが"Rec. 2020"対応と謳っていても実際は色域が大きく狭い場合があります。 また、デバイスごとに様々な色域があり、全て列挙するのは煩雑です。 多くの場合、著者は正確な能力より「sRGBより良いか」「sRGBよりかなり良いか」だけ知りたいので、 それに応じて適切な画像(カラープロファイル付き)をユーザーに出すことができます。
- srgb
-
UAと出力デバイスがsRGB色域以上をおおよそサポートできます。
注: ほとんどのカラーディスプレイはこの種類のクエリにtrueを返すと考えられます。
- p3
- UAと出力デバイスがDCI P3色空間以上の色域をおおよそサポートできます。
- rec2020
- UAと出力デバイスがITU-R勧告BT.2020色空間以上の色域をおおよそサポートできます。
以下の表は、各色空間の主色(一次色)の色度座標を示しています。詳細は[COLORIMETRY]参照。
色空間 | 白色点 | 主色 | ||||||
---|---|---|---|---|---|---|---|---|
赤 | 緑 | 青 | ||||||
xW | yW | xR | yR | xG | yG | xB | yB | |
srgb | 0.3127 | 0.3290 | 0.640 | 0.330 | 0.300 | 0.600 | 0.150 | 0.060 |
p3 | 0.3127 | 0.3290 | 0.680 | 0.320 | 0.265 | 0.690 | 0.150 | 0.060 |
rec2020 | 0.3127 | 0.3290 | 0.708 | 0.292 | 0.170 | 0.797 | 0.131 | 0.046 |
注: 上記表だけでは色空間の全情報は分かりませんが、デバイスがそれぞれの色域をおおよそカバーしているか判断するには十分です。 sRGBについては[SRGB]、 DCI P3については[SMPTE-EG-432-1-2010]と[SMPTE-RP-431-2-2011]、 ITU-R BT.2020については[ITU-R-BT-2020-2]参照。
注: 出力デバイスの色域が十分広い場合、またはある色域が他の色域の部分集合である場合、 このメディア機能の複数値がtrueになることがあります。 そのため、(color-gamut: srgb)でベース値を設定し、(color-gamut: p3)がtrueなら上書き…といった「昇順」利用が適しています。
注: 一部出力デバイス(モノクロ画面など)はsrgb色域すらサポートできません。 そうしたデバイスはこの機能を真偽型コンテキストで否定してテストできます:not (color-gamut)。
6.5. ダイナミックレンジ: dynamic-range 機能
名称: | dynamic-range |
---|---|
対象: | @media |
値: | standard | high |
型: | discrete |
dynamic-rangeは、UAと出力デバイスがサポートする最大輝度・カラー深度・コントラスト比の組み合わせを表します。
- high
-
UAと出力デバイスがすべて以下を満たします:
注: 一部デバイスは高ダイナミックレンジ機能が常時ONでなく、起動(プログラム・ユーザー操作・コンテンツ依存など)必要です。 このメディア機能はそのモードが有効かどうかでなく、デバイスが高ダイナミックレンジ表示可能かだけ判定します。
- standard
- この値は全ての視覚デバイスに一致し、視覚機能がないデバイスには一致しません。
注: このメディア機能は複数の値が同時に一致する場合があります。 highに一致するUAはstandardにも一致します。
6.5.1. 表示のコントラスト・明るさの判定
ピーク輝度は、 LCD画面などの発光型デバイスが出せる最も明るい点、 または紙やE-inkなどの反射型デバイスで最も光を吸収しない点を指します。
注: 一部デバイスはピーク輝度を短時間または画面一部だけでしか出せません。
コントラスト比は、 システムが出せる最も明るい色と最も暗い色の輝度比です。
この仕様はこれらの品質の厳密な測定方法を規定しません。 またUAが何を高コントラスト比・高ピーク輝度とみなすかもUAに委ねます。 ただし、以下の意図に従うよう努力しなければなりません: 高ピーク輝度対応デバイスは「白より明るい」ハイライト表示可能であり、 それと同時に深い黒を出せる(全体が明るいだけのぼやけた画像でなく)場合、高コントラスト比とみなされます。
注: dynamic-rangeやvideo-dynamic-rangeの判定はUAによって異なりますが、概ね一貫した意味になる想定です。
6.6. 画面の反転色検出: inverted-colors機能
名称: | inverted-colors |
---|---|
対象: | @media |
値: | none | inverted |
型: | discrete |
inverted-colorsメディア機能は、コンテンツが通常通り表示されているか、 あるいは色が反転されているかを示します。
注: これはUAやOSが強制的に全色反転したことの指標であり、反転要求ではありません。 明暗反転テキスト切り替えなど、簡易アクセシビリティ機能提供の場合があります。 ただし、画像まで反転・影がハイライトになるなど、可読性低下という副作用があります。
- none
- 色は通常通り表示されます。
- inverted
-
表示領域内のすべてのピクセルが反転されています。
この値は、UAがコンテンツ認識型反転(画像を維持するなど)を行った場合は一致してはいけません(UAスタイルシートによる場合を除く)。
注: このメディア機能の目的は、全ピクセル反転の非コンテンツ認識型挙動の悪影響を著者が緩和できるようにすることです。 コンテンツ認識型にも対策をすると、著者の対策とUAの対策が相殺されるリスクがあります。
UAは以下のルールをUAスタイルシートに追加しなければなりません:
@media ( inverted-colors) {
img : not ( picture>img), picture, video { filter : invert ( 100 % ); }
}
@media (inverted-colors) { * { text-shadow: none !important; box-shadow: none !important; } }
7. インタラクションメディア機能
「インタラクション」メディア機能は、ユーザーがページとどのようにやりとりするかの様々な側面を反映します。
pointer: none | pointer: coarse | pointer: fine | |
---|---|---|---|
hover: none | キーボードのみの操作、順次/空間(十字キー)フォーカスナビゲーション | スマートフォン、タッチスクリーン | 基本的なスタイラスデジタイザ(Cintiq、Wacom等) |
hover: hover | Nintendo Wiiコントローラ、Kinect | マウス、タッチパッド、高度なスタイラスデジタイザ(Surface、Samsung Note、Wacom Intuos Pro等) |
pointerおよびhoverは「主要」ポインティングデバイスの特性に関係し、 any-pointerとany-hoverは利用可能な全ポインティングデバイスの特性を問い合わせるのに使えます。
注: この仕様はUAが「主要」ポインティングデバイスをどう決定するかを定義しませんが、 UAは実行環境や利用可能なポインティングデバイスの数・種類、および一般的・現在利用されているデバイスの知識を組み合わせて判断すべきと期待されています。 デバイスの主要入力がポインティングデバイスでない場合でも、補助的・使用頻度の低いポインティングデバイスがあるならUAは非ポインティングデバイスを主要扱いすることもあります(結果として'pointer: none')。 UAはユーザー環境やユーザーの操作方法の変化に応じて、主要とみなすポインティングデバイスの種類を動的に変更する場合もあります。
注: pointer、hover、any-pointer、any-hoverは、ポインティングデバイスの特性や存在の有無のみに関係し、キーボードなど非ポインティングデバイスの入力機構の有無検出には使えません。 著者は、これらの機能を問い合わせた結果にかかわらず、非ポインティングデバイス入力が存在する可能性も考慮すべきです。
7.1. ポインティングデバイスの品質: pointer機能
名称: | pointer |
---|---|
対象: | @media |
値: | none | coarse | fine |
型: | discrete |
pointerメディア機能は、マウス等のポインティングデバイスの有無と精度を問い合わせます。 複数ポインティングデバイスがある場合は、 pointerメディア機能はUAが決定した「主要」ポインティングデバイスの特性を反映します。 (すべての利用可能ポインティングデバイスの能力を問い合わせる場合はany-pointerメディア機能を参照)
- none
- デバイスの主要入力機構がポインティングデバイスを含みません。
- coarse
- 主要入力機構に精度の低いポインティングデバイスが含まれます。 例:タッチスクリーンやモーションセンサ(XboxのKinectなど)。
- fine
- 主要入力機構に精度の高いポインティングデバイスが含まれます。 例:マウス、タッチパッド、ペン型デバイス。
coarseとfineはどちらもポインティングデバイスの存在を示しますが、精度が異なります。 ズーム倍率1で隣接する小さなターゲットを確実に選択するのが困難または不可能なデバイスはcoarseに該当します。 ズーム倍率を変更してもこのメディア機能の値は変わりません。
注: UAがユーザーにズーム機能を提供する場合や、補助的なポインティングデバイスが異なる精度を持つ場合、値がcoarseでもユーザーが正確なクリックをできる場合があります。 このメディア機能は、ユーザーが絶対に正確なクリックができないことを示すものではなく、単にそれが不便であることを示します。 著者はcoarseの場合は正確なクリックを必要としない設計を心がけるべきです。
アクセシビリティの観点から、ポインティングデバイスがfineと判定できるデバイスでも、UAはcoarseやnoneを返すことがあります(ユーザーが正確な操作が困難な場合)。 また、主要ポインティングデバイスがfineでも、追加でcoarseなポインティングデバイスが利用可能な場合もあります。著者はany-pointerメディア機能でこうしたcoarseなデバイスも考慮できます。
/* 精度の低い主要ポインティングデバイスの場合はラジオボタン・チェックボックスを大きくする */ @media (pointer:coarse) { input[type="checkbox"], input[type="radio"] { min-width:30px; min-height:40px; background:transparent; } }
7.2. ホバー機能: hover機能
名称: | hover |
---|---|
対象: | @media |
値: | none | hover |
型: | discrete |
hoverメディア機能は、主要ポインティングデバイスでページ上の要素にホバーできるかどうかを問い合わせます。 デバイスに複数ポインティングデバイスがある場合は、 hoverメディア機能はUAが決定した「主要」ポインティングデバイスの特性を反映します。 (すべての利用可能ポインティングデバイスの能力を問い合わせる場合はany-hoverメディア機能を参照)
- none
-
主要ポインティングデバイスがホバー不可、またはポインティングデバイスが存在しないことを示します。
例:タッチスクリーン、基本的なペン型デバイス。
ホバー可能だが通常の使い方でそれが不便な場合もこの値に一致します。 例えば、タッチスクリーンで長押しがホバー扱いになる場合はhover: noneに一致します。
- hover
- 主要ポインティングデバイスがページ上の部分を容易にホバーできることを示します。 例:マウスや画面を物理的に指せるデバイス(Nintendo Wiiコントローラ等)。
しかし、オプションのマウスではホバー可能です。 著者は「:hover」疑似クラスが「hover:none」なデバイスで絶対一致しないと決めつけず、ホバー不要でも使えるレイアウト設計が重要です。
アクセシビリティの観点から、ホバー可能なデバイスでもUAはこのメディアクエリにhover: noneを返してホバーなしでも使いやすいレイアウトを選択することがあります。 主要入力に「hover: hover」能力があっても、ユーザーが利用できる他入力機構がホバー非対応の場合もあります。
/* ホバー可能なデバイスだけでドロップダウンメニューを使う */ @media (hover) { .menu > li {display:inline-block;} .menu ul {display:none; position:absolute;} .menu li:hover ul {display:block; list-style:none; padding:0;} /* ... */ }
7.3. 利用可能な全インタラクション機能: any-pointerとany-hover機能
名称: | any-pointer |
---|---|
対象: | @media |
値: | none | coarse | fine |
型: | discrete |
名称: | any-hover |
---|---|
対象: | @media |
値: | none | hover |
型: | discrete |
any-pointerとany-hoverはpointerとhoverと同等ですが、 ユーザーが利用可能な全てのポインティングデバイスの能力の合算に対応します。 any-pointerの場合、異なる特性のデバイスが複数あると複数値が同時一致することもあります。
any-pointerとany-hoverは、全てのポインティングデバイスがnoneに一致する場合、またはポインティングデバイスが全く存在しない場合のみnoneに一致します。
このようなTVのブラウザは、coarseがpointerおよびany-pointerの値となり、著者は大きく押しやすいクリックターゲットのレイアウトを提供できます。
ユーザーがBluetoothマウスをTVにペアリングし、たまに使う場合もありますが、これはTVの主な操作方法ではありません。pointerは依然coarseに一致し、any-pointerはcoarseとfine両方に一致します。
この時(any-pointer: fine)がtrueだからといって小さなクリックターゲットに切り替えるのは適切ではありません。 ユーザーの期待と異なる体験となり、TVの主要操作がマウスでない場合は不便です(マウスが手元にない、ソファの下に隠れている等...)。
一方、スクロールについて考えてみましょう。 正確なポインティングデバイスがなければスクロールバー操作は困難です。 (pointer: coarse)がtrueなら、著者は他の方法(スクロール可能表示)も準備できますが、(any-pointer: fine)がtrueならスクロールバーも表示、falseなら視覚的ノイズを減らすため非表示にする...といった工夫も可能です。
7.4. UA提供のナビゲーションコントロール検出: nav-controls機能
名称: | nav-controls |
---|---|
対象: | @media |
値: | none | back |
型: | discrete |
nav-controlsメディア機能は、UAがUIの一部として容易に発見できるナビゲーションコントロールを提供しているかどうかを著者が知ることを可能にします。
注: 従来のブラウザは通常このようなコントロールを提供しており、ウェブページ側で気にする必要はありませんでしたが、最近ではウェブビュー等でウェブアプリケーションが実行されることがあり、UIが十分でない場合もあります。 そのため、著者はUAが何を提供しているかを知って、容易に発見できる代替手段を自分で用意すべきか検討するのに役立ちます。
この文脈で、容易に発見できるとは、UI上で直接見えるボタンなど、ユーザーがすぐに判別できる、そのデバイスのUIで典型的なコントロールを指します。 視覚UIの場合は見えるコントロールが典型ですが、聴覚や触覚UIなら他の形態もあり得ます。 重要なのは、これはキーボードショートカットやジェスチャーではありません。これらは便利ですが、(視覚UIの場合)UAを見ただけでは発見できません。
有効な値は以下の通りです:
- none
- UAが容易に発見できるナビゲーションコントロールを持たず、特にjoint session historyで1ページ戻る操作を行うコントロールもありません。
- back
- UAはナビゲーションコントロールを提供しており、少なくとも容易に発見できるコントロール(通常「戻る」ボタン)があり、joint session historyで1ページ戻る操作を行えます。
@media ( nav-controls: back) {
#back-button {
display : none;
}
}
このメディア機能は真偽型コンテキストでも使えるため、同じ例をより短い構文で書くこともできます:
@media ( nav-controls) {
#back-button {
display : none;
}
}
注: 理論的には両者は厳密には同等ではなく、将来このメディア機能にback以外の値が追加されると、 が一致しない場合でも一致することがあります。 その場合、真偽型コンテキストでnav-controlsを使うのは誤解を招く可能性があります。 ただし、「戻る」操作は最も基本的なナビゲーションと考えられるため、CSS WGは「戻る」ボタンなしで明示的なナビコントロールだけあるUIは想定しておらず、実際にはこの問題は生じないと考えています。
容易に発見できるコントロールがアクティブかどうかは、このメディア機能の評価に影響しません。
@media (nav-controls: back) { … }
は一致する想定です。 8. ビデオ接頭辞付き機能
一部のUA(多くのテレビなど)は、映像とグラフィックを2つの異なる「プレーン」(バイプレーン)でレンダリングし、画面特性も異なります。ビデオプレーンを記述するためにvideo接頭辞付き機能セットが用意されています。
バイプレーン実装では、以下の機能についてはvideoプレーンの値を返さなければなりません:video-color-gamut、video-dynamic-range。 それ以外の機能はグラフィックプレーンの値を返します。
バイプレーンでない実装は、video接頭辞付き機能と接頭辞なし機能で同じ値を返さなければなりません。
8.1. ビデオカラー表示品質: video-color-gamut機能
名称: | video-color-gamut |
---|---|
対象: | @media |
値: | srgb | p3 | rec2020 |
型: | discrete |
video-color-gamutメディア機能は、UAおよび出力デバイスの映像プレーンがサポートするおおよその色域範囲を表します。 UAが指定された色空間のコンテンツを受け取った場合、出力デバイスは適切な色(または十分近い色)を表示できます。
値と色空間の定義はcolor-gamutと同じです。
8.2. ビデオダイナミックレンジ: video-dynamic-range機能
名称: | video-dynamic-range |
---|---|
対象: | @media |
値: | standard | high |
型: | discrete |
video-dynamic-rangeは、UAおよび出力デバイスの映像プレーンがサポートする最大輝度・カラー深度・コントラスト比の組み合わせを表します。
サポートされる値はdynamic-rangeと同じです。
9. スクリプトメディア機能
9.1. スクリプト対応: scripting機能
名称: | scripting |
---|---|
対象: | @media |
値: | none | initial-only | enabled |
型: | discrete |
scriptingメディア機能は、JavaScriptなどのスクリプト言語が現在のドキュメントでサポートされているかどうかを問い合わせるために使います。
- enabled
- UAがページのスクリプティングをサポートし、ドキュメントの存続期間中スクリプトが有効であることを示します。
- initial-only
-
UAがページのスクリプティングをサポートし、初回ページロード時のみスクリプトが有効で、その後はサポートされないことを示します。
例:印刷ページや、サーバでレンダリングしほぼ静的なページを送信するプリレンダネットワークプロキシ等。
UAがinitial-onlyを主張するための明示的な最小基準が必要か? 基準があれば著者は依存でき、スクリプトを調整できるが、閾値設定は難しい。 低すぎると著者が依存できるスクリプティング機能が実用上制約されるし、実際のUAはもっと多くサポートしている可能性もある。 高すぎると、ロード時のみスクリプトをサポートし、複雑なヒューリスティックで制限するUAを除外することになる。 例えば、保守的な定義ならインラインスクリプトの実行とDOMContentLoadedイベントの発火は含まれる。 しかしinitial-only UAが外部スクリプト(async, defer含む)読み込みやloadイベント発火も行うなら、著者がそれだけに制約される意味は薄い。 一方、外部スクリプト読み込みやloadイベント必須とすると、Opera miniのようなUAはタイムアウト等のヒューリスティックで外部スクリプト未実行になる場合もある。 [Issue #503]
- none
- UAがこのドキュメントでスクリプトを実行しないこと(スクリプト言語非対応、または現在のドキュメントで無効)を示します。
一部のUAはスクリプト単位やドメイン単位でスクリプト対応を個別に切り替え可能で、特定のドキュメントで一部スクリプトのみ実行できる場合があります。 scriptingメディア機能は、どのスクリプトが実行可能かの細かい検出はできません。 この場合、ドキュメントと同じドメイン由来のスクリプトが実行可能なら値はenabledまたはinitial-only、 実行できなければnoneにすべきです。
注: 将来のCSSレベルでは、どのスクリプトが実行可能かの細かい検出が追加される可能性があります。
10. カスタムメディアクエリ
メディアクエリを使ったドキュメント設計時、同じメディアクエリが複数箇所(複数の@import文など)で使われる場合があります。 同じメディアクエリを何度も繰り返すのは編集ミスの元で、著者が変更する際にすべて同じように修正しなければならず、CSSのバグ原因になります。
この問題を緩和するため、本仕様ではカスタムメディアクエリの定義方法を提供します。 これは単純な名前付きのエイリアスで、より長く複雑なメディアクエリに置き換えられます。 このように、複数箇所で使うメディアクエリをカスタムメディアクエリとして割り当てれば、どこでも使え、編集時は1行だけ修正すれば済みます。
カスタムメディアクエリは@custom-media規則で定義します:
@custom-media = @custom-media <extension-name> [ <media-query-list> | true | false ] ;
<extension-name>はmedia featureで使うことができます。 必ず真偽型コンテキストで使う必要があり、通常や範囲コンテキストで使うと構文エラーです。 <media-query-list>が与えられた場合、 カスタムメディアクエリは、その<media-query-list>がtrueならtrue、そうでなければfalseになります。 trueやfalseが指定された場合は、それぞれtrue/falseになります。
/* --modern は color または hover 対応のモダンデバイスを対象 */
@custom-media --modern ( color), ( hover);
@media ( --modern) and ( width > 1024 px ) {
.a { color : green; }
}
これは以下と同等です:
@media (( color) or ( hover)) and ( width > 1024 px ) {
.a { color : green; }
}
次のように処理するのは誤りです:
@media ( color), ( hover) and ( width > 1024 px ) {
.a { color : green; }
}
@custom-media規則は他のカスタムメディアクエリを参照できます。 ただしループは禁止であり、カスタムメディアクエリは自分自身や直接・間接的に参照する他のカスタムメディアクエリで定義してはいけません。 ループとなる定義をした場合、そのループ内のカスタムメディアクエリは全て定義失敗となります。
複数の@custom-media規則が同じ<extension-name>を宣言した場合、真偽値は最後のものだけを使い、それ以前の同名宣言は無視します。
注: エラー処理上、未定義のmedia featureはfalse評価のmedia featureとは異なります。 詳しくはMedia Queries 4 § 3.2 エラー処理参照。
@custom-media --narrow-window (max-width: 30em); @media (--narrow-window) { /* narrow window styles */ } @media (--narrow-window) and (script) { /* special styles for when script is allowed */ } /* etc */
10.1. スクリプトベースのカスタムメディアクエリ
<script> CSS.customMedia.set('--foo', 5); </script> <style> @media (_foo: 5) { ... } @media (_foo < 10) { ... } </style>
11. ユーザー設定メディア機能
11.1. ページ上の動きを減らしたい希望の検出: prefers-reduced-motion 機能
名称: | prefers-reduced-motion |
---|---|
対象: | @media |
値: | no-preference | reduce |
型: | discrete |
prefers-reduced-motion メディア機能は、ユーザーがシステムにアニメーションや動きを最小限にするよう要求したかどうかを検出するために使われます。
- no-preference
- ユーザーがシステムに特に希望を示していない場合を示します。このキーワード値は真偽型コンテキストではfalseとなります。
- reduce
- ユーザーが動きやアニメーションを最小限にしたいとシステムに通知した場合を示します。できる限り不要な動きを無くすことを好みます。
11.2. ページ上の透明度低減希望の検出: prefers-reduced-transparency 機能
名称: | prefers-reduced-transparency |
---|---|
対象: | @media |
値: | no-preference | reduce |
型: | discrete |
prefers-reduced-transparency メディア機能は、ユーザーがシステムに透明・半透明なレイヤー効果を最小限にするよう要求したかどうかを検出するために使われます。
- no-preference
- ユーザーがシステムに特に希望を示していない場合を示します。このキーワード値は真偽型コンテキストではfalseとなります。
- reduce
- ユーザーが透明・半透明レイヤー効果を最小限にしたいとシステムに通知した場合を示します。
パターン塗りや背景などの希望とどのように相互作用するか?これらは透明度ではないが形状認識の妨げにもなる。
11.3. ページ要素の色コントラスト増減希望の検出: prefers-contrast 機能
名称: | prefers-contrast |
---|---|
対象: | @media |
値: | no-preference | less | more | custom |
型: | discrete |
prefers-contrast メディア機能は、ユーザーがページに対してより強い/弱いコントラストを要求したかどうかを検出します。 例えば隣接する色のコントラスト比を調整したり、要素の視覚的な強調度(境界線など)を調整することで対応できます。
- no-preference
- ユーザーがシステムに特に希望を示していない場合を示します。このキーワード値は真偽型コンテキストではfalseとなります。
- less
- ユーザーがコントラストが低いインターフェースを希望したことを示します。
- more
- ユーザーがコントラストが高いインターフェースを希望したことを示します。
- custom
-
ユーザーが特定の色セットを希望しているが、そのコントラストが「more」や「less」には該当しない場合を示します。
注: この値は、ユーザーが特に高い/低いコントラストでないパレットを選んだ強制色モード利用時にも一致します。 詳しくは§ 11.4 強制色モードの検出: forced-colors機能参照。
何も指定せず
で高コントラストスタイルを適用するのは誤りかつユーザーに不親切です。逆希望の人にも強制されてしまいます。
ただし、高低両方のコントラスト希望に対して視覚的なノイズや色の複雑さを減らす対応(背景画像を単色に置換、装飾グラデーションや境界画像・ボックスシャドウを単純な枠線に変更等)は一般的です。
その場合は
でmoreやlessを指定せずに使い、prefers-contrast: customも含めて、prefers-contrast: moreやprefers-contrast: lessと同様に真偽型コンテキストでtrueになるので、強制色モードでも恩恵があります(高低どちらでもない色でも)。
強制色モードでは色数が減る分、ページの視覚的な単純化が望ましいためです。
- コントラストの低い背景では文字が読みにくいので、より高いコントラストを希望するユーザーが多い。
- 片頭痛持ちの人は強いコントラストページが目に痛く、低コントラストを好むことがある。
- ディスレクシアの人の中には高コントラスト文字が読みづらく、文字が光ったりきらめいたように感じて低コントラストの方が快適な場合もある。
- 環境要因(照明など)でコントラスト希望が変わることもある。§ 11.7 ユーザー設定の自動処理も参照。
11.4. 強制色モードの検出: forced-colors 機能
名称: | forced-colors |
---|---|
対象: | @media |
値: | none | active |
型: | discrete |
- active
-
強制色モードが有効であることを示します。
UAはユーザーが選択した限定パレットをページに強制し、CSSのシステム色キーワード経由でそのパレットを著者に提供します。
詳しくはCSS Color Adjust § 3
強制色パレット参照。
これは必ずしも高コントラストの希望を意味しません。 色はユーザーの希望に合わせて強制調整されますが、その希望は高コントラスト・低コントラスト・どちらでもない場合があります。
forced-colors: active時、UAはユーザーが選んだ強制パレットが特に高/低コントラストならprefers-contrast: moreまたはprefers-contrast: lessを一致させ、そうでなければprefers-contrast: customを一致させるべきです。
同様に、強制パレットがprefers-color-schemeで記述されたいずれかの色スキームに該当するなら、それも一致させるべきです。
- none
- 強制色モードは有効でありません。
11.5. 明・暗カラースキーム希望の検出: prefers-color-scheme 機能
名称: | prefers-color-scheme |
---|---|
対象: | @media |
値: | light | dark |
型: | discrete |
prefers-color-scheme メディア機能は、ユーザーがページに明るい/暗いカラーテーマを希望しているかどうかを反映します。
- light
- ユーザーが明るいテーマ(明るい背景に暗い文字)を希望した場合、または特に希望がない場合(「webデフォルト」として明るいテーマになる)。
- dark
- ユーザーが暗いテーマ(暗い背景に明るい文字)を希望した場合。
注: この機能の値は将来的に拡張される可能性があります(明るいカラースキームへの強い希望や「セピア」など他のカラースキーム希望など)。そのため、もっとも将来互換性の高い使い方は否定形で書くこと((prefers-color-scheme: dark)や(not (prefers-color-scheme: dark)))です。これにより新しい値が追加されても必ずどちらかのスタイルブロックに該当します。
ユーザーが希望を表明する方法は様々で、OSのシステム設定やUA独自の設定などがあります。
注: ユーザー希望は媒体によっても異なる場合があります。例えば、発光画面では暗いテーマを好み、印刷時は明るいテーマを好む(インク節約や、白紙に黒文字の方が読みやすいため)。UAはこうした文脈も考慮し、prefers-color-schemeが適切に反映されるようにすべきです。
もし将来UAが「希望なし」と「本当に明るい表示を希望」の違いを表現したい場合はCSSWGまでご連絡ください。
11.6. ページ読み込み時のデータ使用量を減らしたい希望の検出: prefers-reduced-data 機能
この機能は指紋化の望ましくない要素となる可能性があり、低所得・データ制限環境へのバイアスにつながる懸念があります。この仕様にはプライバシーとセキュリティのセクションを追加し、この懸念に対応すべきです。[Issue #4832]
名称: | prefers-reduced-data |
---|---|
対象: | @media |
値: | no-preference | reduce |
型: | discrete |
prefers-reduced-data メディア機能は、ユーザーがページ描画時により少ないデータを使う代替コンテンツを希望しているかどうかを検出します。
- no-preference
- ユーザーがシステムに特に希望を示していない場合を示します。このキーワード値は真偽型コンテキストではfalseとなります。
- reduce
- ユーザーが軽量な代替コンテンツを希望した場合を示します。
ユーザーが希望を表明する方法は様々で、OSのシステム設定やUA独自の設定などがあります。
注: UAは、Save-Data HTTPリクエストヘッダーを設定する際と同じユーザー/システム設定に基づいてこの値を設定することもできます。
.image { background-image: url("images/heavy.jpg"); } @media (prefers-reduced-data: reduce) { /* Save-Data: On */ .image { background-image: url("images/light.jpg"); } }
11.7. ユーザー設定の自動処理
UAは、ユーザーが明示的に希望を指定できる設定を持つ場合も、OSの設定に基づいて判断する場合もあります。 また、UAはデバイスや環境等の知識からユーザー希望を自動推定することもできます。 その場合は、自動推定された希望からユーザーがオプトアウトまたは上書きできる手段も用意することが推奨されます。
例えば、液晶ディスプレイは明るい環境下だと白飛びして非常に読みにくくなります。 こうした画面と照度センサーを持つデバイスでは、読みにくい条件を検知した場合prefers-contrastをmoreに自動切り替えできます。 電子ペーパー(E-ink)ディスプレイ搭載デバイスでは、明るい屋外でも可読性が保たれるため、このような自動調整は行いません。
逆に、発光型ディスプレイ(LCD、OLED等)+照度センサー搭載デバイスでは、暗い環境でコントラストや輝度が高すぎると読みにくいので、prefers-contrastをless、prefers-color-schemeをdarkに自動切り替えることができます。
付録A: 廃止予定メディア機能
以下のメディア機能は廃止予定です。 後方互換のため残されていますが、新しいスタイルシートには使わないでください。著者は使用禁止。UAは指定通りサポートしなければなりません。
ビューポート(またはページメディアの場合はページボックス)のサイズを問い合わせる場合は、width、height、aspect-ratio メディア機能を使うべきで、device-width、device-height、device-aspect-ratioは、デバイスの物理サイズを参照しており、レイアウト対象の領域サイズとは無関係です。device-* メディア機能はモバイルデバイス検出の代用にも使われることがありますが、目的に合ったメディア機能を使うべきです。
device-width
名称: | device-width |
---|---|
対象: | @media |
値: | <length> |
型: | range |
device-width メディア機能は、出力デバイスのレンダリング面の幅を表します。 連続メディアの場合はWeb公開画面領域の幅、 ページメディアの場合はページシートサイズの幅です。
@media (device-width < 800px) { … }
上記例では、スタイルシートは長さが800px未満の画面にのみ適用されます。 px単位は論理単位で、単位セクションで説明しています。
注: デバイスが縦横両向き利用可能な場合、device-*メディア機能は現在の向きを反映します。
device-height
名称: | device-height |
---|---|
対象: | @media |
値: | <length> |
型: | range |
device-height メディア機能は、出力デバイスのレンダリング面の高さを表します。 連続メディアの場合はWeb公開画面領域の高さ、 ページメディアの場合はページシートサイズの高さです。
<link rel="stylesheet" media="(device-height > 600px)" />
上記例では、スタイルシートは600pxより縦に長い画面にのみ適用されます。 px単位の定義はCSSの他の箇所と同じです。
device-aspect-ratio
名称: | device-aspect-ratio |
---|---|
対象: | @media |
値: | <ratio> |
型: | range |
'device-aspect-ratio' メディア機能は、device-widthメディア機能の値を 'device-height' メディア機能の値で割った比率として定義されています。
@media (device-aspect-ratio: 16/9) { … } @media (device-aspect-ratio: 32/18) { … } @media (device-aspect-ratio: 1280/720) { … } @media (device-aspect-ratio: 2560/1440) { … }
付録B: プライバシーとセキュリティの考慮事項
このセクションは規範的ではありません。
display-mode メディア機能は、オリジンがユーザーのローカル環境の側面へアクセス可能にし、特にアプリケーションマニフェスト displayメンバー [APPMANIFEST]と組み合わせると、UAのネイティブUIに一定の制御権限を与えます。 CSSメディアクエリ経由でスクリプトはウェブアプリの表示モードを知ることができます。 攻撃者は、アプリがフルスクリーン表示されていることを悪用して他アプリのUIを模倣することも可能です。
変更点
このセクションは規範的ではありません。
2020-07-31 ワーキングドラフト以降の変更点
編集上の変更や軽微な明確化に加え、以下の変更・追加が2020-07-31 ワーキングドラフト以降にこのモジュールへ加えられました:
-
display-mode を [APPMANIFEST]から採用。 (Issue 6343参照)
-
バイプレーン実装においてビデオプレーンの幾何情報を問い合わせるための media features(
video-width
、video-height
、video-resolution
)を削除。 (Issue 5044参照) -
prefers-contrast の値
high
とlow
を more および prefers-contrast less に名称変更。 (Issue 2943参照) -
prefers-contrast と forced-colors の連携を再設計。
prefers-contrast: forced
を廃止し、custom を導入。 (Issue 5433、 Issue 6036参照) -
horizontal-viewport-segments と vertical-viewport-segments メディア機能を追加。 (Issue 6234参照)
-
nav-controls メディア機能を追加。 (Issue 6234参照)
-
dynamic-range の複数値を同時に一致可能にした。 (Issue 6793参照)
2020-07-15 ワーキングドラフト以降の変更点
以下の追加が2020-07-15 ワーキングドラフト以降にこのモジュールへ加えられました:
- inverted-colors に関するUAスタイルシートルール追加。
- prefers-contrast: forced 値追加。
-
light-level
メディア機能を削除(prefers-contrast・prefers-color-schemeで代替可能)。UAがこれらに自動対応する例も追加。
2020-06-03 ワーキングドラフト以降の変更点
以下の追加が2020-06-03 ワーキングドラフト以降にこのモジュールへ加えられました:
- レベル4の内容を本仕様に統合(以前はレベル4との差分管理)。
- 編集上の微調整。
2020-03-18 ワーキングドラフト以降の変更点
以下の追加が2020-03-18 ワーキングドラフト以降にこのモジュールへ加えられました:
- video-* および dynamic-range メディア機能を追加
- 'prefers-color-scheme: no-preference' を削除
最初のパブリックワーキングドラフト以降の変更点
以下の追加が2020-03-03 最初のパブリックワーキングドラフト以降にこのモジュールへ加えられました:
- 既知の課題をドキュメント内でインライン表示
Media Queries Level 4 以降の変更点
以下の追加がこのモジュールの最初のパブリックワーキングドラフトに対して、Media Queries Level 4以降に加えられました:
-
light-level
、inverted-colors、カスタムメディアクエリの節をレベル4初期ドラフトから復活。 - prefers-reduced-motion、prefers-reduced-transparency、prefers-contrast、prefers-color-scheme、 および forced-colors メディア機能を追加。
謝辞
このセクションは規範的ではありません。
本仕様はW3Cワーキンググループ(Cascading Style Sheets)の成果物です。
以下の方々からのコメントにより本仕様が改善されました: Adam Argyle, Amelia Bellamy-Royds, Andreas Lind, Andres Galante, Arve Bersvendsen, Björn Höhrmann, Chen Hui Jing, Chris Lilley, Chris Rebert, Christian Biesinger, Christoph Päper, Elika J. Etemad (fantasai), Emilio Cobos Álvarez, François Remy, Frédéric Wang, Fuqiao Xue, Greg Whitworth, Ian Pouncey, James Craig, Jay Harris, Jinfeng Ma, Kivi Shapiro, L. David Baron, Masataka Yakura, Matt Giuca, Melinda Grant, Michael Smith, Nicholas C. Zakas Patrick H. Lauke, Philipp Hoschka, Rick Byers, Rijk van Geijtenbeek, Rik Cabanier, Roger Gimson, Rossen Atanassov, Sam Sneddon, Sigurd Lerstad, Simon Kissane, Simon Pieters, Steven Pemberton, Susan Lesch, Tantek Çelik, Thomas Wisniewski, Vi Nguyen, Xidorn Quan, Yves Lafon, akklesed, そして 張俊芝 が本仕様の改善に貢献しました。