Media Queries レベル5

W3C 作業草案,

この文書の詳細
このバージョン:
https://www.w3.org/TR/2021/WD-mediaqueries-5-20211218/
最新公開バージョン:
https://www.w3.org/TR/mediaqueries-5/
編集者草案:
https://drafts.csswg.org/mediaqueries-5/
以前のバージョン:
履歴:
https://www.w3.org/standards/history/mediaqueries-5
フィードバック:
CSSWG イシューレポジトリ
仕様内インライン
編集者:
Dean Jackson (Apple)
Florian Rivoal (招待専門家)
Tab Atkins Jr. (Google)
Daniel Libby (Microsoft)
この仕様への編集提案:
GitHub エディター

要約

Media Queriesは、ドキュメントのレンダリングとは独立して、ユーザーエージェントや表示デバイスの値や機能をテスト・問い合わせることを可能にします。CSSの@media規則でドキュメントに条件付きでスタイルを適用したり、HTMLやJavaScriptなど様々なコンテキストや言語で使用されます。

Media Queries Level 5は、メディアクエリ・メディアタイプ・メディア機能の仕組みと構文を定義します。これはMedia Queries Level 4で定義された機能を拡張・置き換えます。

CSSは、構造化ドキュメント(HTMLやXMLなど)の画面・紙などへのレンダリング方法を記述するための言語です。

この文書のステータス

このセクションは文書公開時点のステータスを説明します。 最新のW3C出版物一覧とこの技術レポートの最新改訂はW3C技術レポートインデックス https://www.w3.org/TR/で確認できます。

この文書はCSS作業グループにより、Recommendation trackを利用して作業草案として公開されました。 作業草案としての公開は、W3Cおよびその会員による承認を意味するものではありません。

この文書はドラフトであり、随時更新・置換・廃止される可能性があります。 進行中の作業以外のものとしてこの文書を引用するのは不適切です。

フィードバックはGitHubでイシュー提出(推奨)でお願いします。その際、タイトルに仕様コード「mediaqueries」を含めてください(例: “[mediaqueries] …コメント要約…”)。 すべてのイシューとコメントはアーカイブされます。 または、(アーカイブあり) 公開メーリングリスト www-style@w3.org へ送信も可能です。

この文書は2021年11月2日付W3Cプロセス文書に従い管理されています。

この文書はW3C特許ポリシーに基づいて運用されるグループによって作成されました。 W3Cはグループ成果物に関連してなされた特許開示の公開リストを管理しています。 そのページには特許開示の方法も記載されています。 特許に関する実際の知識を有し、その特許がEssential Claim(s)を含むと考える者は、W3C特許ポリシー第6節に従い情報を開示しなければなりません。

以下の機能は「at-risk」(リスクあり)であり、CR期間中に削除される可能性があります:

“At-risk”はW3Cプロセスの専門用語であり、必ずしも機能が削除や延期の危険があることを意味するわけではありません。WGが機能の相互運用性実装にタイムリーな困難があると考えている場合に使い、こうしておくことでProposed Rec移行時に必要に応じて機能を削除できるようになっています(まず機能なしのCandidate Recを公開する必要がありません)。

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規則でこの機能を発展・拡張し、個別機能の値を問い合わせる能力を追加しました:

CSSスタイルシート内で、特定のメディアタイプ向けにセクションを宣言できます:
@media screen {
  * { font-family: sans-serif }
}

同様に、メディアクエリに基づいてスタイルシートを条件付きでインポートできます:

@import "print-styles.css" print;

メディアクエリは、HTML、XHTML、XML [xml-stylesheet]、およびCSSの@importや@media規則で利用できます。

同じ例をHTML、XHTML、XML、@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個以上のメディア機能からなります:

media condition only not media type and media condition

メディアクエリは真偽値を返す論理式です。 メディアクエリがtrueになる条件:

このセクションでのメディアクエリに関する記述は構文セクションが順守されることを前提とします。 構文に準拠しないメディアクエリについては§ 3.2 エラー処理で扱います。 すなわち、構文がこのセクションの要件より優先されます。

HTMLで書かれた簡単な例:
<link rel="stylesheet" media="screen and (color)" href="example.css" />

この例は、特定のスタイルシート(example.css)が、特定のメディアタイプ(screen)かつ「カラー画面」の機能を持つデバイスに適用されることを示します。

同じメディアクエリをCSSの@import規則で書くと:

@import url(example.css) screen and (color);

ユーザーエージェントは、認識できるユーザー環境の変化(例:デバイスがランドスケープからポートレートに切り替わる等)に応じてメディアクエリを再評価し、 それらのメディアクエリに依存する構造の挙動を適切に変更しなければなりません。

他の機能が明示的にメディアクエリ解決に影響すると指定しない限り、式の評価のためにスタイルシートを適用する必要はありません。

2.1. メディアクエリの組み合わせ

複数のメディアクエリは、カンマ区切りでメディアクエリリストとして組み合わせることができます。

media query ,

メディアクエリリストは、その構成要素のいずれかメディアクエリがtrueの場合にtrueとなり、 構成要素のメディアクエリすべてfalseの場合のみfalseになります。

例えば、次のメディアクエリリストは、 メディアタイプscreenでカラー対応デバイスまたはメディアタイプprojectionでカラー対応デバイスの場合にtrueとなります:
@media screen and (color), projection and (color) { … }

空のメディアクエリリストはtrueと評価されます。

例えば、これらは同等です:
@media all { … }
@media { … }

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属性用に定義されました。

しかし、メディアタイプだけでは、異なるスタイリングが必要なデバイスを区別する手段として不十分と判明しました。 もともと区別が明確だったカテゴリ(screenhandheldなど)は、近年その境界が大きく曖昧になりました。 他にもttytvなどは、通常の高機能モニターとは異なる有用な違いを示すため、別スタイリングの対象として有用ですが、 メディアタイプが互いに排他的に定義されているため、現実的な使い方が難しくなっています。 代わりに、こうした排他的な側面はmedia feature(例:gridscan)で表現する方が適しています。

このため、メディアタイプは、メディアクエリで以下のものが定義されています:

