メディアクエリ レベル4

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. モジュールの相互作用

このモジュールは、[CSS2]のセクション7および[MEDIAQUERIES-3]で定義されたメディアクエリ、メディアタイプ、メディア機能を置き換え、拡張します。

1.2. 値

この仕様で定義されていない値型、たとえば<integer>、 <number>、 <resolution>などは、 [CSS-VALUES-3]で定義されています。他のCSSモジュールがこれらの値型の定義を拡張する場合があります。

1.3. 単位

メディアクエリで使われる単位は、他のCSSの部分と同じであり、 [CSS-VALUES-3]で定義されています。たとえば、ピクセル単位はCSSピクセルを表し、物理的なピクセルではありません。

相対長単位は、メディアクエリ内では初期値を基準とします。つまり、単位は宣言の結果を基準にすることはありません。例えばHTMLでは、 em単位はfont-sizeの 初期値（ユーザーエージェントまたはユーザーの設定によって定義）を基準としており、 ページ上のスタイリングには依存しません。

2. メディアクエリ

メディアクエリは、 ドキュメントが表示されているユーザーエージェントやデバイスの特定の側面をテストする方法です。 メディアクエリは（ほぼ）常にドキュメントの内容、 スタイリング、その他の内部的な要素とは独立しており、 「外部」の情報のみに依存します（他の機能が明示的にメディアクエリの解決に影響すると指定されている場合を除く）。

メディアクエリの構文は、 オプションのメディアクエリ修飾子、 オプションのメディアタイプ、 そして0個以上のメディア機能から構成されます：

メディアクエリは、 論理式であり、真または偽になります。 メディアクエリが真になる条件は次の通りです：

• 指定された場合、メディアタイプが、 ユーザーエージェントが動作しているデバイスのメディアタイプと一致すること

• メディア条件が真であること。

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

<link rel="stylesheet" media="screen and (color)" href="example.css" />

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

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

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

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

複数のメディアクエリをコンマ区切りで組み合わせて、メディアクエリリストを作成できます。

メディアクエリリストは、構成するメディアクエリのいずれかが真なら真となり、すべてが偽の場合のみ偽となります。

@media screen and (color), projection and (color) { … }

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

@media all { … }
@media { … }

2.2. メディアクエリ修飾子

メディアクエリは、1つのメディアクエリ修飾子を前置できます。これは、後続のメディアクエリの意味を変更するキーワードです。

2.2.1. メディアクエリの否定：not キーワード

個々のメディアクエリは、キーワードnotを前置することで、その結果を否定できます。 メディアクエリが通常は真になる場合、notを付けることで偽になり、逆も同様です。

<link rel="stylesheet" media="not screen and (color)" href="example.css" />

2.2.2. レガシーユーザーエージェントからメディアクエリを隠す：only キーワード

メディアクエリの考え方はHTML4 [HTML401] に由来します。 その仕様ではメディアタイプのみが定義されていましたが、将来的なメディア機能の追加に備えた前方互換構文となっていました。 仕様ではメディアクエリの最初の英数字以外の文字までをメディアタイプと解釈し、残りは無視します。 例えば、メディアクエリ「screen and (color)」はscreenのみとして扱われます。

このため、古いユーザーエージェントはメディアクエリ内のメディア機能を無視してしまい、メディアタイプよりも重要な場合でもスタイルが不適切に適用されることがあります。

このようなメディアクエリを古いユーザーエージェントから隠すには、メディアクエリの先頭にキーワードonlyを付けます。 onlyキーワードはメディアクエリの結果には影響しませんが、古いユーザーエージェントでは未知のメディアタイプ「only」として解釈され、無視されます。

<link rel="stylesheet" media="only screen and (color)" href="example.css" />

注: onlyキーワードはメディアタイプの前にのみ使用できます。 メディア機能のみのメディアクエリや、not修飾子付きのものは、古いユーザーエージェントでは自動的に偽と見なされます。

注: この仕様の公開時点では、このような古いユーザーエージェントは非常に稀であり、only修飾子を使う必要はほとんどありません。

