メディアクエリ レベル 5

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] を拡張し、それらに取って代わります。 これらはさらに、CSS 2 § 7 メディア型を基にして置き換えたものです。

1.2. 値

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

1.3. 単位

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

メディアクエリにおける相対長単位は、初期値に基づきます。 これは、単位が宣言の結果に基づくことは決してないことを意味します。

注: 例えばHTMLでは、 em単位は、初期値 に対して相対的であり、 それはユーザーエージェントまたはユーザーの設定によって定義される font-size の初期値であって、 ページ上のいかなるスタイリングでもありません。 これにはまた、ユーザーが適用しうる追加の制約（最小フォントサイズなど）も考慮される点に注意してください。

2. メディアクエリ

メディアクエリは、 文書が表示されているユーザーエージェント またはデバイスの特定の側面をテストする方法です。メディアクエリは（ほぼ）常に文書の内容から独立しており、 そのスタイリング、 またはその他の内部的な側面には依存しません。 別の特性が、メディアクエリの解決に影響すると明示的に規定していない限り、 それらは「外部」の情報にのみ依存します。

メディアクエリの構文は、 任意のメディアクエリ修飾子、 任意のメディア型、 および0個以上のメディア特性 から構成されます:

メディアクエリは、 trueまたはfalseのいずれかとなる論理式です。 メディアクエリがtrueとなるのは、次の場合です:

• （指定されている場合）メディア型が、 ユーザーエージェントが動作しているデバイスのメディア型に一致し、かつ

• メディア条件がtrueである。

本節におけるメディアクエリに関する記述は、構文の節に従っていることを前提とします。 構文に適合しないメディアクエリは、§ 3.2 エラー処理で扱います。 すなわち、構文が本節の要件に優先します。

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

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

ユーザーエージェントは、把握しているユーザー環境の変化に応じて、 メディアクエリを再評価しなければなりません。 例えば、デバイスが横向きから縦向きへ切り替えられた場合などです。 そして、それらメディアクエリに依存するあらゆる構成要素の挙動を、 それに応じて変更しなければなりません。

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

2.1. メディアクエリの結合

複数のメディアクエリは、 カンマ区切りのメディアクエリリストへ結合できます。

メディアクエリリストは、 構成要素であるメディアクエリのうちいずれかがtrueであればtrueとなり、 構成要素であるメディアクエリのすべてがfalseのときにのみfalseとなります。

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

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

@media all { … }
@media { … }

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

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

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

個々のメディアクエリは、 キーワード not を前置することで、 結果を否定できます。 通常trueと評価されるメディアクエリは、 notを前置するとfalseになり、 その逆も同様です。

<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 のような別のメディアクエリ修飾子を伴うものは、 レガシーなユーザーエージェントによって自動的にfalseとして扱われます。

注: 本仕様の公開時点では、 そのようなレガシーなユーザーエージェントは極めて稀であると見込まれており、 only 修飾子の使用が必要となることは、ほとんど、あるいは全くありません。

2.3. メディア型

メディア型は、 文書が表示されうるユーザーエージェントのデバイスの大まかなカテゴリです。 元のメディア型の集合はHTML4で定義され、 <link>要素のmedia属性のためのものでした。

残念ながら、メディア型は、 異なるスタイリングの必要を持つデバイスを区別する方法として不十分であることが明らかになりました。 元々はかなり明確に区別されていたカテゴリ、例えばscreenとhandheldは、 発明以降の年月で著しく混ざり合ってきました。 一方で、ttyやtvのようなものは、 フル機能のコンピュータモニタという標準から見て有用な違いを露出し、 異なるスタイリングで対象化するのに潜在的に有用ですが、 メディア型が相互排他的であるという定義のために、 それらを合理的に用いることが難しくなっています。 代わりに、それらの排他的な側面は、 メディア特性（例えばgridやscan）として表現する方が適切です。

このため、次のメディア型が、 メディアクエリで使用するために定義されます:

all

すべてのデバイスに一致します。

print

プリンタ、および印刷表示の再現を意図したデバイス（例えば「印刷プレビュー」で文書を表示するWebブラウザ）に一致します。

screen

print に一致するもの以外のすべてのデバイスに一致します。

さらに、次の非推奨のメディア型が定義されます。 著者はこれらのメディア型を使用してはなりません。 代わりに、スタイル適用の対象としているデバイスの側面をより適切に表す、 適切なメディア特性を選択することが推奨されます。

ユーザーエージェントは、次のメディア型を妥当として認識しなければなりませんが、 それらが何にも一致しないようにしなければなりません。

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

注: すべてのメディア型は、重要な違いを捉える適切なメディア特性が定義され次第、 いずれ非推奨となることが見込まれています。

2.4. メディア特性

メディア特性は、 メディア型よりも細かい粒度のテストであり、 ユーザーエージェントまたは表示デバイスの単一の特定の特性をテストします。

構文的には、メディア特性はCSSプロパティに似ています。 すなわち、特性名、コロン、およびテストする値から構成されます。 また、特性名だけのブール形式、 あるいは比較演算子を伴う範囲形式で書くこともできます。

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

• プロパティは文書をどのように提示するかに関する情報を与えるために使用されます。 メディア特性は出力デバイスの要件を記述するために使用されます。
• メディア特性は常に括弧で囲まれ、 andまたはorキーワードで結合されます。 例えば(color) and (min-width: 600px)のように、 セミコロンで区切るのではありません。
• メディア特性は、名前だけ（コロンと値を省略）で与えられ、 特性をブール文脈で評価できます。 これは、0または「none」を表す妥当な値を持つ特性に対する便利な略記です。 例えば、(color)は、 color メディア特性が 0でない場合に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つの値は比較でき、どちらが小さくどちらが大きいかを判断できます。

この2つの型の唯一の重要な違いは、「range」メディア特性が範囲文脈で評価でき、 その名前に「min-」および「max-」接頭辞を受け入れられることです。 これらのいずれかを行うと特性の意味が変わります—​すなわち、 メディア特性が与えられた値に正確に一致するときにtrueとなるのではなく、 その値以上/以下/等しいときに一致します。

2.4.2. ブール文脈におけるメディア特性の評価

メディア特性は通常CSSプロパティに似た構文を持ちますが、 (color)のように、 特性名だけとしてより単純に書くこともできます。

このように書かれた場合、メディア特性は ブール文脈で評価されます。 特性が、数0以外の任意の値、 値0を持つ<dimension>、 キーワードnone、 または、そのメディア特性によりブール文脈でfalseと評価されると明示的に定義された値 に対してtrueとなる場合、 メディア特性はtrueと評価されます。 そうでなければfalseと評価されます。

2.4.3. 範囲文脈におけるメディア特性の評価

「range」型のメディア特性は、 値に順序があるという事実を活用する範囲文脈で別の書き方もでき、 通常の数学的比較演算子を用います:

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

特性名、 比較演算子、 および値からなる基本形は、 その関係が真である場合にtrueを返します。

残りの形式、すなわち 特性名が2つの値比較の間に入れ子になっている形式は、 両方の比較が真である場合にtrueを返します。