all
すべてのデバイスに一致します。
print
プリンター、および印刷表示を再現するためのデバイス(例:ウェブブラウザの「印刷プレビュー」)に一致します。
screen
printに一致しないすべてのデバイスに一致します。

加えて、以下の非推奨メディアタイプも定義されています。 著者はこれらのメディアタイプを使用しないでください。 代わりに、対象デバイスの特徴をより適切に表すメディア機能を選択するのがおすすめです。

ユーザーエージェントは、以下のメディアタイプを有効として認識しなければなりませんが、何にも一致しないようにしなければなりません。

注: 今後すべてのメディアタイプは順次非推奨となる見込みであり、 重要な違いを捉える適切なメディア機能が定義され次第置き換えられる予定です。

2.4. メディア機能

メディア機能は、メディアタイプよりも細かい粒度で、ユーザーエージェントや表示デバイスの特定の機能をテストします。

構文的には、メディア機能はCSSプロパティに似ています: 機能名、コロン、テストする値で構成されます。 また、機能名のみで真偽型(ブール型)として書いたり、比較演算子を使った範囲型として書くこともできます。

( feature name : feature value feature name range form (see below) )

ただし、プロパティとメディア機能にはいくつか重要な違いがあります:

メディア機能がUAの動作するデバイス上に存在しない概念を参照した場合(例:音声UAに「width」の概念はない)、 メディア機能は常にfalseとなります。

device-aspect-ratioメディア機能は視覚デバイスのみ適用されます。speechデバイスでは、device-aspect-ratioを含む式は常に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です。

一方、(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)と等価です。

数値型メディア機能(例:width)は真偽型コンテキストで評価しても有用性はほぼありません。 なぜなら、値がほぼ常にゼロより大きいからです。 一方、colorのようにゼロ値が意味を持つものもあり、(color)(color > 0)と同じで、デバイスが色表示可能かどうかを判定します。
キーワード型メディア機能のうち、真偽型コンテキストで意味を持つものもあります。

例えば、(pointer)は便利で、pointerにはポインティングデバイスが一切ないことを示すnone値があります。 一方、(scan)は「false」を意味する値がないため、常にtrueかfalseです(デバイスに適用可能かによる)。

2.4.3. 範囲コンテキストでのメディア機能評価

「range」型メディア機能は、値に順序性があることを利用し、通常の数学比較演算子を使う範囲コンテキストとして書くこともできます:

( feature name/value > <= < = >= feature value/name value < <= feature name < <= value value > >= feature name > >= value )

注: この構文はMediaqueries Level 4で新しく導入されたため、現時点ではmin-/max-接頭辞ほど広くサポートされていません。

基本形は、機能名、比較演算子、値で構成され、関係が成り立てばtrueとなります。

例:(height > 600px)(または(600px < height))は、ビューポートの高さが600pxより大きい場合trueです。

機能名が2つの値比較の間に入る形は、両方の比較がtrueならtrueを返します。

例:(400px < width < 1000px)は、ビューポートの幅が400pxより大きく1000px未満のときtrueです(両端値は含みません)。

「range」型メディア機能の中には負の範囲でfalseとなるものもあります。 これは、負の値が有効でパースされるべきであり、 メディア機能が負値と等しい・より小さい・以下かどうかを判定する場合は必ずfalseとなることを意味します。 負値より大きい・以上かどうかは、関係が成り立てばtrueです。

注: 負値をパース時に却下した場合は、エラー処理規則によりunknown扱いになります。 しかし実際は、デバイスのresolution-300dpiかどうかは「不明」ではなくfalseです。 同様に、視覚デバイスならwidth-200pxより大きいことが確定しています。 このルールはUAの直感的な動作と一致させるためのものです。

次の例はいずれも全ての視覚デバイスで背景が緑色になります:
@media not (width <= -100px) {
  body { background: green; }
}
@media (height > -100px) {
  body { background: green; }
}
@media not (resolution: -300dpi) {
  body { background: green; }
}
この挙動はMedia Queries Level 3 [MEDIAQUERIES-3]との動作変更です。 以前はこれらのプロパティで負値を使うと構文エラーになりました。 Level 3では、構文エラー(禁止値含む)はメディアクエリ全体をfalse扱いにしましたが、本レベルではunknown扱いとなります。 Level 3からアップデートする実装は、§ 2.5 メディア機能の組み合わせで定義されたより豊かな構文をサポートする際、負値の扱いも必ず変更し、意図しない意味論を導入しないよう注意してください。

2.4.4. 範囲型機能で「min-」「max-」接頭辞を使う方法

上記のように「range」型メディア機能を範囲コンテキストで評価する代わりに、 通常のメディア機能として、 機能名に「min-」または「max-」接頭辞を付けて記述できます。

これは範囲コンテキストで機能を評価するのと同等です。具体的には:

注: 「min-」や「max-」は値を含む範囲比較に相当するため、状況によっては制約が生じます。

例えば、 ビューポート幅のブレークポイントでスタイルを分けたい著者は、「min-」「max-」を使う場合、比較値をずらして両クエリが同時にtrueにならないようにします。 ブレークポイントが320pxだとすると、著者は概念的に次のように使います:
@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-grid: 1)は無効です。 gridは「discrete」メディア機能なので、接頭辞を受け付けません。 (grid メディア機能は数値型に見えても、01の値しか受け付けません。)

min/max接頭辞付きメディア機能真偽型コンテキストで評価するのは無効で、構文エラーとなります。

2.5. メディア機能の組み合わせ

複数のメディア機能を、完全なブール代数(not, and, or)を使ってメディア条件として組み合わせることができます。

andornotを同じ「レベル」で混在させるのは無効です。 例:(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>生成式には、キーワードonlynotandorは含まれません。

「<」や「>」<delim-token>の後ろに「=」<delim-token>がある場合、間に空白は許されません。

注: notandorキーワードの後ろに「(」文字が続く場合は空白必須です。 空白なしだと<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」として扱われ、一致しません。

メディアクエリは「true」「false」「unknown」の三値ロジックを使います。 具体的にはKleeneの三値論理です。 この論理では「unknown」は「trueか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>は一致しないものとして扱います。

例:メディアクエリunknownはfalseです。 unknownは未知のメディアタイプだからです。

ただしnot unknownはtrueになります。notでfalseなメディアタイプが反転されるためです。

一部キーワードは<media-type>として許可されていないため、パースが完全に失敗します: メディアクエリor and (color)はパース時にnot allに変換され、 orを未知のメディアタイプと扱うのではありません。

未知の<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に変換されます。

メディアクエリ(color:20example)colorメディア機能に未知の値を指定しているため、not allに変換されます。
メディアクエリはホスト言語のパース規則にも従います。 例として次のCSSスニペットを見てください:
@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]で説明)。