2.3. メディアタイプ

メディアタイプは、ドキュメントが表示されるユーザーエージェント端末の大まかなカテゴリです。 元のメディアタイプはHTML4で定義され、media属性として<link>要素に使用されました。

しかし、メディアタイプは端末ごとのスタイリングの違いを表現するには不十分であることが判明しています。 例えば、screenやhandheldのような区分は、年月とともに大きく重複するようになっています。 ttyやtvなどは、通常のPCモニタとは異なる有用な違いを持っているため、異なるスタイリング対象にする価値がありますが、 メディアタイプの排他性の定義があるため、実用的な使い方が難しくなっています。 そのため、こうした特徴はメディア機能（例：gridやscan）で表現する方が適しています。

そのため、以下のメディアタイプをメディアクエリで使用できます：

all

すべての端末に一致します。

print

プリンターや、印刷プレビュー表示するウェブブラウザなど、印刷表示を再現する端末に一致します。

screen

print以外のすべての端末に一致します。

加えて、以下の非推奨のメディアタイプが定義されています。 著者はこれらのメディアタイプを使用するべきではありません。 端末の特徴をより適切に表現できるメディア機能を選択することを推奨します。

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

• tty
• tv
• projection
• handheld
• braille
• embossed
• aural
• speech

注: 今後、すべてのメディアタイプが非推奨になることが予想されます。重要な違いを捉える適切なメディア機能が定義されるためです。

2.4. メディア機能

メディア機能は、メディアタイプよりも細かく、ユーザーエージェントや表示端末の特定の機能を判定します。

構文的には、メディア機能はCSSプロパティに似ており、機能名、コロン、判定値で構成されます。 また、機能名のみのブール型や、比較演算子を使った範囲型で記述することも可能です。

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

• プロパティはドキュメントの表示方法を指定するための情報を提供しますが、メディア機能は出力端末の要件を記述します。
• メディア機能は必ず括弧で囲み、andやorキーワードで組み合わせます（例：(color) and (min-width: 600px)）。セミコロン区切りにはしません。
• メディア機能は名前のみ（コロンと値を省略）でも記述でき、ブール型コンテキストで評価されます。これは値が0や「なし」となる機能に便利です。 例えば、(color)はcolor メディア機能がゼロ以外なら真です。
• “range”型のメディア機能は範囲型コンテキストで記述でき、コロンではなく比較演算子を使ったり、“min-”や“max-”を機能名に付与できます。
• プロパティは複雑な値（他の値を含む計算など）を受け付けることがありますが、メディア機能は単一の値（キーワード1つ、数字1つなど）のみ受け付けます。

メディア機能が、UAが動作している端末に存在しない概念（例：音声UAの“width”など）を参照した場合、メディア機能は常に偽と評価されなければなりません。

<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-」のプレフィックスを付けることができる点です。 これらのいずれかを行うことで、機能の意味が変わります。つまり、メディア機能が指定値と完全一致する場合に真となるのではなく、指定値以上／以下／等しい場合に真となります。

2.4.2. メディア機能のブール型コンテキストでの評価

メディア機能は通常、CSSプロパティに似た構文を持ちますが、機能名のみで簡素に記述することもできます。例：(color)

このように記述した場合、メディア機能はブール型コンテキストで評価されます。 機能が0または値が0の<dimension>、あるいはキーワードnone以外なら真となります。 それ以外は偽になります。

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

「range」型のメディア機能は、値の順序性を活かして通常の数学的比較演算子を使う範囲型コンテキストで記述できます：

注: この構文はMediaqueriesレベル4の新機能であり、現時点ではmin-/max-プレフィックスほど広くサポートされていません。

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

残りの形は、機能名を2つの値比較の間に挟み、両方の比較が真なら真となります。

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

注: もし負値がパース時に却下されていた場合、エラー処理規則によりunknown扱いとなります。 しかし実際には、端末のresolutionが-300dpiなのは「不明」ではなく、偽であることが分かっています。 同様に、可視端末なら表示領域のwidthは-200pxより大きいことが分かっています。上記規則はその直感に合わせており、UAの挙動を反映しています。