「range」型のいくつかのメディア特性は、負の範囲ではfalseであるとされます。 これは、負の値が妥当でありパースされなければならないこと、 そして、そのような負の値のいずれかに対してメディア特性が等しい／より小さい／以下であるかどうかを問い合わせると、 falseと評価されなければならないことを意味します。 メディア特性が負の値より大きい、または以上であるかどうかを問い合わせる場合、 その関係が真であればtrueと評価されます。

注: もし負の値がパース時に拒否されていたなら、 代わりにエラー処理規則に基づいてunknownとして扱われていたでしょう。 しかし実際には、デバイスのresolutionが-300dpiであるかどうかはunknownではなく、 falseであることが分かっています。 同様に、任意の視覚デバイスに対して、対象となる表示領域の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-」接頭辞の使用

上で述べたように「range」型のメディア特性を範囲文脈で評価するのではなく、 特性は通常のメディア特性として書けますが、 特性名に「min-」または「max-」接頭辞を付けます。

これは、次のとおり、その特性を範囲文脈で評価することと等価です:

• 特性名に「min-」接頭辞を付けることは、「>=」演算子を用いることと等価です。 例えば、(min-height: 600px)は(height >= 600px)と等価です。
• 特性名に「max-」接頭辞を付けることは、「<=」演算子を用いることと等価です。 例えば、(max-width: 40em)は(width <= 40em)と等価です。

注: 「min-」と「max-」はいずれも、 値を含む範囲比較に相当するため、 ある状況では制限となる場合があります。

@media (max-width: 320px) { /* styles for viewports <= 320px */ }
@media (min-width: 321px) { /* styles for viewports >= 321px */ }

@media (max-width: 320px) { /* styles for viewports <= 320px */ }
@media (min-width: 320.01px) { /* styles for viewports >= 320.01px */ }

@media (width <= 320px) { /* styles for viewports <= 320px */ }
@media (width > 320px) { /* styles for viewports > 320px */ }

「discrete」型のプロパティは「min-」または「max-」接頭辞を受け入れません。 「discrete」型のメディア特性にそのような接頭辞を追加すると、 単に未知の特性名になります。

min/max接頭辞付きメディア特性をブール文脈で評価しようとすることは無効であり、構文エラーです。

2.5. メディア特性の結合

複数のメディア特性は、 完全なブール代数（not, and, or）を用いて メディア条件へ結合できます。

• 任意のメディア特性は、その前にnotを置くことで否定できます。 例えば、not (color)は(color)の意味を反転します—​(color)は何らかのカラー表示を持つデバイスに一致するため、 not (color)は、何らかのカラー表示を持たないデバイスに一致します。

• 2つ以上のメディア特性は、 それらのメディア特性のすべてがtrueのときにのみ問い合わせがtrueとなるように、 それらの間にandを置いて連結できます。 例えば、(width < 600px) and (height < 600px)は、 画面の両次元が600pxより小さいデバイスにのみ一致します。

• 代わりに、2つ以上のメディア特性は、 それらのメディア特性のいずれかがtrueであれば問い合わせがtrueとなるように、 それらの間にorを置いて連結できます。 例えば、(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)のいずれかになります。 これら2つは非常に異なる意味を持ちます: (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>? ) ] | [ ( <any-value>? ) ]

<media-type>生成規則には、キーワードonly、 not、and、or、およびlayerは含まれません。

注: layerが除外されているのは、 そうでなければ、@import url(…) layer; という構文が、カスケードレイヤーのために用いられる場合に曖昧となるからです。 [CSS-CASCADE-5]を参照してください。

“<”または“>”の<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-and>の子項であるすべての<media-in-parens>がtrueならtrue、 これらの<media-in-parens>項のうち少なくとも1つがfalseならfalse、 それ以外の場合はunknownです。

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

結果は、<media-in-parens>の子項と、 <media-or>の子項であるすべての<media-in-parens>がfalseならfalse、 これらの<media-in-parens>項のうち少なくとも1つがtrueならtrue、 それ以外の場合はunknownです。

<general-enclosed>

結果はunknownです。

著者は、スタイルシート内で<general-enclosed>を使用してはなりません。これは将来互換性のためにのみ存在しており、 新しい構文追加が、古いユーザーエージェントにおける<media-condition>を過度に無効化しないようにするためのものです。

<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>、 または、そのメディア特性の値構文に一致しない特性値は、 “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) { … }

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

overflow-blockメディア特性は、 ブロック軸において 内容が初期包含ブロックからあふれたときの、デバイスの挙動を記述します。

none

ブロック軸におけるオーバーフローのための手段はありません。 あふれた内容は単に表示されません。 例: 看板

scroll

ブロック軸であふれた内容は、 ユーザーがスクロールして到達できるようにすることで露出されます。 例: コンピュータ画面

paged

内容は離散的なページに分割されます。 ブロック軸で1ページからあふれた内容は次のページに表示されます。 例: プリンタ、電子書籍リーダー

noneまたはscrollに一致するメディアは、 連続メディアであるとされ、 pagedに一致するものはページメディアであるとされます

注: このメディア特性の追加の値は、 連続とページメディアの側面を組み合わせた ハイブリッドな挙動を持つユーザーエージェントのクラスを記述するために、 将来追加される可能性があります。 例えば、Prestoレイアウトエンジン（現在は廃止）は、 強制改ページを尊重する点を除けばcontinuousに似た、半ページ分割のプレゼンテーションモード挙動を備えていました。 現在出荷されているユーザーエージェントでこの種の挙動を持つものを把握していないため、 Working Groupは、このレベルではそのような値を追加しないことを決定しました。 それにより、そのようなユーザーエージェントを誤って特徴付けることを避けます。 上で指定されたいずれの値でも十分に記述できないユーザーエージェントを実装する人は、 このメディア特性の拡張が検討できるよう、 Working Groupに連絡することが推奨されます。

4.6. インライン軸のオーバーフロー: overflow-inline 特性

overflow-inlineメディア特性は、 インライン軸において 内容が初期包含ブロックからあふれたときの、デバイスの挙動を記述します。

none

インライン軸におけるオーバーフローのための手段はありません。 あふれた内容は単に表示されません。

scroll

インライン軸であふれた内容は、 ユーザーがスクロールして到達できるようにすることで露出されます。

注: インライン方向にはみ出した内容をページ送りで表示するオーバーフローについて、 既知の実装はありません。 そして、その概念自体もあまり意味があるようには見えないため、 overflow-inlineには意図的にpaged値がありません。

4.7. 水平方向ビューポートセグメント: horizontal-viewport-segments 特性

horizontal-viewport-segmentsメディア特性は、 ビューポートを水平方向に見たときの論理セグメントの数を記述します。

horizontal-viewport-segmentsメディア特性は、 負の範囲ではfalseです。

ビューポートが、1つ以上のハードウェア機構（例えば別々のディスプレイの間にある折り目やヒンジなど）によって分割され、 それらが論理的な区切りとして機能する場合、 セグメントとは、ページが論理的に別個のものとして扱えるビューポート領域です。