<length>§ 1.3 単位に従い解釈されます。

width負の範囲でfalseです。

例:このメディアクエリは25cmより広い印刷出力でスタイルシートを使用することを意味します:
<link rel="stylesheet" media="print and (min-width: 25cm)" href="http://…" />
このメディアクエリは、ビューポート (ドキュメントがレンダリングされる画面/紙の部分) の幅が400〜700ピクセルのデバイスでスタイルシートを使うことを意味します:
@media (400px <= width <= 700px) { … }
このメディアクエリは、ビューポートの幅が20emより大きい場合にスタイルシートを使うことを意味します。
@media (min-width: 20em) { … }

em値はfont-sizeの初期値に対して相対的です。

4.2. 高さ: height機能

名称: height
対象: @media
値: <length>
型: range

heightメディア機能は、出力デバイスの対象表示領域の高さを表します。 連続メディアの場合は、ビューポートの高さ(レンダリングされたスクロールバーのサイズも含む)、 ページメディアの場合はページボックスの高さです。

<length>§ 1.3 単位に従い解釈されます。

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
それ以外の場合、orientationlandscapeです。
次のメディアクエリは「portrait」向きをテストします。 たとえば、縦に持ったスマートフォンなどです。
@media (orientation:portrait) { … }

4.5. ブロック軸のオーバーフロー: overflow-block 機能

名称: overflow-block
対象: @media
値: none | scroll | paged
型: discrete

overflow-blockメディア機能は、 ブロック軸方向で 初期包含ブロックからコンテンツがあふれた場合のデバイスの挙動を示します。

none
ブロック軸方向でオーバーフローする場合、 何の表示手段もありません。あふれたコンテンツは表示されません。 例:ビルボード
scroll
ブロック軸方向の オーバーフローしたコンテンツは、ユーザーがスクロールできることで表示されます。 例:コンピュータ画面
paged
コンテンツは個々のページに分割されます。 ブロック軸方向で 1ページからあふれたコンテンツは次ページに表示されます。 例:プリンター、電子書籍リーダー

nonescroll に一致するメディアは連続メディア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です。

このメディアクエリは、横並びでちょうど2つのセグメントを持つビューポートを検出します。
@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 modefullscreenであっても、 fullscreenElementnullを返し、 fullscreenEnabledfalseを返すことがあります。

fullscreen 表示モードは、CSSの:fullscreen疑似クラスとも直接関連しません。 :fullscreenは、要素がフルスクリーン要素スタックに入った時のみ一致します。 ただし、Fullscreen APIrequestFullscreen() を呼び出すと、ブラウザがOSレベルのフルスクリーンモードに入る場合があり、 その場合:fullscreen(display-mode: fullscreen)の両方が一致します。

一部のプラットフォームでは、ユーザーやWeb Application ManifestFullscreen APIを使わずにウェブアプリをフルスクリーンにできます。 この場合、:fullscreen疑似クラスは一致しませんが、 (display-mode: fullscreen)は一致します。 以下はCSSコード例です:
/* ビューポートがフルスクリーンの時に適用 */
@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になります。)

このメディアクエリは「高解像度」画面(ハードウェアピクセル/CSS px比が2以上)を検出します:
@media (resolution >= 2dppx)
このメディアクエリは、解像度がCSS inあたり300ドットより大きいデバイスでスタイルシートを使用することを意味します:
@media print and (min-resolution: 300dpi) { … }

このメディアクエリは、CSS cm単位を使った場合と等価です:

@media print and (min-resolution: 118dpcm) { … }
<resolution>は 物理長単位あたりのデバイスピクセル数ではなく、CSS単位あたりのピクセル数です。 このマッピングはユーザーエージェントが行い、必ず知ることができます。

ユーザーエージェントが物理ピクセルのジオメトリを知らない場合、または知っていて物理ピクセルがほぼ正方であれば、 各軸でCSSピクセルあたりのデバイスピクセル数に違いはありません。 そのため、縦横解像度の違いはありません。

一方、UAが軸ごとに異なるマッピングを選ぶ場合は、物理ピクセルが正方でないことへの対応です。どうUAがその情報を得るかは範囲外ですが、必要情報を得ているなら、デバイスを90度回転した場合などマッピングも反転可能です。

5.2. 表示タイプ: scan機能

名称: scan
対象: @media
値: interlace | progressive
型: discrete

scanメディア機能は、出力デバイスの走査方式を示します。

interlace
CRTや一部プラズマTV画面は「インターレース」描画を使用します。 映像フレームが「偶数行」と「奇数行」を交互に指定し、脳の自動補正効果で滑らかな動きを生み出します。 これにより高FPS放送を帯域半分でシミュレートできました。

インターレース画面表示時は、画面上を高速に動くオブジェクトは「櫛形」現象を避けるため控えめにし、細かいディテールは1px以上としてください(“twitter”を防ぐため)。

progressive
「プログレッシブ」描画を使う画面は全体を一度に描画するため、特別な対応は不要です。

ほとんどの現代的な画面、そしてすべてのコンピュータ画面はプログレッシブ描画です。

例えば、セリフ体フォントの「足」はインターレースデバイスで“twitter”を起こしやすい微小特徴です。 scanメディア機能で検出し、 “twitter”の少ない代替フォントを使うことができます:
@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>型はレガシー目的のみ存在します。 新規設計なら値に正しいキーワードを使ったはずです。

コンソール画面が狭い場合を検出する例:
@media (grid) and (max-width: 15em) { … }

注: 現時点の実装例はすべて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です。