@media not (width <= -100px) {
  body { background: green; }
}

@media (height > -100px) {
  body { background: green; }
}

@media not (resolution: -300dpi) {
  body { background: green; }
}

2.4.4. 範囲型機能への「min-」・「max-」プレフィックスの利用

上記のような範囲型メディア機能を範囲型コンテキストで評価する代わりに、 「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以上のスタイル */ }

@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」で連結すると、すべての機能が真のときだけクエリが真になります。 例：(width < 600px) and (height < 600px)は、縦横ともに600px未満の端末にだけマッチします。

• また、2つ以上のメディア機能を「or」で連結すると、いずれかが真ならクエリが真となります。 例：(update: slow) or (hover: none)は、端末が画面更新に時間がかかる場合（電子書籍端末など）または主なポインティングデバイスにホバー機能がない場合にマッチします。この場合は、情報を隠さず表示するレイアウトが望ましいかもしれません。

• メディア条件は括弧()でグループ化でき、条件式の中で入れ子にできます。 例：(not (color)) or (hover)は、モノクロ端末かつ/またはホバー機能がある端末に真となります。 もし、モノクロかつホバーなし端末のみを問いたい場合は、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)のように記述してください。 この2つは意味が異なり、(hover)だけ真なら 前者は偽、後者は真となります。

3. 構文

非公式なメディアクエリ構文の説明は、前節の本文や図に記載されています。 ここでは正式なメディアクエリ構文を説明します。規則・プロパティの文法構文は[CSS-SYNTAX-3]および[CSS-VALUES-3]で定義されています。