4.8. 垂直方向ビューポートセグメント: vertical-viewport-segments 特性

vertical-viewport-segmentsメディア特性は、 ビューポートを垂直方向に見たときの論理セグメントの数を記述します。

vertical-viewport-segmentsメディア特性は 負の範囲ではfalseです。

@media (horizontal-viewport-segments: 2) and (vertical-viewport-segments: 1) { … }

4.9. 表示モード: display-mode メディア特性

display-modeメディア特性は、 現在の閲覧コンテキストが エンドユーザーに対して現在どのようなモードで提示されているかを記述します。 子の閲覧コンテキストでは、表示モードは、 トップレベルの閲覧コンテキストのそれに一致しなければなりません。

この特性は主として、ユーザーエージェントが アプリケーションコンテキストに適用した どの表示モードであるかを判定するために使用されます。 そのため、この特性の値は、[APPMANIFEST]で定義される表示モードに対応します。 ただし、これは非アプリケーションの文脈においても、 ビューポートがfullscreenやpicture-in-pictureなどの他のモードにあるかどうかを判定するために使用できます。

fullscreen

閲覧コンテキストは、ブラウザUI要素を隠して表示され、利用可能な表示領域の全体を占めます。 fullscreenコンテキストは、fullscreen表示モード（アプリケーションマニフェストにおける）により引き起こされた可能性がありますし、 Fullscreen APIのrequestFullscreen() メソッドにより引き起こされた可能性もあります。 あるいは、他の手段（例えばユーザーがユーザーエージェント組み込みの制御を使って手動でfullscreenモードを有効化するなど）による可能性もあります。

fullscreen表示モードに対応します。

standalone

standalone表示モードが使用中です。 アプリケーションコンテキストでのみ適用されます。

minimal-ui

minimal-ui表示モードが使用中です。 アプリケーションコンテキストでのみ適用されます。

browser

閲覧コンテキストは、ユーザーエージェントにおいてハイパーリンクを開くためのプラットフォーム固有の慣例に従って表示されます （例: ブラウザタブ、またはアドレスバーなどの制御を備えたWebブラウザウィンドウ）。 これは、他の表示モードが適切でない非アプリケーションコンテキストで使用されるべきです。

browser表示モードに対応します。

picture-in-picture

このモードは、ユーザーがデバイス上で他のサイトやアプリケーションとやり取りしながら、 メディアの視聴を継続できるようにします。 閲覧コンテキストは、浮遊し常に最前面に表示されるウィンドウで提示されます。 ユーザーエージェントは、プラットフォーム固有の他のUI要素 （例えば「back-to-tab」や「site information」ボタンなど、またはプラットフォームとユーザーエージェントにおいて慣習的なもの）を含める場合があります。

{
  "display": "standalone"
}

@media (display-mode: standalone) { … }

/* ビューポートがfullscreenのときに適用 */
@media (display-mode: fullscreen) { … }

/* 要素がfullscreenのときに適用 */
#game:fullscreen { … }

注: このメディア特性の追加の値は、 [APPMANIFEST]に追加される新しい表示モードに一致するために、 将来追加される可能性があります。

5. 表示品質のメディア特性

5.1. 表示解像度: resolution 特性

resolutionメディア特性は、出力デバイスの解像度、すなわちピクセル密度を記述します。 これはページズームを考慮しますが、 スケール係数を1.0であると仮定します。

resolutionメディア特性は負の範囲ではfalseです

非正方形ピクセルを持つメディアを問い合わせる場合、resolutionは垂直方向の密度を問い合わせます。

プリンタの場合、これはスクリー二ング解像度 （任意の色の印刷ドットに対する解像度）に対応します。 プリンタは、グレースケール印刷に対して異なる解像度を持つ場合があります。

解像度に物理的な制約がない出力媒体（例えばベクターグラフィックスへの出力など）では、 この特性はinfinite値に一致しなければなりません。 このメディア特性を範囲文脈で評価する目的では、 infiniteは、考え得るいかなる<resolution>よりも大きいものとして扱われなければなりません。 （すなわち、(resolution > 1000dpi)のような問い合わせは、infiniteなメディアに対してtrueになります。）

@media (resolution >= 2dppx)

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

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

5.2. 表示種別: scan 特性

scanメディア特性は、いくつかの出力デバイスにおける走査処理を記述します。

interlace

CRTおよび一部種類のプラズマTV画面は「インターレース」レンダリングを使用しており、 映像フレームが、画面上の「偶数」ラインのみを指定するものと 「奇数」ラインのみを指定するものとで交互になっていました。 これは、滑らかな動きを生成するために、さまざまな自動的な心的イメージ補正能力を利用するものです。 これにより、帯域幅コストを半分に抑えつつ、より高いFPSの放送を擬似的に実現できました。

インターレース画面で表示する場合、 著者は「コーミング」を避けるために画面上を非常に速く横切る動きを避けるべきであり、 また「twitter」を避けるために画面上の細部が1pxより広いことを確保すべきです。

progressive

「プログレッシブ」レンダリングを使用する画面は、各画面を完全に表示し、 特別な取り扱いを必要としません。

ほとんどの現代的な画面、およびすべてのコンピュータ画面は、プログレッシブレンダリングを使用します。

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

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

5.3. コンソール表示の検出: grid 特性

gridメディア特性は、出力デバイスがグリッドかビットマップかを問い合わせるために使用されます。 出力デバイスがグリッドベースである場合 （例: 「tty」端末、または固定フォントが1つしかない電話ディスプレイ）、 値は1になります。 それ以外の場合、値は0になります。

<mq-boolean>値型は、値が0または1である<integer>です。 他の整数値はすべて無効です。CSSでは-0は常に0と等価であるため、 妥当な<mq-boolean>値としても受け入れられます。

注: <mq-boolean>型は、レガシー目的のためにのみ存在します。 もしこの特性が今日設計されるのであれば、 値に対して適切な名前付きキーワードを代わりに使用するでしょう。

@media (grid) and (max-width: 15em) { … }

注: 執筆時点では、既知のすべての実装はgrid: 1ではなくgrid: 0に一致します。

5.4. 表示更新頻度: update 特性

updateメディア特性は、 一度レンダリングされた後にコンテンツの見た目を変更できる出力デバイスの能力を問い合わせるために使用されます。 次の値を受け入れます:

none

一度レンダリングされると、レイアウトはそれ以上更新できません。 例: 紙に印刷された文書。

slow

レイアウトは、CSSの通常の規則に従って動的に変化し得ますが、 出力デバイスは変化を滑らかなアニメーションとして知覚できるほど十分に速くレンダリングまたは表示できません。 例: E-ink画面、または極端に非力なデバイス。

fast

レイアウトは、CSSの通常の規則に従って動的に変化し得て、 出力デバイスは速度の点で特別に制約されているわけではないため、 CSS Animationsのような定期的に更新されるものを使用できます。 例: コンピュータ画面。