例:次の2つのメディアクエリは、スタイルシートがすべてのカラー対応デバイスに適用されることを示します:
@media (color) { … }
@media (min-color: 1) { … }
このメディアクエリは、スタイルシートが1成分あたり8ビット以上のカラー対応デバイスに適用されることを示します:
@media (color >= 8) { … }

異なるカラー成分が異なるビット数で表現される場合は、最小値を使用します。

例えば、8ビットカラーシステムが 赤成分3ビット、緑成分3ビット、青成分2ビットで表現されている場合、 colorメディア機能の値は2となります。

インデックスカラー対応デバイスでは、参照テーブル内の各カラー成分の最小ビット数を使います。

注: この機能で記述できるのはカラー能力の表面的なレベルのみです。color-gamutの方が著者のニーズに合う場合が多いです。 さらなる機能が必要な場合は、RFC2879 [RFC2879] により、より詳細なメディア機能が規定されており、将来的にサポートされる可能性があります。

6.2. パレットカラー画面: color-index機能

名称: color-index
対象: @media
値: <integer>
型: range

color-indexメディア機能は、出力デバイスのカラー参照テーブルのエントリ数を表します。 デバイスがカラー参照テーブルを使わない場合、値は0です。

color-index負の範囲でfalseです。

例:次の2つの方法は、スタイルシートがすべてのカラーインデックスデバイスに適用されることを示します:
@media (color-index) { … }
@media (color-index >= 1) { … }
このメディアクエリは、256以上のエントリを持つカラーインデックスデバイスにスタイルシートが適用されることを示します:
<?xml-stylesheet media="(min-color-index: 256)"
  href="http://www.example.com/…" ?>

6.3. モノクロ画面: monochrome機能

名称: monochrome
対象: @media
値: <integer>
型: range

monochromeメディア機能は、モノクロフレームバッファの1ピクセルあたりのビット数を表します。 デバイスがモノクロ対応でなければ出力値は0です。

monochrome負の範囲でfalseです。

例:スタイルシートがすべてのモノクロデバイスに適用されることを示す記述:
@media (monochrome) { … }
スタイルシートが1ピクセルあたり2ビット超のモノクロデバイスに適用されることを示す記述:
@media (monochrome >= 2) { … }
カラーページ用とモノクロ用でスタイルシートを分ける記述例:
<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色空間以上の色域をおおよそサポートできます。

注: p3色域はsrgb色域を含み、より広いです。

rec2020
UAと出力デバイスがITU-R勧告BT.2020色空間以上の色域をおおよそサポートできます。

注: rec2020色域はp3色域を含み、より広いです。

以下の表は、各色空間の主色(一次色)の色度座標を示しています。詳細は[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]参照。

例:このメディアクエリはDCI P3範囲の色をサポートするディスプレイで適用されます:
@media (color-gamut: p3) {}

注: 出力デバイスの色域が十分広い場合、またはある色域が他の色域の部分集合である場合、 このメディア機能の複数値が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-rangevideo-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%); }
}
このUAスタイルシートルールに加え、著者はスタイルシート次第でCSSで注入した画像(背景など)も反転したり、影を無効化したい場合があります:
@media (inverted-colors) {
  * {
    text-shadow: none !important;
    box-shadow: none !important;
  }
}

7. インタラクションメディア機能

「インタラクション」メディア機能は、ユーザーがページとどのようにやりとりするかの様々な側面を反映します。

pointerhoverの組み合わせに一致するデバイスの典型例:
pointer: none pointer: coarse pointer: fine
hover: none キーボードのみの操作、順次/空間(十字キー)フォーカスナビゲーション スマートフォン、タッチスクリーン 基本的なスタイラスデジタイザ(Cintiq、Wacom等)
hover: hover Nintendo Wiiコントローラ、Kinect マウス、タッチパッド、高度なスタイラスデジタイザ(Surface、Samsung Note、Wacom Intuos Pro等)

pointerおよびhoverは「主要」ポインティングデバイスの特性に関係し、 any-pointerany-hoverは利用可能な全ポインティングデバイスの特性を問い合わせるのに使えます。

注: この仕様はUAが「主要」ポインティングデバイスをどう決定するかを定義しませんが、 UAは実行環境や利用可能なポインティングデバイスの数・種類、および一般的・現在利用されているデバイスの知識を組み合わせて判断すべきと期待されています。 デバイスの主要入力がポインティングデバイスでない場合でも、補助的・使用頻度の低いポインティングデバイスがあるならUAは非ポインティングデバイスを主要扱いすることもあります(結果として'pointer: none')。 UAはユーザー環境やユーザーの操作方法の変化に応じて、主要とみなすポインティングデバイスの種類を動的に変更する場合もあります。

注: pointerhoverany-pointerany-hoverは、ポインティングデバイスの特性や存在の有無のみに関係し、キーボードなど非ポインティングデバイスの入力機構の有無検出には使えません。 著者は、これらの機能を問い合わせた結果にかかわらず、非ポインティングデバイス入力が存在する可能性も考慮すべきです。

pointerhoverはページの基本スタイルやインタラクションモードを主要入力機構(主要ポインティングデバイスの特性や有無)に合わせて設計するのに使えますが、著者はany-pointerany-hoverによって検出される全ての種類のポインティングデバイスも考慮することを強く推奨します。

7.1. ポインティングデバイスの品質: pointer機能

名称: pointer
対象: @media
値: none | coarse | fine
型: discrete

pointerメディア機能は、マウス等のポインティングデバイスの有無と精度を問い合わせます。 複数ポインティングデバイスがある場合は、 pointerメディア機能はUAが決定した「主要」ポインティングデバイスの特性を反映します。 (すべての利用可能ポインティングデバイスの能力を問い合わせる場合はany-pointerメディア機能を参照)

none
デバイスの主要入力機構がポインティングデバイスを含みません。
coarse
主要入力機構に精度の低いポインティングデバイスが含まれます。 例:タッチスクリーンやモーションセンサ(XboxのKinectなど)。
fine
主要入力機構に精度の高いポインティングデバイスが含まれます。 例:マウス、タッチパッド、ペン型デバイス。