<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>? ) ] | ( <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>すべてが真なら真、いずれかが偽なら偽、それ以外はunknownです。

<media-in-parens><media-or>*

<media-in-parens>子項と、<media-in-parens>すべてが偽なら偽、いずれかが真なら真、それ以外はunknownです。

<general-enclosed>

結果はunknownです。

著者は<general-enclosed>をスタイルシートで使用してはいけません。これは将来互換性のためだけに存在します。新しい構文追加によって既存の<media-condition>の多くが古いUAで無効にならないよう配慮されています。

<media-feature>

指定されたメディア機能の評価結果です。

上記のいずれかの生成規則の結果が2値ブールが期待されるコンテキストで使われる場合、「unknown」は「false」に変換されなければなりません。

注: つまり、例えばメディアクエリが@media規則で使われる場合、「unknown」は「false」として扱われ、マッチしません。

3.2. エラー処理

前節の文法に合致しないメディアクエリは、パース時にnot allに置き換えられます。

注: 文法不一致はメディアクエリリスト全体を無効にするものではなく、問題のあるメディアクエリのみです。 上記のパース動作により、次のトップレベルのコンマで自動的に回復されます。

@media (example, all,), speech { /* 音声端末専用 */ }
@media &test, speech           { /* 音声端末専用 */ }

@media (example, speech { /* 音声端末用ルール */ }

未知の<media-type>は一致しないものとして扱われます。

未知の<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" />

@media (min-orientation:portrait) { … }

@media test;,all { body { background:lime } }

4. ビューポート・ページ寸法メディア機能

4.1. 幅：width機能

widthメディア機能は、出力デバイスの対象表示領域の幅を示します。 連続メディアの場合は、CSS2セクション9.1.1 [CSS2]で説明されているように、 ビューポートの幅（スクロールバーのサイズを含む）です。 ページメディアの場合は、CSS2セクション13.2 [CSS2]で説明されているようにページボックスの幅です。

<length>の解釈は§ 1.3 単位に従います。

widthは負の範囲でfalseとなります。

<link rel="stylesheet" media="print and (min-width: 25cm)" href="http://…" />

@media (400px <= width <= 700px) { … }

@media (min-width: 20em) { … }

4.2. 高さ：height機能

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

<length>の解釈は§ 1.3 単位に従います。

heightは負の範囲でfalseとなります。

4.3. アスペクト比：aspect-ratio 機能

aspect-ratioメディア機能は、 widthメディア機能の値と heightメディア機能の値の比率として定義されます。

4.4. 向き：orientation 機能

portrait

orientationメディア機能は、heightメディア機能の値がwidthメディア機能の値以上の場合、portraitとなります。

landscape

それ以外の場合orientationはlandscapeとなります。

@media (orientation:portrait) { … }

5. 表示品質メディア機能

5.1. 表示解像度：resolution 機能

resolutionメディア機能は出力デバイスの解像度（ピクセル密度）を示します。ページズームを考慮しますが、ピンチズームは1.0とみなします。

resolutionメディア機能は負の範囲でfalseとなります。

非正方形ピクセルのメディアを判定する場合、resolutionは縦方向の密度を判定します。

プリンターの場合は、網点解像度（任意色の印刷ドット解像度）に対応します。 グレースケール印刷では異なる解像度になる場合があります。

物理的な解像度制約がない出力メディア（ベクターグラフィックスへの出力など）の場合、 この機能はinfinite値に一致しなければなりません。 範囲型コンテキストで評価する場合、infiniteは、どんな<resolution>よりも大きいものとして扱われます。 （つまり(resolution > 1000dpi)のようなクエリはinfiniteメディアに対して真となります。）

@media (resolution >= 2dppx)

@media print and (min-resolution: 300dpi) { … }

@media print and (min-resolution: 118dpcm) { … }

5.2. 表示タイプ：scan機能

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

interlace

CRTおよび一部プラズマTVは「インターレース」レンダリングを使用し、映像フレームはスクリーン上の偶数行だけ、または奇数行だけを交互に指定します。 これは人間の自動補正能力を利用し、滑らかな動きを再現します。 帯域半分で高FPS放送をシミュレートできました。

インターレース画面上では、著者は非常に速い動きを避け、「コーミング」を防ぎ、詳細は1px以上の幅にして「twitter」を防ぐべきです。

progressive

「プログレッシブ」レンダリングの画面は、毎回全画面を描画し、特別な対処は不要です。

現代の画面やすべてのPC画面はプログレッシブレンダリングを採用しています。

@media (scan: interlace) { body { font-family: sans-serif; } }

注: 執筆時点では、既知の実装はすべてscan: progressiveに一致し、scan: interlaceには一致しません。

5.3. コンソール表示検出：grid機能

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メディア機能は、出力デバイスがレンダリング後にコンテンツの見た目を変更できる能力を判定するためのものです。 受け付ける値は次の通りです：

none

一度レンダリングされるとレイアウトは更新できません。 例：紙への印刷物。

slow

レイアウトは通常のCSSルールに従って動的に変化できますが、出力デバイスは変更を滑らかなアニメーションのように素早く表示できません。 例：Eインク画面や極端に性能の低いデバイス。

fast

レイアウトは通常のCSSルールに従って動的に変化でき、出力デバイスに特別な速度制約はありません。 CSSアニメーションなど頻繁な更新が利用できます。 例：コンピュータ画面。

@media (update) {
  a { text-decoration: none; }
  a:hover, a:focus { text-decoration: underline; }
}
/* 非更新型UAでは、リンクは常に下線付きになります。 */

5.5. ブロック軸オーバーフロー：overflow-block 機能

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

none

ブロック軸でオーバーフローへの配慮がなく、溢れたコンテンツは表示されません。 例：屋外広告

scroll

ブロック軸の溢れたコンテンツは、ユーザーがスクロールして表示できます。 例：コンピュータ画面

paged

コンテンツはページ単位に分割され、ブロック軸で1ページから溢れた分が次ページに表示されます。 例：プリンター、電子書籍リーダー

noneまたはscrollに一致するメディアは連続メディア、 pagedに一致するメディアはページメディアと呼ばれます。

注: このメディア機能には将来的に、連続メディアとページメディア双方の特徴を持つハイブリッド型UAを表す値が追加される可能性があります。 例えば、Prestoレイアウトエンジン（現在は廃止）は「continuous」に似ていますが強制改ページを尊重する半ページ型表示モードを搭載していました。 現在このようなUAは知られていないため、本レベルでは誤った分類を避けるため値を追加しませんでした。 既存値で十分に表現できないUAを実装する場合は、ワーキンググループに連絡いただければ拡張を検討します。

5.6. インライン軸オーバーフロー：overflow-inline 機能

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

none

インライン軸でオーバーフローへの配慮がなく、溢れたコンテンツは表示されません。

scroll

インライン軸の溢れたコンテンツは、ユーザーがスクロールして表示できます。

注: インラインオーバーフローをページとして扱う既知の実装はなく、そもそも概念的にも意味が薄いため、paged値はoverflow-inlineには存在しません。

6. カラーメディア機能

6.1. カラー深度：color機能

colorメディア機能は、出力デバイスの各カラーコンポーネントあたりのビット数を示します。 デバイスが非カラーの場合、値はゼロです。

colorは負の範囲でfalseとなります。

@media (color) { … }
@media (min-color: 1) { … }

@media (color >= 8) { … }

異なるカラーコンポーネントごとにビット数が異なる場合、最小値が使われます。

インデックスカラーのデバイスでは、ルックアップテーブル内の各カラーコンポーネントの最小ビット数が使われます。

注: この機能は色能力を表面的にしか表現できません。著者のニーズには通常color-gamutの方が有用です。 さらに高度な機能が必要な場合はRFC2879 [RFC2879]を参照してください。今後追加される場合があります。

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

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

color-indexは負の範囲でfalseとなります。

@media (color-index) { … }
@media (color-index >= 1) { … }

<?xml-stylesheet media="(min-color-index: 256)"
  href="http://www.example.com/…" ?>

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

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

monochromeは負の範囲でfalseとなります。

@media (monochrome) { … }

@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メディア機能は、UAおよび出力デバイスが対応するおおよその色域を示します。 つまり、UAが指定された空間の色を受け取った場合、出力デバイスがその色を表示できるか、または十分近い色を表示できるかどうかを示します。

注: このクエリは色域を概算で使っています。 第一に、表示ハードウェアには多くの違いがあります。 例えば、デバイスが「Rec. 2020」対応を主張しても、実際にはその全域よりかなり狭い範囲しか表示できない場合があります。 第二に、デバイスごとに異なる色域が非常に多く、すべて列挙するのは大変です。 多くの場合、著者は表示の正確な能力を知る必要はなく、sRGBより良いか、かなり良いかだけ分かれば十分です。 そのため、適切な画像を色プロファイル付きでユーザーに提供できます。

srgb

UAと出力デバイスが、おおよそsRGB色域以上をサポートできます。

注: 圧倒的多数のカラーディスプレイがこのクエリにtrueを返すと予想されます。

p3

UAと出力デバイスがDCI P3色空間以上の色域をおおよそサポートできます。

注: p3色域はsrgb色域より広く、包含します。

rec2020

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

注: rec2020色域はp3色域より広く、包含します。

下記の表は、各色空間の主色の色度座標（chromaticity coordinates）を示します。定義は[COLORIMETRY]参照。

注: 上記表は色空間を完全に記述する情報は含みませんが、端末がおおよそ各色域をカバーしているかどうか判断するには十分です。 sRGBの詳細は[SRGB]、DCI P3は[SMPTE-EG-432-1-2010]と[SMPTE-RP-431-2-2011]、ITU-R BT.2020は[ITU-R-BT-2020-2]参照。

@media (color-gamut: p3) { … }

注: 出力デバイスの色域が十分広い場合や色域が他の色域の部分集合である場合、複数の値でtrueを返すことがあります。 そのため、この機能は「昇順」で使うのが最適です。(color-gamut: srgb)がtrueの場合にベース値を設定し、(color-gamut: p3)がtrueなら上書き、というようにします。

注: モノクロ表示などsrgb色域すらサポートしない出力デバイスもあります。 それらの判定には、否定のブール型コンテキストでこの機能を使えます：not (color-gamut)

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

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

pointerとhoverは「主」ポインティングデバイスの特性に関係し、 any-pointerやany-hoverは利用可能性のあるすべてのポインティングデバイスの特性を判定できます。

注: この仕様はUAが「主」ポインティングデバイスをどう決定すべきかは定義しませんが、 想定されるのは、UAが端末・環境の知識、利用可能なポインティングデバイスの数や種類、どれが一般的/現在使われているかの知識を組み合わせて判断することです。 端末の主入力がポインティングデバイスでないが、補助的であまり使われないポインティングデバイスがある場合、UAは非ポインティングデバイスを主と見なすこともあります（pointer: none）。 また、UAはユーザー環境やUAの操作方式の変化に応じて主デバイスの種類を動的に変更する場合もあります。

注: pointer、hover、any-pointer、any-hoverは全て、ポインティングデバイスの特性や完全な不在に関するもので、 キーボードなど非ポインティングデバイスの入力の有無は判定できません。 著者は、これらの機能で一致する値にかかわらず、非ポインティング入力が存在する可能性も考慮すべきです。

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

pointerメディア機能は、マウスなどのポインティングデバイスの有無と精度を判定するために使用します。 複数のポインティングデバイスがある場合、 pointerメディア機能はUAによって決定される「主」ポインティングデバイスの特性を反映しなければなりません。 （すべての利用可能なポインティングデバイスの能力を判定するには、any-pointerメディア機能を参照してください。）

none

端末の主な入力手段にポインティングデバイスが含まれていません。

coarse

端末の主な入力手段に精度の低いポインティングデバイスが含まれています。 例：タッチスクリーンやモーションセンサー（XboxのKinectなど）。

fine

端末の主な入力手段に精度の高いポインティングデバイスが含まれています。 例：マウス、タッチパッド、ペン型デジタイザ。

coarseとfineはどちらもポインティングデバイスの存在を示しますが、精度が異なります。 ズーム倍率1で複数の小さな隣接ターゲットを正確に選択するのが難しいデバイスはcoarseとみなされます。 ズームレベルの変更はこのメディア機能の値に影響しません。

注: UAがズーム機能を提供したり、補助的なポインティングデバイスの精度が異なる場合、 ユーザーはこのメディア機能の値がcoarseでも正確なクリックが可能な場合があります。 このメディア機能は「ユーザーが絶対に正確なクリックができない」ことを示すものではなく、「正確なクリックがしづらい」ことを示します。 著者はcoarseの場合、正確なクリックに依存しないページ設計を推奨されます。

アクセシビリティの観点から、ポインティングデバイスがfineでも、 UAはこのメディアクエリにcoarseやnoneを返す場合があります。 これはユーザーがポインティングデバイスの操作が困難であることを示します。 また、主なポインティングデバイスがfineでも、追加でcoarseなポインティングデバイスが利用可能な場合があります。著者は他のcoarseデバイスも考慮して、any-pointerメディア機能も利用するとよいでしょう。

/* 主ポインティングデバイスが精度低い場合はラジオボタン・チェックボックスを大きくする */
@media (pointer:coarse) {
  input[type="checkbox"], input[type="radio"] {
    min-width:30px;
    min-height:40px;
    background:transparent;
  }
}

7.2. ホバー機能：hover機能

hoverメディア機能は、主ポインティングデバイスでページ上の要素をホバーできるかを判定します。 複数のポインティングデバイスがある場合、 hoverメディア機能はUAによって決定される「主」ポインティングデバイスの特性を反映しなければなりません。 （すべての利用可能なポインティングデバイスの能力を判定するには、any-hoverメディア機能を参照してください。）

none

主ポインティングデバイスがホバーできない、またはポインティングデバイスがないことを示します。 例：タッチスクリーン、基本的なペン型デバイス。

ホバーできるが操作が不便で通常の使い方ではない場合もこの値に一致します。 例：タッチスクリーンで長押しがホバー扱いになる場合はhover: noneに一致します。

hover

主ポインティングデバイスでページ上の部位を簡単にホバーできることを示します。 例：マウス、物理的に画面を指すデバイス（Nintendo Wiiコントローラーなど）。

アクセシビリティの観点から、ホバーが可能な端末でも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およびany-hoverメディア機能は、pointerやhoverと同じですが、ユーザーが利用可能なすべてのポインティングデバイスの能力の和（ユニオン）に対応します。 any-pointerの場合、異なる特性のデバイスがあれば複数値が一致します。

any-pointerとany-hoverは、すべてのポインティングデバイスが対応するクエリでnoneに一致する場合、またはポインティングデバイスがまったくない場合のみnoneに一致しなければなりません。

付録A: 非推奨メディア機能

以下のメディア機能は非推奨です。 後方互換性のために残されていますが、新しく記述するスタイルシートには適していません。著者はこれらを使用しないでください。ユーザーエージェントは規定通りサポートしなければなりません。

ビューポート（またはページメディアの場合はページボックス）のサイズを判定するには、width、height、aspect-ratio メディア機能を使用すべきです。 device-width、 device-height、 device-aspect-ratioは、ドキュメントのレイアウトに使える領域とは関係なく、デバイスの物理サイズを指します。 device-* メディア機能はモバイルデバイス検出の代理として使われることもありますが、代わりにスタイリング対象のデバイスの特徴をより適切に表すメディア機能を使うべきです。

device-width

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

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

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

注: デバイスが縦横切替できる場合、例えばポートレートとランドスケープ、 device-*メディア機能は現在の向きを反映します。

device-height

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

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

<link rel="stylesheet" media="(device-height > 600px)" />

device-aspect-ratio

'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) { … }

変更履歴

2020年7月21日候補勧告以降の変更点

• で空の関数を許可（Issue 6803参照）。

• 文法定義の編集上の調整（Issue 6806参照）。

2017年9月5日候補勧告以降の変更点

• speechメディアタイプを非推奨化。 メディアタイプは排他的なので、画面リーダーについては扱えません。 画面リーダーはその名の通り画面描画に基づく動作であり、screenメディアタイプに一致します。 ピュアオーディオUAについては可能性がありましたが、そのような実装は知られていません。
• トークンパースがascii大文字小文字非区別であることを思い出させる注記を構文仕様への参照として追加
• 比較なしの(width 500px)のような形が誤って許可されていた文法バグを修正
• <ratio>の定義を[CSS-VALUES-4]に委譲。 いまやmediaqueries以外でも使われるため。

  注: [CSS-VALUES-4]は定義を <ratio> = <integer> / <integer> から <ratio> = <number [0,∞]> [ / <number [0,∞]> ]?

• 編集上の調整、表現の改善、明確化など複数
• 連続メディア、ページメディアの定義を追加
• overflow-blockのoptional-paged値は、該当する現在のUAがないため削除
• updateをat riskに指定

2017年5月19日作業草案以降の変更点

• 範囲型メディア機能を負値パース不可から負の範囲でfalseとするよう変更
• color-gamutに必要な色空間情報を仕様に直接含めるようにした
• hover、pointer、any-hover、any-pointerをat-riskから外した

Media Queries Level 3以降の変更点

以下は2012年6月19日Media Queries Level 3 勧告以降の変更点です：

• 文書の大幅な編集・再構成
• Boolean-context メディア機能は、キーワードnoneでtrueとなる場合もfalseとなるようになった
• 数値型メディア機能はrange contextで書けるようになった
• pointer、any-pointer、hover、any-hover、update、color-gamut、overflow-block、 overflow-inlineメディア機能の追加
• or、and、only、notはメディアタイプとして認識されない（無効なものとしても）。構文エラーとなる。
• screen、print、speech、all以外のすべてのメディアタイプは非推奨
• device-width、device-height、device-aspect-ratioを非推奨化し、プライバシー・セキュリティ向上のためscreenではなくWeb公開画面領域を参照するようにした
• 場合によってはメディアクエリの評価がスタイルシートの評価に依存する場合がある

謝辞

この仕様はW3C作業グループ「カスケーディングスタイルシート」の成果物です。

Amelia Bellamy-Royds、 Andreas Lind、 Andres Galante、 Arve Bersvendsen、 Björn Höhrmann、 Chris Lilley、 Chris Rebert、 Christian Biesinger、 Christoph Päper、 Dean Jackson、 Elika J. Etemad (fantasai)、 Emilio Cobos Álvarez、 François Remy、 Frédéric Wang、 Greg Whitworth、 Ian Pouncey、 James Craig、 Jinfeng Ma、 Kivi Shapiro、 L. David Baron、 Masataka Yakura、 Melinda Grant、 Michael[tm] Smith、 Nicholas C. Zakas、 Patrick H. Lauke、 Philipp Hoschka、 Rick Byers、 Rijk van Geijtenbeek、 Roger Gimson、 Sam Sneddon、 Sigurd Lerstad、 Simon Kissane、 Simon Pieters、 Steven Pemberton、 Susan Lesch、 Tantek Çelik、 Thomas Wisniewski、 Vi Nguyen、 Xidorn Quan、 Yves Lafon、 そして張俊芝 のコメントによってこの仕様が改善されました。

8. プライバシーとセキュリティの考慮事項

この仕様は新たなセキュリティ考慮事項を導入しません。

メディアクエリはCSSがページ環境の様々な側面を問い合わせることを可能にします。 これはスクリプトでは困難または不可能な情報も含みます。 これは潜在的にプライバシーのリスクとなり、ユーザーのフィンガープリンティングが強化される可能性がありますが、リスクは一般的に低いです。 最低限、同じ情報はユーザーエージェント文字列を調べることでスクリプトから推定可能でなければなりません。 ただし、UA文字列の偽装はメディアクエリには影響しないため、検出手法としてやや強力です。

とはいえ、メディアクエリで得られる情報は比較的粗く、この観点でのエントロピーへの寄与は小さいです。

以下のレガシーメディア機能（device-width、device-height、device-aspect-ratio）は、 UAの実行環境に関する情報を明確なメリットなく露出します。 これらは互換性維持のために残されていますが、プライバシーやセキュリティの観点から、UAは不正確な情報を返しても許容されています。

TAGは、編集者や作業グループが仕様によるリスクを評価するための自己レビュー質問票を作成しました。 回答は以下です。

この仕様は個人識別情報を扱いますか？

いいえ。

この仕様は高価値データを扱いますか？

いいえ。

この仕様はoriginの新しい状態をブラウジングセッションをまたいで保持しますか？

いいえ。

この仕様はウェブへ持続的なクロスオリジン状態を露出しますか？

いいえ。

この仕様は現在originがアクセスできない他のデータを露出しますか？

いいえ。

この仕様は新しいスクリプト実行／ロード機構を可能にしますか？

いいえ。

この仕様はoriginにユーザーの位置情報へのアクセスを許可しますか？

いいえ。

この仕様はoriginにユーザー端末のセンサーへのアクセスを許可しますか？

いいえ。

この仕様はoriginにユーザーのローカル計算環境の側面へのアクセスを許可しますか？

はい、上記本文で説明した通りです。

この仕様はoriginに他デバイスへのアクセスを許可しますか？

いいえ。

この仕様はoriginにユーザーエージェントのネイティブUIを制御する権限を与えますか？

いいえ。

この仕様はウェブへ一時的な識別子を露出しますか？

いいえ。

この仕様はファーストパーティ／サードパーティ文脈の挙動を区別しますか？

いいえ。

この仕様はユーザーエージェントの「シークレットモード」文脈でどのように動作すべきですか？

挙動の変更は不要です。

この仕様はユーザーのローカル端末にデータを永続化しますか？

いいえ。

この仕様には「セキュリティの考慮事項」および「プライバシーの考慮事項」セクションがありますか？

はい、このセクションが該当します。

この仕様はデフォルトのセキュリティ特性をダウングレードすることを許可しますか？

いいえ。