@media (update) {
  a { text-decoration: none; }
  a:hover, a:focus { text-decoration: underline; }
}
/* In non-updating UAs, the links get their default underline at all times. */

5.5. 表示技術の検出: environment-blending 特性

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メディア特性は、出力デバイスにおける各色成分あたりのビット数を記述します。 デバイスがカラーデバイスでない場合、値は0です。

colorは負の範囲ではfalseです。

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

@media (color >= 8) { … }

異なる色成分が異なるビット数で表現される場合、最も小さい数が使用されます。

インデックスカラーを持つデバイスでは、 ルックアップテーブルにおける各色成分あたりの最小ビット数が使用されます。

注: 記述された機能は、色の能力を表層的なレベルでしか記述できません。 color-gamutは、一般に著者の必要性とより関連します。 さらなる機能が必要な場合、 RFC2879 [RFC2879]は、 後の段階でサポートされる可能性がある、より具体的なメディア特性を提供します。

6.2. パレット式カラースクリーン: color-index 特性

color-indexメディア特性は、 出力デバイスの色ルックアップテーブルにおけるエントリ数を記述します。 デバイスが色ルックアップテーブルを使用しない場合、値は0です。

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メディア特性は、 モノクロフレームバッファにおけるピクセルあたりのビット数を記述します。 デバイスがモノクロデバイスでない場合、 出力デバイスの値は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より著しく良いかを知れれば十分です。 そうすることで、著者は色プロファイルを付けた適切な画像をユーザーに提供できます。

srgb

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

注: 色表示の大多数は、この種類の問い合わせに対してtrueを返せると予想されます。

p3

UAおよび出力デバイスは、Display P3 [Display-P3] Color Spaceで指定される色域以上を、おおよそサポートできます。

注: p3色域は、 srgb色域より大きく、かつそれを含みます。

rec2020

UAおよび出力デバイスは、ITU-R Recommendation BT.2020 Color Spaceで指定される色域以上を、おおよそサポートできます。

注: rec2020色域は、 p3色域より大きく、かつそれを含みます。

次の表は、[COLORIMETRY]で定義される色空間の色度座標により、 これら色空間の原色を列挙します。

注: 上の表は色空間を完全に記述するのに十分な情報を含みませんが、 出力デバイスがそれぞれの色域をおおよそカバーするかどうかを判断するには十分です。 sRGBについての詳細は[SRGB]を、 Display P3についての詳細は[Display-P3]を、 ITU-R Recommendation BT.2020についての詳細は[ITU-R-BT-2020-2]を参照してください。

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

注: 出力デバイスの出力色域が十分に大きい場合、 またはある色域が別のサポートされる色域の部分集合である場合、 このメディア特性の複数の値に対してtrueを返すことがあります。 その結果、この特性は「昇順」の形で使用するのが最適です—​まず(color-gamut: srgb)がtrueのときに基準値を設定し、 次に(color-gamut: p3)がtrueであればそれを上書きする、といった具合です。

注: モノクロディスプレイのような一部の出力デバイスは、 srgb色域さえサポートできません。 これらのデバイスをテストするには、 否定したブール文脈の形でこの特性を使用できます: not (color-gamut)。

6.5. ダイナミックレンジ: dynamic-range 特性

dynamic-rangeは、 ユーザーエージェントおよび出力デバイスがサポートする最大輝度・色深度・コントラスト比の組み合わせを表します。

high

ユーザーエージェントおよび出力デバイスは、次のすべての基準を満たします:

• 高いピーク輝度をサポートする

• 高いコントラスト比をサポートする

• 色深度が24ビットを超える、またはRGBの各色成分あたり8ビットを超える

注: 一部のデバイスは、高ダイナミックレンジ能力を持っていても常時オンではなく、 有効化が必要です （プログラムによる場合もあれば、ユーザーによる場合もあり、コンテンツに基づく場合もあります）。 このメディア特性は、そのようなモードが有効かどうかをテストするのではなく、 デバイスが高ダイナミックレンジの視覚表現に対応可能かどうかだけをテストします。

standard

この値は、任意の視覚デバイスに一致し、 視覚能力を欠くデバイスには一致しません。

注: このメディア特性の複数の値が同時に一致する場合があります: highに一致するユーザーエージェントは、 standardにも一致します。

6.5.1. 表示のコントラストと輝度の決定

ピーク輝度は、 LCD画面のような発光デバイスが生成できる最も明るい点がどれほど明るいか、 または紙やe-inkのような反射型デバイスの場合には、 光を最も吸収しない点を指します。

注: 一部のデバイスは、短時間のみ、または任意の時点で表面のごく一部においてのみ、 ピーク輝度を生成できます。

コントラスト比は、 システムが生成できる最も明るい色の輝度と最も暗い色の輝度の比です。

本仕様は、これらの特性を測定するための正確な方法を定義しません。 また、ユーザーエージェントが コントラスト比に関して何が高いと見なされるか、 およびピーク輝度に関して何が高いと見なされるかを決定できるようにします。 それでもなお、ユーザーエージェントは次の意図に従うよう試みなければなりません: 高いピーク輝度に対応するデバイスは、 「白より明るい」ハイライトを表示でき、 かつ深い黒を提示しつつ同時にそれを行える能力 （全体として明るいが白っぽく洗い流された画像ではなく） は、高いコントラスト比を示すものです。

注: dynamic-rangeおよびvideo-dynamic-rangeの判定はユーザーエージェントによって異なり得ますが、 おおむね信頼できる意味論を持つことが期待されます。

6.6. 表示上の反転色の検出: inverted-colors 特性

inverted-colorsメディア特性は、 コンテンツが通常どおり表示されているか、 あるいは色が反転されているかを示します。

注: これは、ユーザーエージェントまたは下層のオペレーティングシステムが、すべての色を強制的に反転したことを示すものであり、そうすることを要求するものではありません。 これは簡単なアクセシビリティ機能として提供されることがあり、 ユーザーが明るい背景に暗い文字（dark-on-light）と暗い背景に明るい文字（light-on-dark）を切り替えられるようにします。 しかし、画像が反転されたり、 影がハイライトになったりするなどの不快な副作用があり、 それによってコンテンツの可読性が低下します。

none

色は通常どおり表示されます。

inverted

表示領域内のすべてのピクセルが反転されています。

この値は、ユーザーエージェントが画像を保持するような、何らかのコンテンツ認識型反転を行った場合には一致してはなりません。

注: これは、このメディア特性の目的が、 すべてのピクセルを反転する非コンテンツ認識型アプローチの望ましくない影響を緩和できるようにすることだからです。 著者がコンテンツ認識型の場合にまで対策を講じてしまうと、 著者の対策と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. インタラクションに関するメディア特性

「interaction」メディア特性は、ユーザーがページとどのように相互作用するかのさまざまな側面を反映します。

pointer と hover 特性は「主」ポインティングデバイスの特性に関係し、 一方で any-pointer と any-hover は、 利用可能性のあるすべてのポインティングデバイスの特性を問い合わせるために使用できます。