coarsefineはどちらもポインティングデバイスの存在を示しますが、精度が異なります。 ズーム倍率1で隣接する小さなターゲットを確実に選択するのが困難または不可能なデバイスはcoarseに該当します。 ズーム倍率を変更してもこのメディア機能の値は変わりません。

注: UAがユーザーにズーム機能を提供する場合や、補助的なポインティングデバイスが異なる精度を持つ場合、値がcoarseでもユーザーが正確なクリックをできる場合があります。 このメディア機能は、ユーザーが絶対に正確なクリックができないことを示すものではなく、単にそれが不便であることを示します。 著者はcoarseの場合は正確なクリックを必要としない設計を心がけるべきです。

アクセシビリティの観点から、ポインティングデバイスがfineと判定できるデバイスでも、UAはcoarsenoneを返すことがあります(ユーザーが正確な操作が困難な場合)。 また、主要ポインティングデバイスが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に一致します(主要デバイスがタッチスクリーンでホバー不可のため)。

しかし、オプションのマウスではホバー可能です。 著者は「: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-pointerany-hover機能

名称: any-pointer
対象: @media
値: none | coarse | fine
型: discrete
名称: any-hover
対象: @media
値: none | hover
型: discrete

any-pointerany-hoverpointerhoverと同等ですが、 ユーザーが利用可能な全てのポインティングデバイスの能力の合算に対応します。 any-pointerの場合、異なる特性のデバイスが複数あると複数値が同時一致することもあります。

any-pointerany-hoverは、全てのポインティングデバイスがnoneに一致する場合、またはポインティングデバイスが全く存在しない場合のみnoneに一致します。

any-pointerはポインティングデバイスの有無と精度を問い合わせます。 他の入力(非ポインティングデバイス)は考慮しませんし、画面上カーソルを動かせないd-padやキーボードのみの操作機構の検出には使えません。 'any-pointer:none'がtrueになるのはポインティングデバイスが一切存在しない場合のみです。
例:従来型のデスクトップ環境(マウスとキーボード)では 'any-pointer:none'はfalse(マウスがあるため)になりますが、非ポインター入力(キーボード)も存在します。
'any-hover:none'はポインティングデバイスが存在しない場合、または全てのポインティングデバイスがホバー機能を持たない場合のみtrueになります。 これは、ホバー可能なポインティングデバイスが存在するかどうかのテストとして理解すべきです。逆にホバー非対応デバイスが存在するかは、現状any-hoverや他のインタラクションメディア機能では判定できません。 また、非ポインティングデバイス入力(d-padやキーボードのみ操作等)も考慮しません。
タッチ対応ノートPCにマウスとタッチスクリーン両方がある場合、 'any-hover:none'はfalse(ホバー可能なマウスがあるため)になりますが、ホバー非対応のタッチスクリーンも存在します。 現状、異なるポインティングデバイスが異なるホバー能力を持つ場合のスタイル分岐はできません。
ページ設計でホバーや正確なポイント操作に依存する場合、any-hoverany-pointerが1つでも対応しているからといって依存するとUXが悪化します。 ただし、著者はこの情報を利用して、ユーザーが利用可能な追加ポインティングデバイスに応じたスタイルや機能を検討することもできます。
多くのスマートTVは画面上カーソルを操作できるコントローラを備えていますが、操作精度が低いことが多いです。

このようなTVのブラウザは、coarsepointerおよびany-pointerの値となり、著者は大きく押しやすいクリックターゲットのレイアウトを提供できます。

ユーザーがBluetoothマウスをTVにペアリングし、たまに使う場合もありますが、これはTVの主な操作方法ではありません。pointerは依然coarseに一致し、any-pointercoarsefine両方に一致します。

この時(any-pointer: fine)がtrueだからといって小さなクリックターゲットに切り替えるのは適切ではありません。 ユーザーの期待と異なる体験となり、TVの主要操作がマウスでない場合は不便です(マウスが手元にない、ソファの下に隠れている等...)。

一方、スクロールについて考えてみましょう。 正確なポインティングデバイスがなければスクロールバー操作は困難です。 (pointer: coarse)がtrueなら、著者は他の方法(スクロール可能表示)も準備できますが、(any-pointer: fine)がtrueならスクロールバーも表示、falseなら視覚的ノイズを減らすため非表示にする...といった工夫も可能です。

名称: 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ページ戻る操作を行えます。
著者はウェブアプリ内に「戻る」ボタンを含め、UAがすでにその機能を提供している場合は条件付きで非表示にできます:
@media (nav-controls: back) {
  #back-button {
    display: none;
  }
}

このメディア機能は真偽型コンテキストでも使えるため、同じ例をより短い構文で書くこともできます:

@media (nav-controls) {
  #back-button {
    display: none;
  }
}

注: 理論的には両者は厳密には同等ではなく、将来このメディア機能にback以外の値が追加されると、backが一致しない場合でも一致することがあります。 その場合、真偽型コンテキストでnav-controlsを使うのは誤解を招く可能性があります。 ただし、「戻る」操作は最も基本的なナビゲーションと考えられるため、CSS WGは「戻る」ボタンなしで明示的なナビコントロールだけあるUIは想定しておらず、実際にはこの問題は生じないと考えています。

容易に発見できるコントロールがアクティブかどうかは、このメディア機能の評価に影響しません。

joint session historyに前ページがない場合、UAが「戻る」ボタンを持っていても、履歴が存在するまで無効状態にすることができます。 この場合も@media (nav-controls: back) { … }は一致する想定です。

8. ビデオ接頭辞付き機能

一部のUA(多くのテレビなど)は、映像とグラフィックを2つの異なる「プレーン」(バイプレーン)でレンダリングし、画面特性も異なります。ビデオプレーンを記述するためにvideo接頭辞付き機能セットが用意されています。

バイプレーン実装では、以下の機能についてはvideoプレーンの値を返さなければなりません:video-color-gamutvideo-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になります。 truefalseが指定された場合は、それぞれtrue/falseになります。

カスタムメディアクエリは論理的に評価され、テキスト置換として扱われません。 例えば次のコード:
/* --modern は color または hover 対応のモダンデバイスを対象 */
@custom-media --modern (color), (hover);

@media (--modern) and (width > 1024px) {
  .a { color: green; }
}

これは以下と同等です:

@media ((color) or (hover)) and (width > 1024px) {
  .a { color: green; }
}

次のように処理するのは誤りです:

@media (color), (hover) and (width > 1024px) {
  .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. スクリプトベースのカスタムメディアクエリ

JS用に名前と値のマップ定義。 値はMediaQueryListオブジェクトまたはブール値なら上記と同等扱い、数値や文字列なら通常のMQ・範囲コンテキスト構文で使える。 例:
<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機能参照。

ユーザーが錆色背景にシアン文字を希望する場合、明度的には高コントラストでも低コントラストでもなく、希望がないわけでもありません。
注: 著者はprefers-contrast: moreprefers-contrast: lessに応じて、ユーザーの希望に合わせて対応できます。

何も指定せず@media (prefers-contrast) {} で高コントラストスタイルを適用するのは誤りかつユーザーに不親切です。逆希望の人にも強制されてしまいます。

ただし、高低両方のコントラスト希望に対して視覚的なノイズや色の複雑さを減らす対応(背景画像を単色に置換、装飾グラデーションや境界画像・ボックスシャドウを単純な枠線に変更等)は一般的です。 その場合は@media (prefers-contrast) {}morelessを指定せずに使い、prefers-contrast: customも含めて、prefers-contrast: moreprefers-contrast: lessと同様に真偽型コンテキストでtrueになるので、強制色モードでも恩恵があります(高低どちらでもない色でも)。 強制色モードでは色数が減る分、ページの視覚的な単純化が望ましいためです。

コントラスト増減希望は様々な状況から生じます。例:

このリストは今後拡張・精緻化すべきです。

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
強制色モードは有効でありません。
強制色モード有効時、著者が使える色はシステム色のみです。 UAはこの限定パレットを自動で強制しますが、著者はforced-colorsメディア機能で状況を検出して色の使い方を変えることもできます。

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が適切に反映されるようにすべきです。

この機能(と他のprefers-*機能)は、かつては希望なしを示すno-preference値がありました。 しかしUAは「デフォルト」動作をlight希望として表現し、no-preferenceには一致しないようになりました。

もし将来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はデバイスや環境等の知識からユーザー希望を自動推定することもできます。 その場合は、自動推定された希望からユーザーがオプトアウトまたは上書きできる手段も用意することが推奨されます。

ユーザーがlightdarkカラースキームを明示的に選択できるだけでなく、UAが現在時刻に基づいて自動判定するモードを持ち、日没から夜明けまでdarkを希望として扱うこともできます。
使用するディスプレイ種別によっては、周囲の明るさの変化で快適な読書体験を損なう場合があります。

例えば、液晶ディスプレイは明るい環境下だと白飛びして非常に読みにくくなります。 こうした画面と照度センサーを持つデバイスでは、読みにくい条件を検知した場合prefers-contrastmoreに自動切り替えできます。 電子ペーパー(E-ink)ディスプレイ搭載デバイスでは、明るい屋外でも可読性が保たれるため、このような自動調整は行いません。

逆に、発光型ディスプレイ(LCD、OLED等)+照度センサー搭載デバイスでは、暗い環境でコントラストや輝度が高すぎると読みにくいので、prefers-contrastlessprefers-color-schemedarkに自動切り替えることができます。

UAは、ネットワーク接続が無制限か従量課金かによってprefers-reduced-data: no-preferencereduceを自動で切り替えることもできます。

付録A: 廃止予定メディア機能

以下のメディア機能廃止予定です。 後方互換のため残されていますが、新しいスタイルシートには使わないでください。著者は使用禁止。UAは指定通りサポートしなければなりません。

ビューポート(またはページメディアの場合はページボックス)のサイズを問い合わせる場合は、widthheightaspect-ratio メディア機能を使うべきで、device-widthdevice-heightdevice-aspect-ratioは、デバイスの物理サイズを参照しており、レイアウト対象の領域サイズとは無関係です。device-* メディア機能はモバイルデバイス検出の代用にも使われることがありますが、目的に合ったメディア機能を使うべきです。

device-width

名称: device-width
対象: @media
値: <length>
型: range

device-width メディア機能は、出力デバイスのレンダリング面の幅を表します。 連続メディアの場合はWeb公開画面領域の幅、 ページメディアの場合はページシートサイズの幅です。

device-width負の範囲でfalseです。

@media (device-width < 800px) { … }

上記例では、スタイルシートは長さが800px未満の画面にのみ適用されます。 px単位は論理単位で、単位セクションで説明しています。

注: デバイスが縦横両向き利用可能な場合、device-*メディア機能は現在の向きを反映します。

device-height

名称: device-height
対象: @media
値: <length>
型: range

device-height メディア機能は、出力デバイスのレンダリング面の高さを表します。 連続メディアの場合はWeb公開画面領域の高さ、 ページメディアの場合はページシートサイズの高さです。

device-height負の範囲でfalseです。

<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' メディア機能の値で割った比率として定義されています。

例:正方形ピクセルの画面デバイスで水平方向1280px、垂直方向720px(一般「16:9」)の場合、以下のメディアクエリはすべて一致します:
@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 ワーキングドラフト以降にこのモジュールへ加えられました:

2020-07-15 ワーキングドラフト以降の変更点

以下の追加が2020-07-15 ワーキングドラフト以降にこのモジュールへ加えられました:

2020-06-03 ワーキングドラフト以降の変更点

以下の追加が2020-06-03 ワーキングドラフト以降にこのモジュールへ加えられました:

2020-03-18 ワーキングドラフト以降の変更点

以下の追加が2020-03-18 ワーキングドラフト以降にこのモジュールへ加えられました:

最初のパブリックワーキングドラフト以降の変更点

以下の追加が2020-03-03 最初のパブリックワーキングドラフト以降にこのモジュールへ加えられました:

Media Queries Level 4 以降の変更点

以下の追加がこのモジュールの最初のパブリックワーキングドラフトに対して、Media Queries Level 4以降に加えられました:

謝辞

このセクションは規範的ではありません。

本仕様は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, そして 張俊芝 が本仕様の改善に貢献しました。

適合性

文書の規約

適合性要件は、説明的な断言とRFC 2119用語の組み合わせで表現されます。規範部分で使われる "MUST"、"MUST NOT"、"REQUIRED"、"SHALL"、"SHALL NOT"、"SHOULD"、"SHOULD NOT"、"RECOMMENDED"、"MAY"、"OPTIONAL" などのキーワードはRFC 2119で定義された通り解釈してください。ただし、可読性のため、この仕様書ではこれらの語はすべて大文字では記載されません。

この仕様の文書本文は、明示的に非規範と記載されたセクション、例、注記を除きすべて規範的です。[RFC2119]

この仕様での例は「例えば」で始まるか、または次のように class="example" で規範テキストから分離されます:

これは情報提供のみの例です。

情報的な注記は「注:」で始まり、class="note"で規範テキストから分離されます:

注: これは情報的な注記です。

注意喚起は規範的なセクションで、特別な注意を促すスタイルで表示され、<strong class="advisement"> で分離されます。例: UAは必ずアクセシブルな代替手段を提供しなければなりません。

適合性クラス

本仕様への適合は、次の3つの適合クラスで定義されます:

スタイルシート
CSSスタイルシート
レンダラー
UAは、スタイルシートの意味を解釈し、それを使う文書を描画するもの。
オーサリングツール
UAは、スタイルシートを作成するもの。

スタイルシートが本仕様に適合するとされるのは、モジュールで定義された構文を使う文が、汎用CSS文法および本モジュールで定義された各機能の個別文法に従いすべて有効な場合です。

レンダラーが本仕様に適合するとされるのは、スタイルシートを適切な仕様通りに解釈することに加え、本仕様で定義されたすべての機能を正しくパースし、文書をそれに従って描画する場合です。ただし、デバイスの制約によってUAが文書を正しく描画できない場合でも、UAが不適合になるわけではありません(例:UAがモノクロモニターの場合、色の描画は必須ではありません)。

オーサリングツールが本仕様に適合するとされるのは、汎用CSS文法および本モジュールの各機能の個別文法に適合するスタイルシートを書き、スタイルシートの他の適合要件をすべて満たしている場合です。

部分実装

著者が将来互換性のあるパース規則を利用してフォールバック値を指定できるよう、CSSレンダラーは、サポートできないat-rule・プロパティ・値・キーワードその他の構文については必ず無効(および必要に応じて無視)として扱わなければなりません。特に、UAはマルチ値プロパティ宣言のうち未サポート値のみ選択的に無視し、サポート値だけを反映することは絶対にしてはなりません。宣言内に無効値がある場合(未サポート値は必ず無効)、CSSでは宣言全体が無視されます。

不安定・独自機能の実装

将来の安定CSS機能との衝突を避けるため、CSSWGはベストプラクティスに従って不安定な機能や独自拡張を実装することを推奨します。

非実験的実装

仕様がCandidate Recommendation段階に達したら、非実験的な実装が可能となり、実装者は仕様通り正しく実装できるCRレベル機能については、ベンダープレフィックス無しでリリースすべきです。

CSSの実装間で相互運用性を確立・維持するため、CSSワーキンググループは非実験的なCSSレンダラーに対し、CSS機能のベンダープレフィックス無し実装リリース前に実装報告書(必要ならそのテストケースも)をW3Cへ提出するよう要請します。提出されたテストケースはCSSワーキンググループによるレビュー・修正対象となります。

テストケースと実装報告書の提出方法についてはCSSワーキンググループサイト https://www.w3.org/Style/CSS/Test/ を参照してください。質問は public-css-testsuite@w3.org メーリングリストまで。

索引

この仕様で定義された用語

参照によって定義された用語

参考文献

規範的な参考文献

[COLORIMETRY]
Colorimetry, Fourth Edition. CIE 015:2018. 2018年. URL: http://www.cie.co.at/publications/colorimetry-4th-edition
[CSS-CASCADE-5]
Elika Etemad; Miriam Suzanne; Tab Atkins Jr.. CSS Cascading and Inheritance Level 5. 2021年12月3日. WD. URL: https://www.w3.org/TR/css-cascade-5/
[CSS-COLOR-ADJUST-1]
Elika Etemad; 他. CSS Color Adjustment Module Level 1. 2021年6月16日. WD. URL: https://www.w3.org/TR/css-color-adjust-1/
[CSS-CONDITIONAL-3]
David Baron; Elika Etemad; Chris Lilley. CSS Conditional Rules Module Level 3. 2020年12月8日. CR. URL: https://www.w3.org/TR/css-conditional-3/
[CSS-EXTENSIONS]
Tab Atkins Jr.. CSS Extensions. ED. URL: https://drafts.csswg.org/css-extensions/
[CSS-SYNTAX-3]
Tab Atkins Jr.; Simon Sapin. CSS Syntax Module Level 3. 2019年7月16日. CR. URL: https://www.w3.org/TR/css-syntax-3/
[CSS-VALUES-4]
Tab Atkins Jr.; Elika Etemad. CSS Values and Units Module Level 4. 2021年10月16日. WD. URL: https://www.w3.org/TR/css-values-4/
[CSS-WRITING-MODES-4]
Elika Etemad; Koji Ishii. CSS Writing Modes Level 4. 2019年7月30日. CR. URL: https://www.w3.org/TR/css-writing-modes-4/
[CSS2]
Bert Bos; 他. Cascading Style Sheets Level 2 Revision 1 (CSS 2.1) Specification. 2011年6月7日. REC. URL: https://www.w3.org/TR/CSS21/
[CSSOM-VIEW-1]
Simon Pieters. CSSOM View Module. 2016年3月17日. WD. URL: https://www.w3.org/TR/cssom-view-1/
[HTML]
Anne van Kesteren; 他. HTML Standard. リビングスタンダード. URL: https://html.spec.whatwg.org/multipage/
[MEDIAQUERIES-3]
Florian Rivoal; 他. Media Queries. 2012年6月19日. REC. URL: https://www.w3.org/TR/css3-mediaqueries/
[MEDIAQUERIES-4]
Florian Rivoal; Tab Atkins Jr.. Media Queries Level 4. 2020年7月21日. CR. URL: https://www.w3.org/TR/mediaqueries-4/
[RFC2119]
S. Bradner. Key words for use in RFCs to Indicate Requirement Levels. 1997年3月. Best Current Practice. URL: https://datatracker.ietf.org/doc/html/rfc2119

参考情報

[APPMANIFEST]
Marcos Caceres; 他. Web Application Manifest. 2021年11月10日. WD. URL: https://www.w3.org/TR/appmanifest/
[CSS-COLOR-4]
Tab Atkins Jr.; Chris Lilley. CSS Color Module Level 4. 2021年6月1日. WD. URL: https://www.w3.org/TR/css-color-4/
[CSS-FONTS-5]
Myles Maxfield; Chris Lilley. CSS Fonts Module Level 5. 2021年7月29日. WD. URL: https://www.w3.org/TR/css-fonts-5/
[FULLSCREEN]
Philip Jägenstedt. Fullscreen API Standard. リビングスタンダード. URL: https://fullscreen.spec.whatwg.org/
[HTML401]
Dave Raggett; Arnaud Le Hors; Ian Jacobs. HTML 4.01 Specification. 2018年3月27日. REC. URL: https://www.w3.org/TR/html401/
[INFRA]
Anne van Kesteren; Domenic Denicola. Infra Standard. リビングスタンダード. URL: https://infra.spec.whatwg.org/
[ITU-R-BT-2020-2]
Parameter values for ultra-high definition television systems for production and international programme exchange. 2015年10月. URL: https://www.itu.int/rec/R-REC-BT.2020/en
[RFC2879]
G. Klyne; L. McIntyre. Content Feature Schema for Internet Fax (V2). 2000年8月. Proposed Standard. URL: https://www.rfc-editor.org/rfc/rfc2879
[SMPTE-EG-432-1-2010]
SMPTE Engineering Guideline - Digital Source Processing — Color Processing for D-Cinema. 2010年. URL: http://ieeexplore.ieee.org/document/7289763/
[SMPTE-RP-431-2-2011]
SMPTE Recommended Practice - D-Cinema Quality — Reference Projector and Environment. 2011年. URL: http://ieeexplore.ieee.org/document/7290729/
[SRGB]
Multimedia systems and equipment - Colour measurement and management - Part 2-1: Colour management - Default RGB colour space - sRGB. URL: https://webstore.iec.ch/publication/6169
[XML-STYLESHEET]
James Clark; Simon Pieters; Henry Thompson. Associating Style Sheets with XML documents 1.0 (Second Edition). 2010年10月28日. REC. URL: https://www.w3.org/TR/xml-stylesheet/

プロパティ索引

定義されたプロパティはありません。

@media ディスクリプタ一覧

名称 初期値
any-hover none | hover discrete
any-pointer none | coarse | fine discrete
aspect-ratio <ratio> range
color <integer> range
color-gamut srgb | p3 | rec2020 discrete
color-index <integer> range
device-aspect-ratio <ratio> range
device-height <length> range
device-width <length> range
display-mode fullscreen | standalone | minimal-ui | browser discrete
dynamic-range standard | high discrete
environment-blending opaque | additive | subtractive discrete
forced-colors none | active discrete
grid <mq-boolean> discrete
height <length> range
horizontal-viewport-segments <integer> range
hover none | hover discrete
inverted-colors none | inverted discrete
monochrome <integer> range
nav-controls none | back discrete
orientation portrait | landscape discrete
overflow-block none | scroll | paged discrete
overflow-inline none | scroll discrete
pointer none | coarse | fine discrete
prefers-color-scheme light | dark discrete
prefers-contrast no-preference | less | more | custom discrete
prefers-reduced-data no-preference | reduce discrete
prefers-reduced-motion no-preference | reduce discrete
prefers-reduced-transparency no-preference | reduce discrete
resolution <resolution> | infinite range
scan interlace | progressive discrete
scripting none | initial-only | enabled discrete
update none | slow | fast discrete
vertical-viewport-segments <integer> range
video-color-gamut srgb | p3 | rec2020 discrete
video-dynamic-range standard | high discrete
width <length> range

課題索引

ユーザー情報はアクティブなフィンガープリントベクトルとして利用される可能性があります。 影響分析は保留中であり、仕様公開前に追加情報が提供される予定です。

この仕様を実装するUAや開発者は、このベクトルを認識し、機能を使用する際に考慮する必要があります。特に `prefers-reduced-motion`、`prefers-color-scheme`、`prefers-reduced-data` は、現時点で悪用の懸念があります。

subtractive値は必要でしょうか?
UAがinitial-onlyを主張するための明示的な最小基準が必要か? 基準があれば著者は依存でき、スクリプトを調整できるが、閾値設定は難しい。 低すぎると著者が依存できるスクリプティング機能が実用上制約されるし、実際のUAはもっと多くサポートしている可能性もある。 高すぎると、ロード時のみスクリプトをサポートし、複雑なヒューリスティックで制限するUAを除外することになる。 例えば、保守的な定義ならインラインスクリプトの実行とDOMContentLoadedイベントの発火は含まれる。 しかしinitial-only UAが外部スクリプト(async, defer含む)読み込みやloadイベント発火も行うなら、著者がそれだけに制約される意味は薄い。 一方、外部スクリプト読み込みやloadイベント必須とすると、Opera miniのようなUAはタイムアウト等のヒューリスティックで外部スクリプト未実行になる場合もある。 [Issue #503]
JS用に名前と値のマップ定義。 値はMediaQueryListオブジェクトまたはブール値なら上記と同等扱い、数値や文字列なら通常のMQ・範囲コンテキスト構文で使える。 例:
<script>
CSS.customMedia.set('--foo', 5);
</script>
<style>
@media (_foo: 5) { ... }
@media (_foo < 10) { ... }
</style>
パターン塗りや背景などの希望とどのように相互作用するか?これらは透明度ではないが形状認識の妨げにもなる。
このリストは今後拡張・精緻化すべきです。
この機能は指紋化の望ましくない要素となる可能性があり、低所得・データ制限環境へのバイアスにつながる懸念があります。この仕様にはプライバシーとセキュリティのセクションを追加し、この懸念に対応すべきです。[Issue #4832]
このセクションは未完成です