注: 本仕様は、ユーザーエージェントがどのようにして「主」ポインティングデバイスを決定すべきかを定義しませんが、 期待されるのは、ユーザーエージェントがこれを、 動作しているデバイス/環境に関する知識、 利用可能なポインティングデバイスの数と種類、 そしてそれらのうちどれが一般的に、または現在使用されているかという概念 を組み合わせて判定することです。 デバイスの主要入力機構がポインティングデバイスではないが、 二次的（かつ使用頻度の低い）入力としてポインティングデバイスが存在する状況では、 ユーザーエージェントは非ポインティングデバイスを主として扱うことを決める場合があります（その結果 'pointer: none' となります）。 ユーザーエージェントはまた、 ユーザー環境の変化や、 ユーザーがUAとどのように相互作用しているかの変化に応じて、 どの種類のポインティングデバイスが主であると見なされるかを動的に変更することを決める場合もあります。

注: pointer、hover、any-pointer、およびany-hover特性は、 ポインティングデバイスの特性、またはそれが完全に存在しないことにのみ関係し、 キーボードのような非ポインティングデバイス入力機構の存在を検出するためには使用できません。 著者は、これらの特性を問い合わせた結果どの値に一致したかにかかわらず、 非ポインティングデバイス入力が存在する可能性を考慮すべきです。

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

pointerメディア特性は、 マウスのようなポインティングデバイスの有無と精度を問い合わせるために使用されます。 複数のポインティングデバイスが存在する場合、 pointerメディア特性は、 ユーザーエージェントによって決定される「主」ポインティングデバイスの特性を反映しなければなりません。 （利用可能なポインティングデバイスのいずれかの能力を問い合わせるには、 any-pointerメディア特性を参照してください。）

none

デバイスの主入力機構にポインティングデバイスが含まれません。

coarse

デバイスの主入力機構に、精度が限定されたポインティングデバイスが含まれます。 例としてはタッチスクリーンや動体検出センサー（Xbox用Kinect周辺機器など）があります。

fine

デバイスの主入力機構に、精度の高いポインティングデバイスが含まれます。 例としてはマウス、タッチパッド、描画用スタイラスなどがあります。

coarse と fine はどちらも ポインティングデバイスの存在を示しますが、精度が異なります。 ズーム係数1の状態で、隣接する複数の小さなターゲットのうち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メディア特性は、 ユーザーエージェントによって決定される「主」ポインティングデバイスの特性を反映しなければなりません。 （利用可能なポインティングデバイスのいずれかの能力を問い合わせるには、 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に一致しなければなりません。

7.4. UAが提供するナビゲーションコントロールの検出: nav-controls 特性

nav-controlsメディア特性は、 ユーザーエージェントがそのユーザーインターフェースの一部として 明らかに見つけやすいナビゲーションコントロールを提供しているかどうかを、 著者が知ることを可能にします。

注: 従来のブラウザは通常そのようなコントロールを提供しており、 Webページは通常それを気にする必要がありませんでしたが、 ある種の文脈では、Webアプリケーションは、いわゆるweb-viewを通じて実行され、 それらは必ずしもフル機能のユーザーインターフェースを備えていません。 そのため、著者にとっては、 ユーザーエージェントから何が提供されているかを知ることが有用であり、 見つけやすい代替手段を提供する必要があるかどうかを検討できます。

この文脈で、明らかに見つけやすいとは、 ボタンのようにユーザーインターフェース上で直接見えるコントロール、 またはそのデバイスのユーザーインターフェースとして典型的で、 ユーザーが容易に識別できる他の形態のコントロールを指します。 視覚的ユーザーインターフェースの場合、 通常は可視のコントロールになりますが、 音声または触覚ユーザーインターフェースの場合には別のものになり得ます。 重要なのは、これはキーボードショートカットやジェスチャーのことではないという点です。 これらがどれほど便利であっても、 （視覚UIの場合に）ユーザーエージェントを見ただけで明らかに見つけられるものではありません。

次の値が妥当です:

none

ユーザーエージェントは、明らかに見つけやすいナビゲーションコントロールを何も持たず、 とりわけ、ユーザーエージェントがページの直前のセッション履歴エントリへ戻ることを引き起こすものはありません。

back

ユーザーエージェントはナビゲーションコントロールを提供し、 少なくとも、ユーザーエージェントがページの直前のセッション履歴エントリへ戻ることを引き起こす 明らかに見つけやすいコントロール（通常は「戻る」ボタン）を含みます。

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

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

明らかに見つけやすいコントロールが有効かどうかは、 このメディア特性の評価に影響しません。

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

一部のユーザーエージェント（多くのテレビを含む）は、ビデオとグラフィックを二つの 別個の「プレーン」（bi-plane）として、それぞれ異なる画面特性でレンダリングします。ビデオプレーンを 記述するために、ビデオ接頭辞付きの機能群が提供されています。

任意の bi-plane 実装は、次の機能についてビデオプレーンに基づく値を返さなければなりません: video-color-gamut; video-dynamic-range。 その他の全ての機能はグラフィックスプレーンに基づく値を返さなければなりません。

bi-plane でない実装は、ビデオ接頭辞付き機能と接頭辞なしの対応する機能に対して同じ値を返さなければなりません。

8.1. ビデオカラー表示品質: the video-color-gamut feature

The video-color-gamut メディア機能は、 ユーザーエージェントと出力機器のビデオプレーンがサポートするおおよその色域を記述します。 つまり、UA が指定された色空間の色を含むコンテンツを受け取った場合に、 出力機器で適切な色または十分に近いものをレンダリングできることを意味します。

値と色空間の定義は color-gamut と同じです。

8.2. ビデオダイナミックレンジ: the video-dynamic-range feature

video-dynamic-range は、 UA と出力機器のビデオプレーンがサポートする最大輝度、色深度、およびコントラスト比の組み合わせを表します。

サポートされる値は dynamic-range と同じです。

9. スクリプト用メディア機能

9.1. スクリプトサポート: the scripting feature

The scripting メディア機能は、JavaScript のようなスクリプト言語が 現在の文書でサポートされているかどうかを照会するために使用されます。

enabled

ページのスクリプトがユーザーエージェントによってサポートされており、 現在の文書におけるスクリプトが文書の寿命の間有効であることを示します。

initial-only

ページのスクリプトがユーザーエージェントによってサポートされており、 現在の文書では初回読み込み時にスクリプトが有効であるが、その後はサポートされないことを示します。 例としては印刷用ページや、サーバー側でページをレンダリングしてほとんど静的なバージョンを送る プリレンダリングプロキシなどがあります。

initial-only と主張する前に満たすべき 明示的な最低閾値を設けるべきか、という問題があります。 閾値があれば著者は依存できる条件が分かりやすくなり、スクリプトをそれに合わせて調整できます。 一方で、その閾値を特定するのは困難です。閾値が低すぎると、著者が依存できるスクリプト機能が 実用的に制限されてしまう可能性がありますが、逆に高すぎると読み込み時にスクリプトを 有効にする UA を除外してしまうかもしれません。 たとえば保守的な定義は少なくともすべてのインラインスクリプトを実行し DOMContentLoaded イベントを 発火することを含むでしょう。しかし、多く（あるいはほとんどの）initial-only UA が外部スクリプト（async や defer を含む）をロードし load イベントを発火する場合、 それに制限してしまうのは現実的でないかもしれません。 他方で外部スクリプトのロードを必須にし load イベントの発火を要求すると、 Opera mini のようにタイムアウトやその他のヒューリスティクスにより外部スクリプトを 実行しない場合の UA を除外する可能性があります。 [Issue #503]

none

この文書に対して UA がスクリプトを実行しないことを示します; スクリプト言語をサポートしていないか、 現在の文書ではサポートが有効でないためです。

一部のユーザーエージェントはスクリプトをスクリプト単位やドメイン単位でオフにする機能を持ち、 特定の文書内で一部のスクリプトのみを実行できる場合があります。 scripting メディア機能は、どのスクリプトが許可されるかを 細かく検出することを許容しません。 このようなシナリオでは、同一ドメイン起源のスクリプトが実行可能であれば scripting メディア機能の値は enabled か initial-only にすべきであり、 そうでなければ none にするべきです。

注意: 将来の CSS レベルでは、このメディア機能を拡張して どのスクリプトが実行可能かをより細かく検出できるようになるかもしれません。

10. カスタムメディアクエリ

メディアクエリを使用する文書を設計する際、同じメディアクエリが複数の場所で使用されることがあり、 例えば複数の @import 文を修飾する場合があります。 同じメディアクエリを繰り返すことは編集上の危険を生みます; 著者が変更を行う場合、すべてのコピーを同じように編集しなければならず、 そうでなければ CSS に見つけにくいバグが生じます。

これを緩和するために、本仕様は カスタムメディアクエリ を定義する方法を定めています。 これは長く複雑なメディアクエリのための単純な名前の別名です。 このようにして、複数箇所で使用されるメディアクエリは カスタムメディアクエリ に割り当てられ、 どこでもそれを使用でき、メディアクエリの編集は一行だけ触れば済むようになります。

A custom media query は @custom-media ルールで定義されます:

@custom-media = @custom-media <extension-name> [ <media-query-list> | true | false ] ;

<extension-name> はその後 メディア機能 で使えます。 それは 必ず ブール文脈 で使わなければなりません; 通常文脈や レンジ文脈 で使うと構文エラーです。 <media-query-list> が与えられた場合、 その カスタムメディアクエリ は、 それが表す <media-query-list> が true と評価されると true を返し、 そうでなければ false を返します。 true または false が与えられた場合、 その カスタムメディアクエリ はそれぞれ true または false と評価されます。

/* --modern targets modern devices that support color or 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> を宣言している場合、 真偽値は最後の宣言のみを基に決まり、同じ <extension-name> の以前の宣言は無視されます。

注意: エラー処理の観点から、未定義の メディア機能 は false と評価される メディア機能 とは異なります。 詳細は Media Queries 4 § 3.2 Error Handling を参照してください。

@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. CSSOM

The CSSCustomMediaRule インターフェイスは @custom-media ルールを表します。

typedef (MediaList or boolean) CustomMediaQuery;

[Exposed=Window]
interface CSSCustomMediaRule : CSSRule {
  readonly attribute CSSOMString name;
  readonly attribute CustomMediaQuery query;
};

name, 型は CSSOMString, 読み取り専用

<extension-name> を表す CSSOMString を返します。

query, 型は CustomMediaQuery, 読み取り専用

カスタムメディアクエリの値を表します。 返される CustomMediaQuery は次のいずれかになります:

• A MediaList オブジェクト、 ルールが <media-query-list> で定義されていた場合。
• 真のブール値 true、 ルールが値 true で定義されていた場合。
• 偽のブール値 false、 ルールが値 false で定義されていた場合。

12. ユーザー設定に関するメディア機能

12.1. ページ上の動きの削減を検出する: the prefers-reduced-motion feature

The prefers-reduced-motion メディア機能は、 ユーザーがシステムに対して不要な動きの量を最小化するよう要請しているかを検出するために使われます。

no-preference

システムに対してユーザーが特に好みを示していないことを示します。このキーワード値は ブール文脈 では false と評価されます。

reduce

ユーザーが前庭感覚過敏や注意欠陥のある人にとって不快となる種類のモーションベースのアニメーションを 削除または置換するインターフェースを好むことをシステムに通知したことを示します。

12.2. ページ上の透明度低減の希望を検出する: the prefers-reduced-transparency feature

The prefers-reduced-transparency メディア機能は、 ユーザーがシステムに対して透明または半透明のレイヤー効果の使用量を最小化するよう要請しているかを検出するために使われます。

no-preference

システムに対してユーザーが特に好みを示していないことを示します。このキーワード値は ブール文脈 では false と評価されます。

reduce

ユーザーが透明または半透明のレイヤー効果の使用を最小限にするインターフェースを好むことを示します。

これがパターン塗りや背景に関する好みと どのように相互作用するか、という問題があります。これらは透明性の問題ではありませんが、形状認識の妨げにもなります。

12.3. ページ上の要素からの色のコントラストを増減する希望を検出する: the prefers-contrast feature

The prefers-contrast メディア機能は、 ユーザーがページでより多いまたはより少ないコントラストを要求しているかを検出するために使われます。 例えば隣接する色のコントラスト比を調整したり、 要素の視覚的な浮き立ち具合を変える（境界線を調整するなど）ことで応答できます。

no-preference

システムに対してユーザーが特に好みを示していないことを示します。このキーワード値は ブール文脈 では false と評価されます。

less

ユーザーが低いレベルのコントラストを好むことをシステムに通知したことを示します。

more

ユーザーが高いレベルのコントラストを好むことをシステムに通知したことを示します。

custom

ユーザーが特定の色セットを使用したいと示しており、 その色により暗黙されるコントラストが more でも less でもないことを示します。

注意: この値は forced colors mode のユーザーが選んだパレットが 特に高コントラストでも低コントラストでもない場合に該当します。 詳細は § 12.4 Detecting Forced Colors Mode: the forced-colors feature を参照してください。

錆色の背景にシアンのテキストを指定するユーザーは、 輝度の点では必ずしも特に高コントラストや低コントラストを望んでいるわけではありませんが、 好みがないというわけでもありません。

12.4. 強制カラーモードの検出: the forced-colors feature

active

forced colors mode が有効であることを示します: ユーザーエージェントがユーザー選択の限定色パレットをページに強制します。 UA は著者に対して CSS のシステムカラーキーワードを通じてカラーパレットを提供します。 詳細は CSS Color Adjustment 1 § 3 Forced Color Palettes を参照してください。

これは必ずしもより高いコントラストを意味するわけではありません。 色はユーザーの好みに合わせて強制的に調整されていますが、 その好みはより低いコントラストやより高いコントラスト、あるいはどちらでもない配置である可能性があります。

さらに、forced-colors: active に加えて、 ユーザーが選んだ強制カラーパレットが特に高コントラストまたは低コントラストであると UA が判断できる場合には、 prefers-contrast: more または prefers-contrast: less のいずれかを マッチさせる必要があり、そうでなければ prefers-contrast: custom をマッチさせる必要があります。

同様に、ユーザーが選んだ強制カラーパレットが prefers-color-scheme で記述されるカラースキームの いずれかに当てはまる場合、その対応する値もマッチさせる必要があります。

none

Forced colors mode が有効でないことを示します。

12.5. ライトまたはダークのカラースキームの希望を検出する: the prefers-color-scheme feature

The prefers-color-scheme メディア機能は、 ページにライトまたはダークのカラーテーマを使用してほしいというユーザーの希望を反映します。

light

ユーザーがライトテーマ（明るい背景に暗いテキスト）を好むと表明しているか、 明確なアクティブな好みを表明していない（したがって「ウェブのデフォルト」であるライトを受け取る）ことを示します。

dark

ユーザーがダークテーマ（暗い背景に明るいテキスト）を好むと表明していることを示します。

注意: この機能の値は将来拡張される可能性があります （ライトテーマに対するより積極的な希望を表すためや、「セピア」のような他のカラースキームの希望を表すため）。 したがって、このメディア機能を使用する最も将来対応的な方法は否定を使うことです（例: (prefers-color-scheme: dark) と (not (prefers-color-scheme: dark))）。 これにより新しい値が少なくともスタイルブロックのいずれかに入り込むことが保証されます。

ユーザーの希望の表現手段は様々です。OS によるシステム全体の設定か、 ユーザーエージェントが制御する設定である場合があります。

注意: ユーザーの設定は媒体によって変わることがあります。 例えば、発光スクリーン上ではダークテーマを好むが印刷時にはライトテーマを好むことがあります （インク節約や、背景にインクがあるよりも白紙にインクで印字された方が読みやすいため）。 UA はそのような差異を考慮し、prefers-color-scheme が媒体に適した設定を反映するように期待されます。

埋め込み SVG 文書で "Secure Animated" 埋め込みモードを使用して評価される場合、 優先カラースキームは埋め込み文書の埋め込みノード上の used color scheme の値を反映しなければなりません。

12.6. ページ読み込み時のデータ使用量削減の希望を検出する: the prefers-reduced-data feature

この機能は望ましくないフィンガープリンティングの 情報源となる可能性があり、低所得でデータ制限のある層に偏る懸念があります。 [Issue #10076]

The prefers-reduced-data メディア機能は、 ページのレンダリングに際してより少ないデータを使う代替コンテンツを提供してほしいという ユーザーの希望を検出するために使われます。

no-preference

システムに対してユーザーが特に好みを示していないことを示します。このキーワード値は ブール文脈 では false と評価されます。

reduce

ユーザーが軽量な代替コンテンツを好むことを示します。

ユーザーが好みを表現する方法は様々です。OS の設定やユーザーエージェントの設定である場合があります。 ユーザーエージェントは Save-Data HTTP リクエストヘッダを設定する際に使うものと同じユーザー/システムの設定を これに基づいて考慮することができます（参照: Save-Data）。

注意: ユーザーエージェントはこの値の切り替えを扱う際に 自身の裁量でユーザー中心の判断を行うことが推奨されます。ページ読み込み後または読み込み中に切り替わった場合に どのように振る舞うかが例示されています。主な目標は不要なデータをダウンロードしないことかもしれません。 例えばページが既に高品質のアセットで読み込まれていてユーザーが reduced に切り替えた場合、 ページは直ちにドキュメントを更新せず、ユーザーの明示的なリロードを待つようにすることが考えられます。 逆にダウンロードに時間がかかっているページでユーザーが reduced に切り替えた場合は、 より小さなアセットのダウンロードに即座に切り替えて帯域を節約するのが適切かもしれません。 UA はこうした状況に対して適切と考えるロジックを実装する自由があり、またそのような状況が存在することを認識すべきです。

.image {
  background-image: url("images/heavy.jpg");
}

@media (prefers-reduced-data: reduce) {
  /* Save-Data: On */
  .image {
    background-image: url("images/light.jpg");
  }
}

12.7. ユーザー設定の自動処理

ユーザーエージェントはユーザーが好みを示す明示的な設定を提供する場合や、 基盤となる OS の設定に基づいて決定する場合があります。 また、デバイスや環境に関する知識に基づいて自動的にユーザーの好みを推測することもあります。 そのような場合には、自動的に決定された好みをユーザーがオプトアウトまたは上書きできる方法を提供することが推奨されます。

13. スクリプトによるユーザー設定の制御

Web サイトの作者が、ユーザーのシステム設定を尊重しつつもその設定を上書きできるようにしたいと考えることはよくあります。 これを支援するために、本仕様は § 12 User Preference Media Features をスクリプトで上書きする方法を PreferenceManager インターフェイスとして定義します。

この上書きにより、これらの設定に影響されるさまざまなプラットフォーム機能とプリファレンスを統合して扱うことが可能になります。

13.1. Navigator インターフェイスへの拡張

[Exposed=Window, SecureContext]
partial interface Navigator {
	[SameObject] readonly attribute PreferenceManager preferences;
};

13.1.1. preferences 属性

preferences 属性を取得する際は常に同じ PreferenceManager オブジェクトのインスタンスを返すものとします。

13.1.2. PreferenceManager インターフェイス

[Exposed=Window, SecureContext]
interface PreferenceManager {
	readonly attribute PreferenceObject colorScheme;
	readonly attribute PreferenceObject contrast;
	readonly attribute PreferenceObject reducedMotion;
	readonly attribute PreferenceObject reducedTransparency;
	readonly attribute PreferenceObject reducedData;
};

13.1.3. colorScheme 属性

The colorScheme 属性はサイトのカラースキームに関するユーザーの好みを上書きするために使われる PreferenceObject です。これは § 12.5 prefers-color-scheme をモデルとしています。

もしこのプリファレンスのための上書きが設定されている場合:

• ユーザーエージェントは、この上書きを § 12.5 prefers-color-scheme の 値として origin に適用されるすべてのスタイルシート（UA スタイルシートを含む）に対して使用しなければなりません。

• ユーザーエージェントは、CSSOM View § 4 の `matchMedia()` 経由で問合せられたときにもこの上書きを使用しなければなりません。

• ユーザーエージェントは、used color scheme を計算する際にもこの上書きを使用しなければなりません。

• ユーザーエージェントは、User Preference Media Features Client Hints Headers § 2.5 を送信する際にもこの上書きを使用しなければなりません。

• ユーザーエージェントは、通常 § 12.5 prefers-color-scheme によって影響を受ける任意の UA 機能に対してもこの上書きを使用しなければなりません。

13.1.4. contrast 属性

The contrast 属性はサイトのコントラストに関するユーザーの好みを上書きするために使われる PreferenceObject です。これは § 12.3 prefers-contrast をモデルとしています。

もしこのプリファレンスのための上書きが設定されている場合:

• ユーザーエージェントは、この上書きを § 12.3 prefers-contrast の 値として origin に適用されるすべてのスタイルシート（UA スタイルシートを含む）に対して使用しなければなりません。

• ユーザーエージェントは、`matchMedia()` 経由で問合せられたときにもこの上書きを使用しなければなりません（CSSOM View § 4）。

• ユーザーエージェントは、User Preference Media Features Client Hints Headers § 2.3 を送信する際にもこの上書きを使用しなければなりません。

• ユーザーエージェントは、通常 § 12.3 prefers-contrast によって影響を受ける任意の UA 機能に対してもこの上書きを使用しなければなりません。

注意: このプリファレンスは custom に設定できない点でメディア機能とは異なります。 これは § 12.4 forced-colors と密接に結びついているためです。

13.1.5. reducedMotion 属性

The reducedMotion attribute is a PreferenceObject used to override the user’s preference for reduced motion on the site. This is modeled after the § 12.1 prefers-reduced-motion.

もしこのプリファレンスのための上書きが設定されている場合:

• ユーザーエージェントは、この上書きを § 12.1 prefers-reduced-motion の 値として origin に適用されるすべてのスタイルシート（UA スタイルシートを含む）に対して使用しなければなりません。

• ユーザーエージェントは、`matchMedia()` 経由で問合せられたときにもこの上書きを使用しなければなりません（CSSOM View § 4）。

• ユーザーエージェントは、User Preference Media Features Client Hints Headers § 2.1 を送信する際にもこの上書きを使用しなければなりません。

• ユーザーエージェントは、通常 § 12.1 prefers-reduced-motion によって影響を受ける任意の UA 機能に対してもこの上書きを使用しなければなりません。

注意: このプリファレンスに影響される UA 機能の例としては、スムーススクロールを無効にしたり、 marquee 要素を一時停止することなどが考えられます。

13.1.6. reducedTransparency 属性

The reducedTransparency attribute is a PreferenceObject used to override the user’s preference for reduced transparency on the site. This is modeled after the § 12.2 prefers-reduced-transparency.

もしこのプリファレンスのための上書きが設定されている場合:

• ユーザーエージェントは、この上書きを § 12.2 prefers-reduced-transparency の 値として origin に適用されるすべてのスタイルシート（UA スタイルシートを含む）に対して使用しなければなりません。

• ユーザーエージェントは、`matchMedia()` 経由で問合せられたときにもこの上書きを使用しなければなりません（CSSOM View § 4）。

• ユーザーエージェントは、User Preference Media Features Client Hints Headers § 2.2 を送信する際にもこの上書きを使用しなければなりません。

• ユーザーエージェントは、通常 § 12.2 prefers-reduced-transparency によって影響を受ける任意の UA 機能に対してもこの上書きを使用しなければなりません。

13.1.7. reducedData 属性

The reducedData attribute is a PreferenceObject used to override the user’s preference for reduced data usage on the site. This is modeled after the § 12.6 prefers-reduced-data.

もしこのプリファレンスのための上書きが設定されている場合:

• ユーザーエージェントは、この上書きを § 12.6 prefers-reduced-data の 値として origin に適用されるすべてのスタイルシート（UA スタイルシートを含む）に対して使用しなければなりません。

• ユーザーエージェントは、`matchMedia()` 経由で問合せられたときにもこの上書きを使用しなければなりません（CSSOM View § 4）。

• ユーザーエージェントは、Save Data API § 2.1.1 の Save-Data リクエストヘッダを送信する際にもこの上書きを使用しなければなりません。

• ユーザーエージェントは、Save Data API § 2.1 の saveData 属性を計算する際にもこの上書きを使用しなければなりません。

• ユーザーエージェントは、通常 § 12.6 prefers-reduced-data によって影響を受ける任意の UA 機能に対してもこの上書きを使用しなければなりません。

13.1.8. PreferenceObject インターフェイス

[Exposed=Window, SecureContext]
interface PreferenceObject : EventTarget {
	readonly attribute DOMString? override;
	readonly attribute DOMString value;
	readonly attribute FrozenArray<DOMString> validValues;

	undefined clearOverride();
	Promise<undefined> requestOverride(DOMString? value);

	attribute EventHandler onchange;
};

13.1.8.1. override 属性

13.1.8.2. value 属性

13.1.8.3. validValues 属性

13.1.8.4. onchange イベントハンドラ属性

The onchange attribute is an event handler IDL attribute for the onchange event handler, whose event handler event type is change.

13.1.8.5. requestOverride() メソッド

このアルゴリズムは、実際にプリファレンス上書きを設定することが正確に何を行うのかについて より詳細が必要です。

ここで TypeError は正しいでしょうか？

注意: `change` イベントは計算された値が変更されたときに発火しますが、 新しい上書きが設定されたときは値が変わっていなくても発火されます。

13.1.8.6. clearOverride() メソッド

注意: `change` イベントは計算された値が変更されたときに発火しますが、 上書きが解除されたときは値が変わっていなくても発火されます。

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

以下の media features は 廃止予定 です。 後方互換性のために残されていますが、新しいスタイルシートには適していません。著者はこれらを使用してはなりません。 ユーザーエージェントは仕様どおりにこれらをサポートしなければなりません。

ビューポート（または印刷メディアのページボックス）のサイズを問合せるには、 width、height、および aspect-ratio の media features を使うべきであり、 物理デバイスの大きさを参照する device-width、device-height、 および device-aspect-ratio は使うべきではありません。 これらはレイアウト対象の文書に利用可能な空間とは無関係に、デバイスの物理的な大きさを参照します。 device-* の media features はしばしばモバイルデバイスの検出のために代用として使われますが、 代わりに著者は意図するスタイル対象により適切に対応する 他の media features を使うべきです。

device-width

The device-width media feature describes the width of the rendering surface of the output device. For continuous media, this is the width of the Web-exposed screen area. For paged media, this is the width of the page sheet size.

device-width is false in the negative range.

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

注意: デバイスが縦向きや横向きなど複数の向きで使える場合、 device-* メディア機能は現在の向きを反映します。

device-height

The device-height media feature describes the height of the rendering surface of the output device. For continuous media, this is the height of the Web-exposed screen area. For paged media, this is the height of the page sheet size.

device-height is false in the negative range.

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

device-aspect-ratio

The device-aspect-ratio media feature is defined as the ratio of the value of the device-width media feature to the value of the device-height media feature.

@media (device-aspect-ratio: 16/9) { … }
@media (device-aspect-ratio: 32/18) { … }
@media (device-aspect-ratio: 1280/720) { … }
@media (device-aspect-ratio: 2560/1440) { … }

変更点

この節は規範ではありません。

謝辞

この節は規範ではありません。

この仕様は 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, Stephen Chenney, Steven Pemberton, Susan Lesch, Tantek Çelik, Thomas Wisniewski, Vi Nguyen, Xidorn Quan, Yves Lafon, akklesed, and 張俊芝 によって本仕様は改善されました。

プライバシーに関する考慮事項

この節は規範ではありません。

セキュリティに関する考慮事項

この節は規範ではありません。