1. 序論
◎非規範的1997 年にて, HTML4 `HTML401$r は、 異なる`媒体~型$ごとに誂えられた,媒体に依存する~stylesheetを~supportする仕組みを定義した。 例えば、 文書は,~screen用と印刷~用に異なる~stylesheetを利用し得る。 ~HTMLにおいては、 これは次の様に記せる: ◎ In 1997, HTML4 [HTML401] defined a mechanism to support media-dependent style sheets, tailored for different media types. For example, a document may use different style sheets for screen and for print. In HTML, this can be written as:
<link rel="stylesheet" type="text/css" media="screen" href="style.css" > <link rel="stylesheet" type="text/css" media="print" href="print.css" >
~CSSは、 `media$at, `import$at 規則により,個々の特能の`実~値$を~queryする能を追加して、 この機能性に適応し,それを拡張している: ◎ CSS adapted and extended this functionality with its @media and @import rules, adding the ability to query the value of individual features:
~CSS~stylesheetの内側では、 一定の`媒体~型$に適用される区間を宣言できる: ◎ Inside a CSS style sheet, one can declare that sections apply to certain media types:
@media screen { * { font-family: sans-serif } }
同様に、 次の様にすれば,媒体~queryに基づいて条件付きで~stylesheetが~importされる: ◎ Similarly, stylesheets can be conditionally imported based on media queries:
@import "print-styles.css" print;
`媒体~query$は、 HTML, XHTML, XML `xml-stylesheet$r に加え, ~CSSの `import$at / `media$at 規則と伴にも利用できる。 ◎ Media queries can be used with HTML, XHTML, XML [xml-stylesheet] and the @import and @media rules of CSS.
以下に, HTML, XHTML, XML, `import^at, `media^at にて記される等価な例を同順に挙げる: ◎ Here is the same example written in HTML, XHTML, XML, @import and @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. ~module間の相互作用
この~moduleは、 `CSS2$r `§ 媒体~型@~CSS22/media.html#q7.0$ の上に築かれた[ `MEDIAQUERIES-4$r, その前身である `MEDIAQUERIES-3$r ]を拡張して,それに取って代わる。 ◎ This module extends and supersedes [MEDIAQUERIES-4] and its predecessor [MEDIAQUERIES-3], which themselves built upon and replaced CSS 2 § 7 Media types.
1.2. 値
この~仕様にて定義されない `integer$t, `number$t, `resolution$t などの値~型は `CSS-VALUES-4$r にて定義される。 他の~CSS~moduleは,これらの~値~型の定義を拡げてもヨイ。 ◎ Value types not defined in this specification, such as <integer>, <number> or <resolution>, are defined in [CSS-VALUES-4]. Other CSS modules may expand the definitions of these value types.
1.3. 単位
媒体~queryにて利用される単位は、 ~CSSの他所と同じであり,`CSS-VALUES-4$r にて定義される。 例えば,画素~単位( `px$u )は、 物理-画素ではなく,~CSS画素を表現する。 ◎ The units used in media queries are the same as in other parts of CSS, as defined in [CSS-VALUES-4]. For example, the pixel unit represents CSS pixels and not physical pixels.
媒体~queryにおける`相対~長さ$単位は、 `初期~値$に基づく — すなわち単位は、 決して宣言の結果に基づくものではないことを意味する。 ◎ Relative length units in media queries are based on the initial value, which means that units are never based on results of declarations.
注記: 例えば,~HTMLにおける `em$u 単位は、[ ~UAあるいは利用者の選好により定義される, `font-size$p の`初期~値$ ]に相対的になり,~page上の~style付けは関わらない。 これには、 利用者が適用し得る追加的な制約 — 最小~font~sizeなど — も織り込まれることに注意。 ◎ Note: For example, in HTML, the em unit is relative to the initial value of font-size, defined by the user agent or the user’s preferences, not any styling on the page. Note that this will also take into account additional restrictions the user might apply, such as minimum font sizes.
1.4. `prefers-*^d 媒体~特能の~securityと~privacy
【この節は、~level 4 に対する追加。】
利用者についての情報は、 能動的な指紋収集~行路として利用され得る。 影響iの分析を待って、 この仕様が公表される前に,もっと情報が供されることになる。 ◎ Information about a user can be used as an active fingerprinting vector. Analysis of impact pending, more information to be provided before spec is published.
この仕様を実装している~UAと開発者は、 この指紋収集~行路を自覚して,当の特能を利用するかどうか裁定するときに考慮に入れる必要がある。 特定的に,次に挙げるものは、 現時点で悪用が懸念される ⇒# `prefers-reduced-motion$d, `prefers-color-scheme$d, `prefers-reduced-transparency$d, `prefers-reduced-data$d ◎ User agents and developers implementing this specification need to be aware of this vector and take it into consideration when deciding whether to use the feature. Specifically `prefers-reduced-motion`, `prefers-color-scheme`, `prefers-reduced-transparency` and `prefers-reduced-data` are currently of concern for exploitation.
2. 媒体~query
`媒体~query@ とは、 文書を表示している~UAや装置の一定の側面を~testするための手法である。 `媒体~query$は、 (ほぼ)常に[ 文書の内容, その~style付け, 他の内部的な側面 ]から独立であり、 “外部の” 情報のみに依存する — 別の特能が,`媒体~query$【!Media Queries】の解決に影響するものを明示的に指定しない限り。 ◎ A media query is a method of testing certain aspects of the user agent or device that the document is being displayed in. Media queries are (almost) always independent of the contents of the document, its styling, or any other internal aspect; they’re only dependent on “external” information unless another feature explicitly specifies that it affects the resolution of Media Queries.
【 装置 — この仕様の文脈では、 何らかの特徴的な側面を有する物理的な装置と, その挙動を~~模倣する~UA/環境に,論理的な差異は無い。 例えば~UAによる印刷~previewは、 物理的な印刷機と論理的に同じと見なされる。 】
`媒体~query$の構文( `media-query$t )は、 次に挙げるものからなる 【括弧内は訳者補足】:
- 0 〜 1 個の`媒体~query改変子$( `not^v または `only^v )
- 0 〜 1 個の`媒体~型$( `media-type$t )
- 0 個~以上の`媒体~特能$( `媒体~条件$( `media-condition$t )内の `media-feature$t )
`媒体~query$は、 論理-式であり, `真^i または `偽^i に評価される。 媒体~queryが `真^i に評価されるのは、 ~AND↓ が満たされるときである: ◎ A media query is a logical expression that is either true or false. A media query is true if:
- `媒体~型$が指定されているならば、 それは,~UAが稼働中の装置の媒体~型に合致する。 ◎ the media type, if specified, matches the media type of the device where the user agent is running, and
- その`媒体~条件$は `真^i に評価される。 ◎ the media condition is true.
この節における,媒体~queryに関する言明は、 `§ 構文@#mq-syntax$に従っていると見做す。 構文に適合しない媒体~queryについては, `§ ~errorの取扱い@#error-handling$にて論じられる。 すなわち、 構文は,この節による要件よりも優先される。 ◎ Statements regarding media queries in this section assume the syntax section is followed. Media queries that do not conform to the syntax are discussed in § 3.2 Error Handling. I.e. the syntax takes precedence over requirements in this section.
ここに~HTMLで記される単純な例を示す: ◎ Here is a simple example written in HTML:
<link rel="stylesheet" media="screen and (color)" href="example.css" />
この例は、
一定の~stylesheet( example.css
)を[
一定の(有色~screenであることを要する)特能を伴う,
一定の媒体~型( `screen$vm )の装置
]に適用することを表出する。
◎
This example expresses that a certain style sheet (example.css) applies to devices of a certain media type (screen) with certain feature (it must be a color screen).
同じ媒体~queryを~CSSの `import$at 規則で記した例: ◎ Here is the same media query written in an @import-rule in CSS:
@import url(example.css) screen and (color);
~UAは、 利用者~環境の変化に呼応して,自身が~~認識できる`媒体~query$を評価し直すモノトスル。 例えば,装置の方位( `orientation$d )が横置き( `landscape$v1 )から縦置き( `portrait$v1 )に横転された【!tiled = tilted】ときは、 それに則って, `orientation$d を伴う`媒体~query$に依存する どの構成子の挙動も変化する。 ◎ User agents must re-evaluate media queries in response to changes in the user environment that they’re aware of, for example if the device is tiled from landscape to portrait orientation, and change the behavior of any constructs dependent on those media queries accordingly.
別の特能が`媒体~query$【!Media Queries】の解決に影響するものと明示的に~指定しない限り、 式を評価するために~stylesheetを適用する必要は,決して生じない。 ◎ Unless another feature explicitly specifies that it affects the resolution of Media Queries, it is never necessary to apply a style sheet in order to evaluate expressions.
2.1. 媒体~queryを組合せるとき
複数個の`媒体~query$を,~commaで分離して組合できる。 `媒体~query~list@ とは、 0 個~以上の`媒体~query$からなる並びである: ◎ Several media queries can be combined into a comma-separated media query list.
`媒体~query~list$は、[ それを成す各 `媒体~query$成分のうち `どれか一つでも^em `真^i に評価される ]とき `真^i に評価され,他の場合は — すなわち,`すべてが^em `偽^i に評価されるときは — `偽^i に評価される。 ◎ A media query list is true if any of its component media queries are true, and false only if all of its component media queries are false.
例えば、 次の`媒体~query~list$は,[[ `媒体~型$は `screen$vm である, かつ有色~装置である ]または[ `媒体~型$は `projection$vm である, かつ有色~装置である ]]場合に, `真^i になる: ◎ For example, the following media query list is true if either the media type is screen and it’s a color device, or the media type is projection and it’s a color device:
@media screen and (color), projection and (color) { … }
空な`媒体~query~list$は、 `真^i に評価される。 ◎ An empty media query list evaluates to true.
例えば,次の 2 つは、 等価になる: ◎ For example, these are equivalent:
@media all { … } @media { … }
2.2. 媒体~query改変子
`媒体~query$には、 任意選択で,単独の `媒体~query改変子@ が接頭されてもヨイ。 それは、 単独の~keywordであり,後続している`媒体~query$の意味を改める。 ◎ A media query may optionally be prefixed by a single media query modifier, which is a single keyword which alters the meaning of the following media query.
2.2.1. 媒体~queryの否定形: `not^v ~keyword
`媒体~query$は、 ~keyword `not@vm を接頭することで,否定形になる — [ `真^i / `偽^i ]に評価される`媒体~query$は,[ `偽^i / `真^i ]に評価されるようになる。 ◎ An individual media query can have its result negated by prefixing it with the keyword not. If the media query would normally evaluate to true, prefixing it with not makes it evaluate to false, and vice versa.
例えば,次のものは、[ ~screenであって,有色~能力があるもの ]を除く,何にでも適用されることになる。 `媒体~型$のみではなく,媒体~query全体として否定形にされることに注意。 ◎ For example, the following will apply to everything except color-capable screens. Note that the entire media query is negated, not just the media type.
<link rel="stylesheet" media="not screen and (color)" href="example.css" />
2.2.2. 媒体~queryを旧来の~UAからは見えなくさせる: `only^v ~keyword
`媒体~query$の概念は HTML4 `HTML401$r に由来する。 その仕様は、 `媒体~型$のみを定義しつつ,前方-互換な構文 — `媒体~特能$のような将来の概念の追加にも~~適応し得る構文 — を備えている: それは、 `媒体~query$の文字を[ 最初の非~英数字までの部分 ]を`媒体~型$として解釈して,残りの部分は無視する。 例えば`媒体~query$ `screen and (color)^css は、 単に `screen$vm に切落されることになる。 ◎ The concept of media queries originates from HTML4 [HTML401]. That specification only defined media types, but had a forward-compatible syntax that accommodated the addition of future concepts like media features: it would consume the characters of a media query up to the first non-alphanumeric character, and interpret that as a media type, ignoring the rest. For example, the media query screen and (color) would be truncated to just screen.
あいにくこれは、 旧来の~UAが,`媒体~query$の中のどの`媒体~特能$も — それが`媒体~型$よりずっと重要であったとしても — この~errorの取扱いを利用して無視することになることを意味する。 その結果、 不適切な状況~下で,不用意に~styleを適用することになり得る。 ◎ Unfortunately, this means that legacy user agents using this error-handling behavior will ignore any media features in a media query, even if they’re far more important than the media type in the query. This can result in styles accidentally being applied in inappropriate situations.
これらの`媒体~query$を,旧来の~UAからは見えなくさせるため、 `媒体~query$には,~keyword `only@vm も接頭できる。 ~keyword `only$vm は,`媒体~query$の結果には効果は無いが、 旧来の~UAにおいては,その`媒体~query$に 未知な`媒体~型$ "`only^c" が指定されていたかのように構文解析され,無視されるようになる。 ◎ To hide these media queries from legacy user agents, the media query can be prefixed with the keyword only. The only keyword has no effect on the media query’s result, but will cause the media query to be parsed by legacy user agents as specifying the unknown media type “only”, and thus be ignored.
次の例の `link^e 要素に指定された~stylesheetは、 旧来の~UAからは利用されなくなる — それが,通常は`媒体~型$ `screen$vm に合致するとしても。 ◎ In this example, the stylesheet specified by the <link> element will not be used by legacy user agents, even if they would normally match the screen media type.
<link rel="stylesheet" media="only screen and (color)" href="example.css" />
注記: `only$vm ~keywordが利用できる所は、 `媒体~型$の前に限られる。 `媒体~query$のうち[ `媒体~特能$のみからなるもの / `not$vm など別の`媒体~query改変子$があるもの ]は、 旧来の~UAからは,自動的に `偽^i として扱われるので。 ◎ Note: Note that the only keyword can only be used before a media type. A media query consisting only of media features, or one with another media query modifier like not, will be treated as false by legacy user agents automatically.
注記: この~仕様を公表した時点では,そのような旧来の~UAは極めて稀なので、 `only$vm 改変子が必要になることも稀である。 ◎ Note: At the time of publishing this specification, such legacy user agents are extremely rare, and so using the only modifier is rarely, if ever, necessary.
2.3. 媒体~型
`媒体~型@ は、 文書を表示し得る~UA装置の おおまかな分類である。 `媒体~型$の元々の集合は、 HTML4 にて, `link^e 要素~上の `media^a 属性~用に定義されていた。 ◎ A media type is a broad category of user-agent devices on which a document may be displayed. The original set of media types were defined in HTML4, for the media attribute on <link> elements.
あいにく,`媒体~型$は、 異なる~style付けを要する~装置を差別化するには不足であることが判明している。 `screen$vm と `handheld$vm の様な,元々は全く異なっていた一部の分類は、 それらが考案されて以来,年月と伴に~~境目が~~曖昧になってきている。 `tty$vm や `tv$vm などの他のものも, 平均的な~computer~monitorからの相違を露わにさせ, 異なる~style付けを~~適用するために有用になり得るが、 `媒体~型$の定義が排他的なので,適理な方式で利用するのは困難になっている — それらの排他的~側面は、 `grid$d や `scan$d などの`媒体~特能$として,より~~適切に表出される。 ◎ Unfortunately, media types have proven insufficient as a way of discriminating between devices with different styling needs. Some categories which were originally quite distinct, such as screen and handheld, have blended significantly in the years since their invention. Others, such as tty or tv, expose useful differences from the norm of a full-featured computer monitor, and so are potentially useful to target with different styling, but the definition of media types as mutually exclusive makes it difficult to use them in a reasonable manner; instead, their exclusive aspects are better expressed as media features such as grid or scan.
そのようなわけで、 次の`媒体~型$が,`媒体~query$用途に定義される: ◎ As such, the following media types are defined for use in media queries:
- `all@vm
- すべての装置に合致する。 ◎ Matches all devices.
- `print@vm
- 印刷機, あるいは印刷d表示の再現に意図されている装置 (文書を “印刷~preview” で~~表示する~Web~browserなど) に合致する。 ◎ Matches printers, and devices intended to reproduce a printed display, such as a web browser showing a document in “Print Preview”.
- `screen@vm
- `print$vm に合致しない,すべての装置に合致する。 ◎ Matches all devices that aren’t matched by print.
加えて、 下に挙げる非推奨にされた`媒体~型$が定義される — 作者は、 これらの`媒体~型$を利用してはならない。 代わりに、[ ~style付けを試みている装置の側面を,より適切に表現する`媒体~特能$ ]を選定することが推奨される。 ◎ In addition, the following deprecated media types are defined. Authors must not use these media types; instead, it is recommended that they select appropriate media features that better represent the aspect of the device that they are attempting to style against.
~UAは、 これらの`媒体~型$を妥当なものとして認識した上で,何にも合致させないモノトスル。 ◎ User agents must recognize the following media types as valid, but must make them match nothing.
- `tty@vm
- `tv@vm
- `projection@vm
- `handheld@vm
- `braille@vm
- `embossed@vm
- `aural@vm
- `speech@vm
注記: どの媒体~型も、[ 時を経て,より重要な相違を捕捉する適切な`媒体~特能$が定義される ]に伴い,非推奨にされ得るものと予期されている。 ◎ Note: It is expected that all of the media types will also be deprecated in time, as appropriate media features are defined which capture their important differences.
【 `speech^vm (発話)が非推奨にされたのは、 どの “読み上げ” ~browserも,~screenに描画された結果(視覚的に具現化された結果)に基づいて動作している(すなわち,~screen~reader(読み取り器)である)ことに因る( `1751$issue )。 】
2.4. 媒体~特能
`媒体~特能@ は、 `媒体~型$より木目細かい~testである — それは、 ~UAや表示~装置に備わる,単独の, 特定の特能( `feature^en )を~testする。 ◎ A media feature is a more fine-grained test than media types, testing a single, specific feature of the user agent or display device.
`媒体~特能$【 `media-feature$t 】は、 次に挙げる 3 通りの記し方がある:
- `素-形@ 【 `mf-plain$t 】
- [ 特能~名, 1 個の~colon, `~test値$ ]が成す並び。
- 【 “素-形” という語は、 記述し易くするため,この訳にて導入した非公式な用語である。 】
- `真偽-形@ 【 `mf-boolean$t 】
- 特能~名のみ。
- `範囲~形@ 【 `mf-range$t 】
- 後述する比較~演算子を伴うもの。
特に`素-形$は,構文上は~CSS~propに類似するが、 ~propと媒体~特能には,いくつか重要な相違がある: ◎ There are, however, several important differences between properties and media features:
- ~propは,文書をどう呈示するかについての情報を与えるものである一方、 媒体~特能は,出力~装置の要件を述べるためのものである。 ◎ Properties are used to give information about how to present a document. Media features are used to describe requirements of the output device.
- 媒体~特能は、 常に丸括弧で括られる — ~propのように~semicolonで分離されず,次の様に `and^vm や `or^vm ~keywordを用いて組合せることもできる ⇒ `(color) and (min-width: 600px)^css ◎ Media features are always wrapped in parentheses and combined with the and or or keywords, like (color) and (min-width: 600px), rather than being separated with semicolons.
- 媒体~特能は、 (~colonと値を省略して)その名前`のみ^emとしても与え得る — その場合、 その特能は `真偽-文脈$の下で評価される。 これは、[ `実~値$として`ゼロ値$をとり得る特能 ]用の簡便な略記を成す。 例えば `(color)^css は、 `color$d `媒体~特能$の`実~値$が`ゼロ値$でないとき, `真^i になる。 ◎ A media feature may be given with only its name (omitting the colon and value) to evaluate the feature in a boolean context. This is a convenient shorthand for features that have a reasonable value representing 0 or “none”. For example, (color) is true if the color media feature is non-zero.
- `範囲~文脈$の下では、 `媒体~特能$を`範囲$で記すこともできる — それは~colonではなく,標準な数学的な比較~演算子を利用して, あるいは 特能~名に`~min-max接頭辞$を付与して記すこともできる。 ◎ Media features with “range” type can be written in a range context, which uses standard mathematical comparison operators rather than a colon, or have their feature names prefixed with “min-” or “max-”.
- ~propには、 例えば 他のいくつかの値の計算も孕むような複階的な値を受容するものもある。 `媒体~特能$が`~test値$に受容するのは、 単独の値 — 1 個の~keyword, 1 個の数, 等々 — に限られる。 ◎ Properties sometimes accept complex values, e.g., calculations that involve several other values. Media features only accept single values: one keyword, one number, etc.
`媒体~特能$が,~UAが稼働中の装置~上に存在しない概念を参照する場合 (例えば,発話~UAは “横幅” の概念を備えない)、 常に `偽^i に評価するモノトスル。 ◎ If a media feature references a concept which does not exist on the device where the UA is running (for example, speech UAs do not have a concept of “width”), the media feature must always evaluate to false.
媒体~特能 `device-aspect-ratio$d は、 視覚-装置に限り適用される。 したがって, `speech$vm 装置においては、 `device-aspect-ratio^d が含まれた式は,常に `偽^i になる: ◎ The media feature device-aspect-ratio only applies to visual devices. On an speech device, expressions involving device-aspect-ratio will therefore always be false:
<link media="speech and (device-aspect-ratio: 16/9)" rel="stylesheet" href="example.css" >
2.4.1. 媒体~特能の型: 範囲~型と離散~型
どの媒体~特能も,その定義~表tの中で その “型” を次のいずれかとして定義する: ◎ Every media feature defines its “type” as either “range” or “discrete” in its definition table.
- `離散~型@
- この型の媒体~特能は、 いくつかの~keywordや, 真偽値( `0^v または `1^v で記される)からなる集合に属する値をとり, それら値の間には順序(大小関係)は内在されない点で共通する。 例えば `pointer$d 。 ◎ “Discrete” media features, like pointer take their values from a set. The values may be keywords or boolean numbers (0 and 1), but the common factor is that there’s no intrinsic “order” to them—none of the values are “less than” or “greater than” each other.
- `範囲~型@
- この型の媒体~特能がとり得る値~集合は,全順序を備える範囲であり、 どの2つの値も,大小関係を比較できる。 例えば `width$d 。 ◎ “Range” media features like width, on the other hand, take their values from a range. Any two values can be compared to see which is lesser and which is greater.
この2つの型の唯一かつ有意な相違は、 `範囲~型$の`媒体~特能$が[ `範囲~文脈$の下でも評価できるものであり,その名前に`~min-max接頭辞$を受容する ]ことである。 これらの接頭辞はいずれも,特能の意味を変える — [ `媒体~特能$の`実~値$が`~test値$に正確に合致するとき, `真^i に評価される 【すなわち,`素-文脈$】 ]のではなく、[ `実~値$が`~test値$[ より大きい/より小さい/等しい ]範囲に合致する ]とき, `真^i に評価される。 ◎ The only significant difference between the two types is that “range” media features can be evaluated in a range context and accept “min-” and “max-” prefixes on their name. Doing either of these changes the meaning of the feature—rather than the media feature being true when the feature exactly matches the given value, it matches when the feature is greater than/less than/equal to the given value.
`媒体~特能$ `(width >= 600px)^css は、 表示域の横幅が `600px^v `以上^em のとき `真^i になる。 ◎ A (width >= 600px) media feature is true when the viewport’s width is 600px or more.
他方, `(width: 600px)^css それ自体は、 表示域の横幅が `正確に^em `600px^v のときに限り `真^i になり, `600px^v より[ 小さい/大きい ]ときには `偽^i になる。 ◎ On the other hand, (width: 600px) by itself is only true when the viewport’s width is exactly 600px. If it’s less or greater than 600px, it’ll be false.
2.4.X. 素-文脈~下での媒体~特能の評価-法
【 この節は、 原文には無い,訳者による補完である。 この仕様が定義する~modelを[ 明確化する/整理する ]ため、 以下の非公式な用語を導入する。 】
媒体~特能の `~test値@ とは、 その特能の値の構文に従って,作者が指定した値を意味する。 媒体~特能の `実~値@ とは、[ その特能が参照rする,~UAが稼働する環境に備わる装置 ]の[ 現在の状態/機能性 ]を反映する値 — より一般には、 値の集合 — を意味する。 【原文では、明示的な区別なく,単に(媒体~特能の) “値” と記される所も多々あり、そのまま和訳すると紛らわしくなるので。】
次に挙げる値は、 所与の媒体~特能の `ゼロ値@ とされる 【今の所、複数の`ゼロ値$を定義する媒体~特能は無い】 :
- ~keyword `none^v
- `number$t 値 `0^v
- `dimension$t 値 `0^v
- その媒体~特能により、 `ゼロ値$であるものと明示的に定義された値
`実~値$が`ゼロ値$であることは、 一般に,その特能が参照する装置に その特能が備わっていない(または,装置そのものがない)ことを指示する。
`素-形$のうち,`~min-max接頭辞$を伴わない媒体~特能は、 `素-文脈@ の下で評価される — すなわち ⇒ `~test値$が`実~値$に正確に合致するとき, `真^i に評価され、 他の場合は `偽^i に評価される。
ただし,一部の`離散~型$の媒体~特能は、 何個かの~test値に合致するような`実~値$をとり得る — すなわち`実~値$は、 一般には,何個かの値からなる集合として表現され、 `~test値$が そのいずれかの値に一致するとき, `真^i に評価されることになる:
-
媒体~特能には、 構文として(`~test値$として)`ゼロ値$をとり得ないものもある。 ~UAが その特能を備えていない場合、 `実~値$は空~集合になり,どの`~test値$にも合致しない。
【 原文は,この場合の評価-法について明確に述べていないが、 実質的には, `存在しない概念を参照する@#_not-exist$場合に従うのと `同じことを意味する@#_apply-to-the-device$と見受けられる。 】
- 媒体~特能には、 いくつかの装置の和集合を表現するものもある( `any-pointer$d など)。 この場合の`実~値$は,それらの各~装置を表現する媒体~特能の`実~値$からなる和集合になる。
- 媒体~特能[ `color-gamut$d, `dynamic-range$d ]の`実~値$は、 場合によっては複数個の値からなる(その節における記述(注記も含む)を見よ)。
【 `実~値$が`ゼロ値$と他の値を同時に含むことは決してない。 `実~値$としての`ゼロ値$は、 論理的には空~集合を表現するので。 】
2.4.2. 真偽-文脈~下での媒体~特能の評価-法
`媒体~特能$の通常の構文は,~CSS~propに類似する(`素-形$)が、 `(color)^css のように,より単純に 特能~名のみ(`真偽-形$)として記すこともできる。 ◎ While media features normally have a syntax similar to CSS properties, they can also be written more simply as just the feature name, like (color).
このように記された`媒体~特能$は、 `真偽-文脈@ の下で評価される — すなわち: ある`ゼロ値$以外の値 `V^V が在って,その`媒体~特能$を[ `素-文脈$の下で, `V^V を`~test値$として評価したときの結果 ]が `真^i になる — 言い換えれば,`実~値$は`ゼロ値$でない — とき, `真^i に評価され、 他の場合は `偽^i に評価される。 ◎ When written like this, the media feature is evaluated in a boolean context. If the feature would be true for any value other than the number 0, a <dimension> with the value 0, the keyword none, or a value explicitly defined by that media feature to evaluate as false in a boolean context, the media feature evaluates to true. Otherwise, it evaluates to false.
一部の`媒体~特能$は、 このような記され方を念頭に置いて設計されている。 ◎ Some media features are designed to be written like this.
例えば `update$d は、 何らかの描画更新が可用である(あるいは可用でない)かどうかを~testするために,概して `(update)^css (あるいは `not (update)^css )として記される。 ◎ For example, update is typically written as (update) to test if any kind of updating is available, or not (update) to check for the opposite.
`~test値$を明示的に与える`素-形$による記し方も,依然として可能である — `(update: fast) or (update: slow)^css は `(update)^css に等しく, `(update: none)^css は `not (update)^css に等しい。 ◎ It can still be given an explicit value as well, with (update: fast) or (update: slow) equal to (update), and (update: none) equal to not (update).
`width$d のような数的な`媒体~特能$が`真偽-文脈$下の評価において有用になることは、 稀である — それらの`実~値$は,ほぼ常にゼロより大きいので。 `color$d などの他のものは、 有意義な`ゼロ値$をとり得る: `(color)^css は `(color > 0)^css と~~等価であり,装置は有色~表示の能力があることを指示する。 ◎ Some numeric media features, like width, are rarely if ever useful to evaluate in a boolean context, as their values are almost always greater than zero. Others, like color, have meaningful zero values: (color) is identical to (color > 0), indicating that the device is capable of displaying color at all.
~keywordを受容する`媒体~特能$のうち,`真偽-文脈$下で有意義になるものは、 一部に限られる。 ◎ Only some of the media features that accept keywords are meaningful in a boolean context.
例えば `(pointer)^css は、 `pointer$d が[ 装置~上に~pointing装置を備えていないことを指示する値 `none^v ]をとり得るので有用になる。 一方で `(scan)^css は、 `scan$d が偽を意味する値【`ゼロ値$】をとり得ないので、 常に `真^i , または常に `偽^i になる(それが装置に適用されるか否かに依存して†)。 ◎ For example, (pointer) is useful, as pointer has a none value to indicate there’s no pointing device at all on the device. On the other hand, (scan) is just always true or always false (depending on whether it applies at all to the device), as there’s no value that means “false”.
【† すなわち,~UAが `scan$d に対応する装置を備えるならば、 その`実~値$が何であれ `真^i,そうでなければ `偽^i になる,と思われる。 ここでの “値” が `実~値$, `~test値$のどっちを指しているかはっきりしないが、 当の装置を備えない場合, 2 つの解釈が考えられる: (1) `存在しない概念を参照する@#_not-exist$ものと見なされる結果、 `偽^i とされる。 (2) `実~値$は空~集合であると見なされる結果、 `偽^i とされる。 】
2.4.3. 範囲~文脈~下での媒体~特能の評価-法
`範囲~型$の`媒体~特能$は、 `範囲~形$として記すこともできる — それは、 特能がとり得る値が[ 普通の数学的な比較~演算子を利用して順序付けれる利点 ]を活かすよう, `範囲~文脈@ の下で評価される: ◎ Media features with a “range” type can be alternately written in a range context that takes advantage of the fact that their values are ordered, using ordinary mathematical comparison operators:
注記: この構文は、 この仕様の~level 4 による新たなものなので、 現時点では,`~min-max接頭辞$ほどには広く~supportされていない。 ◎ Note: This syntax is new to Level 4 of Mediaqueries, and thus is not as widely supported at the moment as the min-/max- prefixes.
[ 特能~名, 比較~演算子, 値 ]からなる基本~形に対しては、[ 特能~名をその特能の`実~値$, 値を`~test値$ ]に解釈する下で,関係性が真になる場合に `真^i を返す。 ◎ The basic form, consisting of a feature name, a comparison operator, and a value, returns true if the relationship is true.
例えば `(height > 600px)^css (あるいは `(600px < height)^css )は、 表示域の縦幅が `600px^v より大きい場合に `真^i を返す。 ◎ For example, (height > 600px) (or (600px < height)) returns true if the viewport height is greater than 600px.
残りの,特能~名が 2 つの比較~演算子の間に挟まれた形では、 2 つの比較がいずれも `真^i になる場合に, `真^i を返す。 ◎ The remaining forms, with the feature name nested between two value comparisons, returns true if both comparisons are true.
例えば `(400px < width < 1000px)^css は、 表示域の横幅を反映する`実~値$が `400px^v 〜 `1000px^v の間にある(両端の値は含まない)場合に `真^i を返す。 ◎ For example, (400px < width < 1000px) returns true if the viewport width is between 400px and 1000px (but not equal to either).
`範囲~型$の媒体~特能には、 `負な範囲は偽になる@ とされるものもある。 これは、 次を意味する:
- `~test値$が負であっても妥当であり、 構文解析するモノトスル。
-
`実~値$が負な`~test値$[ に等しい/以下/より小さい ]かどうか~queryした結果は, `偽^i に評価し、 負な`~test値$[ 以上/より大きい ]かどうか~queryした結果は, `真^i に評価するモノトスル。
【 この要件は、 実質的に,単に “`実~値$は,常に負でない値をとる” ものと要求することに等価になる。 】
注記: 代わりに,負な`~test値$が 構文解析する時点で却下された場合、 当の~queryは,~error取扱い規則に基づいて `未知^i として扱われることになる。 しかしながら,ある装置における[ `resolution$d の`実~値$は `-300dpi^v かどうか ]が~~実際に `未知^i でなくとも、 `偽^i になるのは既知である。 同様に、 どの視覚-装置であれ,[ 表示~用~区画の `width$d の`実~値$は `-200px^v より大きい ]のは既知である。 上の規則は、 ~UAが何を行うかの直感に合致するよう,それを反映する。 ◎ Note: If negative values had been rejected at parse time instead, they would be treated as unknown based on the error handling rules. However, in reality, whether a device’s resolution is -300dpi is not unknown, it is known to be false. Similarly, for any visual device, the width of the targeted display area is known to be greater than -200px The above rule reflects that, making intuition match what UAs do.
次のいずれの例に対しても、 すべての視覚-装置における背景は,~greenになる: ◎ The following examples result in a green background on all visual devices:
@media not (width <= -100px) { body { background: green; } }
@media (height > -100px) { body { background: green; } }
@media not (resolution: -300dpi) { body { background: green; } }
この挙動は、 ~level 3 `MEDIAQUERIES-3$r からの変更である。 ~level 3 においては、 これらの~propに対する負な`~test値$は,構文~errorとされ、 禁止された値も含めて,当の`媒体~query$全体が `偽^i にされていた — この~levelに定義される `未知^i 扱いでなく。 ~level 3 から更新する実装は,[ `媒体~特能を組合せて@#media-conditions$定義される より多彩な構文 ]の~supportを追加するときには、 意図されない意味論が導入されないよう,関連な~propに対する負な値の取扱いを変更すること。 ◎ This is a behavior change compared to Media Queries Level 3 [MEDIAQUERIES-3], where negative values on these properties caused a syntax error. In level 3, syntax errors—including forbidden values—resulted in the entire media query being false, rather than the unknown treatment defined in this level. Implementations updating from level 3 should make sure to change the handling of negative values for the relevant properties when they add support for the richer syntax defined in § 2.5 Combining Media Features, to avoid introducing unintended semantics.
2.4.4. 範囲~型の特能における~min-maxの利用-法
`範囲~型$の特能に対しては、 上述の,範囲~文脈の下での`媒体~特能$の評価-法に代えて, 特能~名に~min-max接頭辞を付与して,`素-形$による`媒体~特能$の記し方もできる。 ◎ Rather than evaluating a “range” type media feature in a range context, as described above, the feature may be written as a normal media feature, but with a “min-” or “max-” prefix on the feature name.
これは、 次の様な,`範囲~文脈$の下での特能の評価-法に等価になる: ◎ This is equivalent to evaluating the feature in a range context, as follows:
- 特能~名に対する "`min-^d" 接頭辞の利用は、 "`>=^css" 演算子の利用に等価になる。 例えば `(min-height: 600px)^css は、 `(height >= 600px)^css に等価になる。 ◎ Using a “min-” prefix on a feature name is equivalent to using the “>=” operator. For example, (min-height: 600px) is equivalent to (height >= 600px).
- 特能~名に対する "`max-^d" 接頭辞の利用は、 "`<=^css" ~演算子の利用に等価になる。 例えば `(max-width: 40em)^css は、 `(width <= 40em)^css に等価になる。 ◎ Using a “max-” prefix on a feature name is equivalent to using the “<=” operator. For example, (max-width: 40em) is equivalent to (width <= 40em).
注記: ~min-maxによる比較は,その範囲が当の`~test値$も含むので、 状況によっては~~限界もある。 ◎ Note: because “min-” and “max-” both equate to range comparisons that include the value, they may be limiting in certain situations.
一例として、 ~min-maxを利用して,表示域~横幅の ある~~境目の前後で異なる~styleを定義しようとしている作者は、 両~queryとも同時に `真^i に評価されないことを確保するため、 一般に,比較している値を少しずらす。 境目が `320px^v にあると見做すなら、 作者は,概念的に次を利用するであろう: ◎ For instance, authors trying to define different styles based on a breakpoint in the viewport width using “min-” and “max-” would generally offset the values they’re comparing, to ensure that both queries don’t evaluate to true simultaneously. Assuming the breakpoint is at 320px, authors would conceptually use:
@media (max-width: 320px) { /* 表示域 ~LTE `320px^v 用の~style ◎ styles for viewports <= 320px */ } @media (min-width: 321px) { /* 表示域 ~GTE `321px^v 用の~style ◎ styles for viewports >= 321px */ }
これは,表示域の横幅が `320px^v のときに両~styleとも同時に適用されないことを確保しているが、 表示域の~sizeが整数でない可能性を織り込んでいない — それは、 画素~密度が整数でないときに生じ得る(例: 高 dpi な~displayや,~zoom/拡縮したとき)。 表示域の横幅が `320px^v 〜 `321px^v の合間に入る場合、 両~styleとも適用されないことになる。 ◎ While this ensures that the two sets of styles don’t apply simultaneously when the viewport width is 320px, it does not take into account the possibility of fractional viewport sizes which can occur as a result of non-integer pixel densities (e.g. on high-dpi displays or as a result of zooming/scaling). Any viewport widths that fall between 320px and 321px will result in none of the styles being applied.
この問題に対処する~approachとして、 比較~用に利用される値の精度を増やすことが挙げられる。 上の例で, 2 個目の比較~値を `320.01px^v に変更すれば、 その装置~上の表示域の横幅がすき間に入り込む~~確率は,有意に抑制される。 ◎ One approach to work around this problem is to increase the precision of the values used for the comparison. Using the example above, changing the second comparison value to 320.01px significantly reduces the chance that a viewport width on a device would fall between the cracks.
@media (max-width: 320px) { /* 表示域 ~LTE `320px^v 用の~style ◎ styles for viewports <= 320px */ } @media (min-width: 320.01px) { /* 表示域 ~GTE `320.01px^v 用の~style ◎ styles for viewports >= 320.01px */ }
しかしながら,このような状況では、 ( `>=^css, `<=^css 以外による比較も可能な)`範囲~文脈$による~queryが,より適切な解決策を提供する: ◎ However, in these situations, range context queries (which are not limited to “>=” and “<=” comparisons) offer a more appropriate solution:
@media (width <= 320px) { /* 表示域 ~LTE `320px^v 用の~style ◎ styles for viewports <= 320px */ } @media (width > 320px) { /* 表示域 ~GT `320px^v 用の~style ◎ styles for viewports > 320px */ }
`離散~型$の媒体~特能は、 `~min-max接頭辞$を受容しない。 そのような接頭辞が付与された媒体~特能は、 単純に未知な特能~名と見なされる。 ◎ “Discrete” type properties do not accept “min-” or “max-” prefixes. Adding such a prefix to a “discrete” type media feature simply results in an unknown feature name.
例えば `(min-grid: 1)^css は、 無効になる — `grid$d は`離散~型$の`媒体~特能$であり,接頭辞を受容しないので( `grid$d は数的な`~test値$ `0^v / `1^v を受容するが,それは真偽値を意味する)。 ◎ For example, (min-grid: 1) is invalid, because grid is a “discrete” media feature, and so doesn’t accept the prefixes. (Even though the grid media feature appears to be numeric, as it accepts the values 0 and 1.)
`~min-max接頭辞$が付与された`媒体~特能$を`真偽-文脈$の下で評価させようとする試みは、 無効であり,構文~errorである。 ◎ Attempting to evaluate a min/max prefixed media feature in a boolean context is invalid and a syntax error.
2.5. 媒体~特能を組合せるとき
真偽値~代数( `not^vm, `and^vm, `or^vm )を利用すれば、 複数個の`媒体~特能$を組合せて,一つの `媒体~条件@ にまとめることができる。 ◎ Multiple media features can be combined together into a media condition using full boolean algebra (not, and, or).
- 媒体~特能に `not$vm を前置すれば、 否定形にできる。 例えば `not (color)^css は、 `(color)^css の意味を反転する — `(color)^css は,任意の種類の有色~display装置に合致するので、 `not (color)^css は,有色~displayを除く任意の種類の装置に合致する。 ◎ Any media feature can be negated by placing not before it. For example, not (color) inverts the meaning of (color)—since (color) matches a device with any kind of color display, not (color) matches a device without any kind of color display.
- 複数個の媒体~特能を, `and^vm を挟んでつなげることで一体化させれる。 そうして得られた~queryは、 各 媒体~特能`すべて^emが `真^i になる場合に限り, `真^i になる。 例えば `(width < 600px) and (height < 600px)^css は、 両~次元とも `600px^css より狭い~screen装置にのみ合致する。 ◎ Two or more media features can be chained together, such that the query is only true if all of the media features are true, by placing and between them. For example, (width < 600px) and (height < 600px) only matches devices whose screens are smaller than 600px wide in both dimensions.
- 複数個の媒体~特能を, `or^vm を挟んでつなげることで一体化させれる。 そうして得られた~queryは、 各 媒体~特能のうち`いずれか^emが `真^i ならば, `真^i になる。 例えば `(update: slow) or (hover: none)^css は、[ ~screenの更新が遅い(電子書籍~readerなど) ]`または^em[ 首~pointing装置が~hover能力を有さない ]ときに合致する — おそらく、 利用者が~hoverするまで小さくたたんでおくような~layoutに代えて,当初から より多く情報を表示する~layoutを利用するべきであることを指示する。 ◎ Alternately, two or more media features can be chained together, such that the query is true if any of the media features are true, by placing or between them. For example, (update: slow) or (hover: none) matches if the device is slow to update the screen (such as an e-reader) or the primary pointing device has no hover capability, perhaps indicating that one should use a layout that displays more information rather than compactly hiding it until the user hovers.
- 複数個の`媒体~条件$を丸括弧 `()^css で括って~group化すれば、 単独の媒体~queryと同じように,条件の中に入子にできる。 例えば `(not (color)) or (hover)^css は、 単彩色または~hover能力を有する装置に対し, `真^i になる。 単彩色, かつ~hover能力を`有さない^em装置を~queryしたいと求めるならば、 代わりに `not ((color) or (hover))^css と記さなければナラナイ(あるいは, `(not (color)) and (not (hover)))^css でも等価になる)。 ◎ Media conditions can be grouped by wrapping them in parentheses () which can then be nested within a condition the same as a single media query. For example, (not (color)) or (hover) is true on devices that are monochrome and/or that have hover capabilities. If one instead wanted to query for a device that was monochrome and didn’t have hover capabilities, it must instead be written as not ((color) or (hover)) (or, equivalently, as (not (color)) and (not (hover))).
[ `and^vm, `or^vm, `not^vm ]を媒体~queryの同じ “~level” に混在させるのは`無効になる^em。 例えば `(color) and (pointer) or (hover)^css は、 ~~意図が不明瞭なので違法になる。 代わりに丸括弧を利用すれば、 特定0の~~連結~keywordを利用している~~項たちを~group化できる — `(color) and ((pointer) or (hover))^css, あるいは `((color) and (pointer)) or (hover)^css のように。 これら 2 つの意味は異なる — 例えば `(hover)^css のみが `真^i であれば、 前者は `偽^i , 後者は `真^i に評価される。 ◎ It is invalid to mix and and or and not at the same “level” of a media query. For example, (color) and (pointer) or (hover) is illegal, as it’s unclear what was meant. Instead, parentheses can be used to group things using a particular joining keyword, yielding either (color) and ((pointer) or (hover)) or ((color) and (pointer)) or (hover). These two have very different meanings: if only (hover) is true, the first one evaluates to false but the second evaluates to true.
3. 構文
前~節に示した 注釈文や線路~図式に現れる媒体~queryの構文は,非正式な記述であり、 正式な構文は,この節にて `CSS-SYNTAX-3$r, `CSS-VALUES-4$r にて定義される[ 規則/~prop ]文法の構文で述べられる。 ◎ Informal descriptions of the media query syntax appear in the prose and railroad diagrams in previous sections. The formal media query syntax is described in this section, with the rule/property grammar syntax defined in [CSS-SYNTAX-3] and [CSS-VALUES-4].
`media-query-list@t 生成規則を構文解析するためには、 `~commaで分離された成分~値~listを構文解析-$した結果の各~entryを, `media-query$t として構文解析する。 生産される結果の値は、 `media-query$t の~listになる。 ◎ To parse a <media-query-list> production, parse a comma-separated list of component values, then parse each entry in the returned list as a <media-query>. Its value is the list of <media-query>s so produced.
注記: ここで明示的に定義される `media-query-list$t の構文解析-法は、 `媒体~query~list$における~error回復の挙動がきちんと定義されること( `well-defined^en )が必要yである。 ◎ Note: This explicit definition of <media-query-list> parsing is necessary to make the error-recovery behavior of media query lists well-defined.
注記: ここで定義される `media-query-list$t の構文解析-法は、 意図的に,空な~listも受容するようにされている。 ◎ Note: This definition of <media-query-list> parsing intentionally accepts an empty list.
注記: `CSS-SYNTAX-3$r に従って、 ~tokenは`~ASCII大小無視$である。 ◎ Note: As per [CSS-SYNTAX-3], tokens are ASCII case-insensitive.
`media-query@t = `media-condition$t | [ not | only ]? `media-type$t [ and `media-condition-without-or$t ]? `media-type@t = `ident$t `media-condition@t = `media-not$t | `media-in-parens$t | [ `media-and$t* | `media-or$t* ] `media-condition-without-or@t = `media-not$t | `media-in-parens$t `media-and$t* `media-not@t = not `media-in-parens$t `media-and@t = and `media-in-parens$t `media-or@t = or `media-in-parens$t `media-in-parens@t = ( `media-condition$t ) | `media-feature$t | `general-enclosed$t `media-feature@t = ( [ `mf-plain$t | `mf-boolean$t | `mf-range$t ] ) `mf-plain@t = `mf-name$t : `mf-value$t `mf-boolean@t = `mf-name$t `mf-range@t = `mf-name$t `mf-comparison$t `mf-value$t | `mf-value$t `mf-comparison$t `mf-name$t | `mf-value$t `mf-lt$t `mf-name$t `mf-lt$t `mf-value$t | `mf-value$t `mf-gt$t `mf-name$t `mf-gt$t `mf-value$t `mf-name@t = `ident$t `mf-value@t = `number$t | `dimension$t | `ident$t | `ratio$t `mf-lt@t = '<' '='? `mf-gt@t = '>' '='? `mf-eq@t = '=' `mf-comparison@t = `mf-lt$t | `mf-gt$t | `mf-eq$t `general-enclosed@t = [ (【!原文 左括弧抜け】 `function-token$t `any-value$t? ) ] | [ ( `any-value$t? ) ]
`media-type$t 生成規則は、 ~keyword[ `only$vm, `not$vm, `and^vm, `or^vm, `layer^vm ]を含まない。 ◎ The <media-type> production does not include the keywords only, not, and, or, and layer.
注記:
`layer^vm が除外されたわけは、
さもないと,`~cascade層$のために
`import$at `url(…) layer^v;
構文にて利用されるとき多義的になるからである。
`CSS-CASCADE-5$r を見よ。
◎
Note: The exclusion of layer is because it would otherwise be ambiguous when when used in the @import url(…) layer; syntax for the sake of cascade layers. See [CSS-CASCADE-5].
`delim-token$t である[[ "`<^css" / "`>^css" ]と, 直後の "`=^css"(もし在れば) ]の合間には、 空白は許容されない。 ◎ No whitespace is allowed between the “<” or “>” <delim-token>s and the following “=” <delim-token>, if it’s present.
注記: ~keyword[ `not$vm / `and^vm / `or^vm ]と後続している文字 "`(^css" との合間には、 空白が要求される。 そうでないと `function-token$t に構文解析されるので。 これは、 すでに上の文法が受持っているので明示的に無効にされる【?】ことはない。 一方で、 "`)^css" と後続している~keywordとの合間の空白は,~~問題ない。 ◎ Note: Whitespace is required between a not, and, or or keyword and the following ( character, because without it that would instead parse as a <function-token>. This is not made explicitly invalid because it’s already covered by the above grammar. It’s fine to have whitespace between a ) and a following keyword, however.
生成規則 `media-in-parens$t の構文解析においては、 選択肢 `general-enclosed$t が選ばれるのは,[ 入力が,先行するどの選択肢にも合致しない場合 ]に限られるモノトスル。 `general-enclosed$t は、 将来に,適理に互換な仕方で文法を拡げることを許容するために存在する。 ◎ When parsing the <media-in-parens> production, the <general-enclosed> branch must only be chosen if the input does not match either of the preceding branches. <general-enclosed> exists to allow for future expansion of the grammar in a reasonably compatible way.
3.1. 媒体~queryの評価-法
[ `media-condition$t / `media-condition-without-or$t ]を成す主な各 下位式は、 以下に挙げる規則に従って,真偽値に評価される: ◎ Each of the major subexpression of <media-condition> or <media-condition-without-or> is associated with a boolean result, as follows:
- `media-condition$t
- `media-condition-without-or$t
- 子 下位式の結果。 ◎ The result is the result of the child subexpression.
- `media-in-parens$t
- 結果は、 子~項の結果。 ◎ The result is the result of the child term.
- `media-not$t
- 結果は、 子 `media-in-parens$t 項の否定。 `未知^i の否定は `未知^i とする【下の注記を見よ】。 ◎ The result is the negation of the <media-in-parens> term. The negation of unknown is unknown.
- `media-in-parens$t `media-and$t*
- 結果は、 次に挙げる項が[ すべて `真^i ならば `真^i / いずれかが `偽^i ならば `偽^i / 他の場合は `未知^i ] ⇒# 子 `media-in-parens$t 項, すべての子 `media-and$t 項の子 `media-in-parens$t 項 ◎ The result is true if the <media-in-parens> child term and all of the <media-in-parens> children of the <media-and> child terms are true, false if at least one of these <media-in-parens> terms are false, and unknown otherwise.
- `media-in-parens$t `media-or$t*
- 結果は、 次に挙げる項が[ すべて `偽^i ならば `偽^i / いずれかが `真^i ならば `真^i / 他の場合は `未知^i ] ⇒# 子 `media-in-parens$t 項, すべての子 `media-and$t 項の子 `media-in-parens$t 項 ◎ The result is false if the <media-in-parens> child term and all of the <media-in-parens> children of the <media-or> child terms are false, true if at least one of these <media-in-parens> terms are true, and unknown otherwise.
- `general-enclosed$t
- 結果は、 `未知^i 。 ◎ The result is unknown.
- 作者は、 ~stylesheetに `general-enclosed$t を利用してはならない。 ◎ ↓
- これは,将来の互換性を保つためのみにあり、 新たな構文が追加されたとき,[ 旧い~UAにおいて `media-condition$t が不能化されないようにする ]ためにある。 ◎ Authors must not use <general-enclosed> in their stylesheets. It exists only for future-compatibility, so that new syntax additions do not invalidate too much of a <media-condition> in older user agents.
- `media-feature$t
-
結果は、 指定された媒体~特能に対し評価した結果で与えられる:
- ~min-maxを伴わない `mf-plain$t 用には ⇒ `§ 素-文脈~下での媒体~特能の評価-法@#mq-plain-context$
- `mf-boolean$t 用には ⇒ `§ 真偽-文脈~下での媒体~特能の評価-法@#mq-boolean-context$
- `mf-range$t 用には ⇒ `§ 範囲~文脈~下での媒体~特能の評価-法@#mq-range-context$
- ~min-maxを伴う `mf-plain$t 用には ⇒ `§ 範囲~型の特能における~min-maxの利用-法@#mq-min-max$
上に挙げたいずれかの生成規則の結果が,二値~真偽値を期待する文脈で利用される場合、 `未知^i は `偽^i に変換するモノトスル。 ◎ If the result of any of the above productions is used in any context that expects a two-valued boolean, “unknown” must be converted to “false”.
注記: これは例えば、 `media$at 規則にて`媒体~query$が利用されるとき、 `未知^i に解決されるものは `偽^i として扱われ,合致しなくなることを意味する。 ◎ Note: This means that, for example, when a media query is used in a @media rule, if it resolves to “unknown” it’s treated as “false” and fails to match.
注記: `媒体~query$【!Media Queries】は、 各~項が[ `真^i, `偽^i, `未知^i ]のいずれかをとる論理 — 特定的には, `~Kleeneの三値~論理@https://en.wikipedia.org/wiki/Three-valued_logic#Kleene_and_Priest_logics$ 【`日本語版@https://ja.wikipedia.org/wiki/3%E5%80%A4%E8%AB%96%E7%90%86#.E3.82.AF.E3.83.AA.E3.83.BC.E3.83.8D.E3.81.AE3.E5.80.A4.E8.AB.96.E7.90.86$】 — を利用する。 この論理における `未知^i は、 “`真^i か `偽^i のどちらかだが,まだわからない” ことを意味する。 ◎ Media Queries use a three-value logic where terms can be “true”, “false”, or “unknown”. Specifically, it uses the Kleene 3-valued logic. In this logic, “unknown” means “either true or false, but we’re not sure which yet”.
一般に,公式が `未知^i 値を含む場合、 その結果は `未知^i になる — `未知^i を `真^i に置き換えた場合と `偽^i に置き換えた場合とで異なるので。 `未知^i 値を消せるのは、 `未知^i を `真^i, `偽^i どちらに置換しようが同じ結果になるとき — すなわち “`偽^i ~AND `未知^i” (いずれにせよ `偽^i に評価される), “`真^i ~OR `未知^i” (いずれにせよ `真^i に評価される) — に限られる。 ◎ In general, an unknown value showing up in a formula will cause the formula to be unknown as well, as substituting “true” for the unknown will give the formula a different result than substituting “false”. The only way to eliminate an unknown value is to use it in a formula that will give the same result whether the unknown is replaced with a true or false value. This occurs when you have “false AND unknown” (evaluates to false regardless) and “true OR unknown” (evaluates to true regardless).
この論理が採用されている~~理由は、
`general-enclosed$t に真理~値( `truth value^en )†をアテガう必要があるためである。
標準な真偽-論理で適理な値は `偽^i に限られるが、
これは
not `未知な何か^V
が `真^i になることを意味し,求まれないか惑わすものになる。
~Kleeneの三値~論理は、[
未知なものは、
その値が最終-結果に関連するならば,`媒体~query$に合致させない
]ことを確保する。
◎
This logic was adopted because <general-enclosed> needs to be assigned a truth value. In standard boolean logic, the only reasonable value is “false”, but this means that not unknown(function) is true, which can be confusing and unwanted. Kleene’s 3-valued logic ensures that unknown things will prevent a media query from matching, unless their value is irrelevant to the final result.
【† 命題の真/偽( “真らしさ” )を表す値 — 排中律を前提にしないので、 真, 偽 以外もあり得る。 】
3.2. ~errorの取扱い
前~節の文法に合致しない媒体~queryは、 構文解析-時に `not all^v に置換するモノトスル。 ◎ A media query that does not match the grammar in the previous section must be replaced by not all during parsing.
注記: `媒体~query~list$における,文法との不一致に際しては、 問題になり得る`媒体~query$のみが `not all^v に置換される — ~list全体が一掃されるわけではない。 また、 上で定義される構文解析の挙動は,その次に~~現れる~top-levelの~commaで自動的に回復する。 ◎ Note: Note that a grammar mismatch does not wipe out an entire media query list, just the problematic media query. The parsing behavior defined above automatically recovers at the next top-level comma.
@media (example, all,), speech { /* 発話~装置に限り適用-可能 ◎ only applicable to speech devices */ } @media &test, speech { /* 同上 ◎ only applicable to speech devices */ }
上の`媒体~query~list$は、 どちらも,構文解析-時には `not all, speech^css に転換される — その結果、 単なる `speech$vm と同じ真理~値をとる。 ◎ Both of the above media query lists are turned into not all, speech during parsing, which has the same truth value as just speech.
~error回復は、 `媒体~query$の~top-levelのみに限られることに注意。 括弧で括られた無効な~block内のものは,どれも、 単に~groupとして `not all^css に転換される。 例えば: ◎ Note that error-recovery only happens at the top-level of a media query; anything inside of an invalid parenthesized block will just get turned into not all as a group. For example:
@media (example, speech { /*
発話~装置~用の規則
◎
rules for speech devices
*/ }
"`(^c" から~~開始する~blockは閉じられていないので、[ 閉じ括弧 "`)^c" に遭遇するまでの,~stylesheetの残り全部 ]が `not all^css `媒体~query$に転換される。 ◎ Because the parenthesized block is unclosed, it will contain the entire rest of the stylesheet from that point (unless it happens to encounter an unmatched “)” character somewhere in the stylesheet), and turn the entire thing into a not all media query.
未知な `media-type$t は、 どの`媒体~型$にも合致しないように扱うモノトスル。 ◎ An unknown <media-type> must be treated as not matching.
例えば,媒体~query `unknown^css は、 `unknown^v が未知な`媒体~型$なので, `偽^i になる。 ◎ For example, the media query unknown is false, as unknown is an unknown media type.
一方 `not unknown^css は、 `not$vm が `偽^i の`媒体~型$を否定形にするので, `真^i になる。 ◎ But not unknown is true, as the not negates the false media type.
~keywordには、 `media-type$t として許容されない【すなわち,媒体~型と見なされない】ものもあることに留意。 それは構文解析をまるごと失敗させる: `or and (color)^css のような媒体~queryは、 構文解析-時には,単に `or^vm が未知な`媒体~型$に扱われるのではなく, `not all^css に転換される。 ◎ Remember that some keywords aren’t allowed as <media-type>s and cause parsing to fail entirely: the media query or and (color) is turned into not all during parsing, rather than just treating the or as an unknown media type.
未知な[ `mf-name$t / `mf-value$t ]に対する結果, および[ `~test値$【!特能~値】が当の`媒体~特能$用の構文に合致しない場合 ]の結果は、 値 `未知^i になる。 値 `未知^i をとる `media-query$t は、 `not all^css に置換するモノトスル。 ◎ An unknown <mf-name> or <mf-value>, or a feature value which does not matches the value syntax for that media feature, results in the value “unknown”. A <media-query> whose value is “unknown” must be replaced with not all.
<link media="screen and (max-weight: 3kg) and (color), (color)" rel="stylesheet" href="example.css" />
`max-weight^v は未知な`媒体~特能$なので、 この`媒体~query~list$は `not all, (color)^css に転換され, 単なる `(color)^css に~等価になる。 ◎ As max-weight is an unknown media feature, this media query list is turned into not all, (color), which is equivalent to just (color).
@media (min-orientation:portrait) { … }
`orientation$d 特能は接頭辞を受容しない — よって, `min-orientation^d は、 未知な`媒体~特能$と見なされ, `not all^css に転換される。 ◎ The orientation feature does not accept prefixes, so this is considered an unknown media feature, and turned into not all.
媒体~query `(color:20example)^css は、 媒体~特能 `color$d に未知な`~test値$を指定するので, `not all^css に転換される。 ◎ The media query (color:20example) specifies an unknown value for the color media feature and is therefore turned into not all.
`媒体~query$は、 ~host言語による構文解析~規則の~subjectになることに注意。 例えば、 次の~CSS片: ◎ Note that media queries are also subject to the parsing rules of the host language. For example, take the following CSS snippet:
@media test;,all { body { background:lime } }
において,[ 媒体~query `test;,all^css 自体を構文解析した結果は、 `not all, all^css に等価になり,常に `真^i になる ]が、[ ~CSSの構文解析~規則により、 `media$at 規則, したがって`媒体~query$は,~semicolonで終端する ]ので,[ ~semicolonより~~後の部分は、 無効な[ 選択子と内容 ]を伴う~style規則として扱われる ]ことになる。 ◎ The media query test;,all is, parsed by itself, equivalent to not all, all, which is always true. However, CSS’s parsing rules cause the @media rule, and thus the media query, to end at the semicolon. The remainder of the text is treated as a style rule with an invalid selector and contents.
4. 表示域や~pageの特性に関する媒体~特能
4.1. 横幅: `width^d
◎述 `width@d ◎用 `media$at ◎値 `length$t ◎型 `範囲$ ◎表終媒体~特能 `width$d は、 出力~装置の表示~用~区画の横幅を述べる。 その`実~値$は、 `連続的~媒体$用には,`表示域$の横幅になる( `CSS2$r § 9.1.1 ) — ~scrollbarが描画されるならば,その~sizeも含む。 `~paged媒体$用には,`~page~box$の横幅になる( `CSS2$r § 13.2 )。 ◎ The width media feature describes the width of the targeted display area of the output device. For continuous media, this is the width of the viewport (as described by CSS2, section 9.1.1 [CSS2]) including the size of a rendered scroll bar (if any). For paged media, this is the width of the page box (as described by CSS2, section 13.2 [CSS2]).
`length$t は、 `§ 単位$に則って解釈される。 ◎ <length>s are interpreted according to § 1.3 Units.
`width$d に対する`負な範囲は偽になる$。 ◎ width is false in the negative range.
例えば,次の媒体~queryは、[ 印刷d出力が `25cm^v より幅広なときに限り,~stylesheetが利用される ]ことを表出する: ◎ For example, this media query expresses that the style sheet is used on printed output wider than 25cm:
<link rel="stylesheet" media="print and (min-width: 25cm)" href="http://…" />
次の媒体~queryは、[ 表示域(~screenや紙に文書が描画される部分)の横幅が 400 〜 700 画素の装置に限り,~stylesheetが利用される ]ことを表出する: ◎ This media query expresses that the style sheet is used on devices with viewport (the part of the screen/paper where the document is rendered) widths between 400 and 700 pixels:
@media (400px <= width <= 700px) { … }
次の媒体~queryは、[ 表示域の横幅が `20em^v より大きいときに限り,~stylesheetが利用される ]ことを表出する: ◎ This media query expresses that style sheet is used if the width of the viewport is greater than 20em.
@media (min-width: 20em) { … }
`em$u 単位の値は、 `font-size$p の`初期~値$に相対的になる。 ◎ The em value is relative to the initial value of font-size.
4.2. 縦幅: `height^d
◎述 `height@d ◎用 `media$at ◎値 `length$t ◎型 `範囲$ ◎表終媒体~特能 `height$d は、 出力~装置の表示~用~区画の縦幅を述べる。 その`実~値$は、 `連続的~媒体$用には,`表示域$の縦幅になる — ~scrollbarが描画されるならば,その~sizeも含む。 `~paged媒体$用には,`~page~box$の縦幅になる。 ◎ The height media feature describes the height of the targeted display area of the output device. For continuous media, this is the height of the viewport including the size of a rendered scroll bar (if any). For paged media, this is the height of the page box.
`length$t は、 `§ 単位$に則って解釈される。 ◎ <length>s are interpreted according to § 1.3 Units.
`height$d に対する`負な範囲は偽になる$。 ◎ height is false in the negative range.
4.3. 縦横比: `aspect-ratio^d
◎述 `aspect-ratio@d ◎用 `media$at ◎値 `ratio$t ◎型 `範囲$ ◎表終媒体~特能 `aspect-ratio$d の`実~値$は、[ 媒体~特能 `width$d の`実~値$ ]の[ 媒体~特能 `height$d の`実~値$ ]に対する比率として定義される。 ◎ The aspect-ratio media feature is defined as the ratio of the value of the width media feature to the value of the height media feature.
4.4. 方位: `orientation^d
◎述 `orientation@d ◎用 `media$at ◎値 `portrait$v | `landscape$v ◎型 `離散$ ◎表終- `portrait@v
- 媒体~特能 `orientation$d の`実~値$は、[ 媒体~特能 `height$d の`実~値$ ]が[ 媒体~特能 `width$d の`実~値$ ]以上ならば, `portrait^v になる。 ◎ The orientation media feature is portrait when the value of the height media feature is greater than or equal to the value of the width media feature.
- `landscape@v
- 他の場合, `landscape^v になる。 ◎ Otherwise orientation is landscape.
次の~媒体~queryは、 方位が “縦置き” かどうか~testする。 携帯電話を直立に握っているときのように。 ◎ The following media query tests for “portrait” orientation, like a phone held upright.
@media (orientation:portrait) { … }
4.5. 塊-軸~~方向の~overflow: `overflow-block^d
◎述 `overflow-block@d ◎用 `media$at ◎値 `none$v | `scroll$v | `paged$v ◎型 `離散$ ◎表終媒体~特能 `overflow-block$d は、 内容が`初期~包含塊$を`塊-軸$~~方向に~overflowするときの,装置の挙動を述べる。 ◎ The overflow-block media feature describes the behavior of the device when content overflows the initial containing block in the block axis.
- `none@v
- `塊-軸$~~方向の~overflowに対し,便宜を図ることはない — ~overflowした内容は、 単に表示されない。 例:広告塔 ◎ There is no affordance for overflow in the block axis; any overflowing content is simply not displayed. Examples: billboards
- `scroll@v
- `塊-軸$~~方向に~overflowしている内容は、 利用者による~scrollで露わにできる。 例:~computer~screen ◎ Overflowing content in the block axis is exposed by allowing users to scroll to it. Examples: computer screens
- `paged@v
- 内容は、 離散的な~pageに分断される — ある~page内から`塊-軸$に~overflowする内容は、 次の~page上に表示される。 例:印刷機, 電子書籍~reader。 ◎ Content is broken up into discrete pages; content that overflows one page in the block axis is displayed on the following page. Examples: printers, ebook readers
[ `none$v / `scroll$v ]に合致する媒体は, `連続的~媒体@ と称され、 `paged$v に合致する媒体は, `~paged媒体@ と称される。 ◎ Media that match none or scroll are said to be continuous media, while those that match paged are said to be paged media
注記: 将来には、 この媒体~特能~用に,[ `連続的~媒体$と`~paged媒体$の側面を組合せた,~hybridな挙動を備える~UA ]が成す~classを述べるような~~新たな値が追加され得る。 例えば,(今や打ち切られた) `Presto^en ~layout~engineが出荷した半~page割りされる呈示~modeは、 強制d~page分断を尊守することを除いて,`連続的~媒体$に類似な挙動を備えていた。 ~WGが知る限り、 現在~出荷-中にある~UAには,この種の挙動を備えるものは無い — そのような~UAを誤って特徴付けるのを避けるため、 ~WGは[ そのような値は、 この~levelでは追加しない ]ものと裁定した。 上に指定した どの値でも必要十分に述べれない~UAを実装している者は、 この媒体~特能に対する拡張が考慮され得るよう,~WGに連絡することが奨励される。 ◎ Note: Additional values for this media feature may be added in the future to describe classes of user agents with a hybrid behavior combining aspects of continuous and paged media. For example, the Presto layout engine (now discontinued) shipped with a semi-paginated presentation-mode behavior similar to continuous except that it honored forced page breaks. Not knowing of any currently-shipping user agent with this type of behavior, the Working Group has decided not to add such a value in this level to avoid mischaracterizing any such user agent. Anyone implementing a user agent not adequately described by any of the values specified above is encouraged to contact the Working Group so that extensions to this media feature may be considered.
4.6. 行内-軸~~方向の~overflow: `overflow-inline^d
◎述 `overflow-inline@d ◎用 `media$at ◎値 `none$v | `scroll$v ◎型 `離散$ ◎表終媒体~特能 `overflow-inline$d は、[ 内容が`初期~包含塊$の`行内-軸$~~方向に~overflowするとき ]の,装置の挙動を述べる。 ◎ The overflow-inline media feature describes the behavior of the device when content overflows the initial containing block in the inline axis.
- `none@v
- `行内-軸$~~方向の~overflowに対し,便宜を図ることはない — ~overflowした内容は,単に表示されない。 ◎ There is no affordance for overflow in the inline axis; any overflowing content is simply not displayed.
- `scroll@v
- `行内-軸$~~方向に~overflowした内容を,利用者による~scrollで露わにできるようにする。 ◎ Overflowing content in the inline axis is exposed by allowing users to scroll to it.
注記: [ 行内~~方向へ~overflowする内容に対し,~pageを~~割付ける ]ような既知な実装は無く,概念そのものがイミを成さないので、 `overflow-inline$d 用には,値 `paged^v は意図的に省かれている。 ◎ Note: There are no known implementations of paged overflow of inline-overflowing content, and the very concept doesn’t seem to make much sense, so there is intentionally no paged value for overflow-inline.
4.7. 横方向の表示域~区分: `horizontal-viewport-segments^d 特能
【この節は、~level 4 に対する追加。】
◎述 `horizontal-viewport-segments@d ◎用 `media$at ◎値 `integer$t ◎型 `範囲$ ◎表終`horizontal-viewport-segments$d 媒体~特能は、 横~方向における[ 表示域を成す論理的な区分 ]の個数を述べる。 ◎ The horizontal-viewport-segments media feature describes the number of logical segments of the viewport in the horizontal direction.
`horizontal-viewport-segments$d 媒体~特能に対する`負な範囲は偽になる$。 ◎ The horizontal-viewport-segments media feature is false in the negative range.
表示域が[ 論理的な分割子として動作するような,何らかの~hardware特能 (折り曲げ可能な~displayの折り目など) ]により分割されているとき、 各~区分は,[ ~pageにより,論理的に別個なものとして扱える ]ような[ 表示域の領域 ]になる。 ◎ When the viewport is split by one or more hardware features (such as a fold or a hinge between separate displays) that act as a logical divider, segments are the regions of the viewport that can be treated as logically distinct by the page.
4.8. 縦方向の表示域~区分: `vertical-viewport-segments^d 特能
【この節は、~level 4 に対する追加。】
◎述 `vertical-viewport-segments@d ◎用 `media$at ◎値 `integer$t ◎型 `範囲$ ◎表終`vertical-viewport-segments$d 媒体~特能は、 縦~方向における[ 表示域を成す論理的な区分 ]の個数を述べる。 ◎ The vertical-viewport-segments media feature describes the number of logical segments of the viewport in the vertical direction.
`vertical-viewport-segments$d 媒体~特能に対する`負な範囲は偽になる$。 ◎ The vertical-viewport-segments media feature is false in the negative range.
次の媒体~queryは、 表示域が[ 正確に 2 個の,隣り合う区分からなる ]かどうかを検出する。 ◎ This media query detects a viewport that has exactly two segments that are side-by-side.
@media (horizontal-viewport-segments: 2) and (vertical-viewport-segments: 1) { … }
4.9. 表示~mode: `display-mode^d 媒体~特能
◎述 `display-mode@d ◎用 `media$at ◎値 `fullscreen$v | `standalone$v | `minimal-ui$v | `browser$v | `picture-in-picture$v ◎型 `離散$ ◎表終`display-mode$d `媒体~特能$は、[ 現在の`閲覧~文脈$は、 末端-利用者に対し,現在どの~modeの下で呈示されているか ]を述べる。 子~閲覧~文脈における`表示~mode$は、 その`~top-level閲覧~文脈$の`表示~mode$に合致するモノトスル。 ◎ The display-mode media feature describes the mode in which the current browsing context is currently being presented to the end user. In child browsing contexts, the display mode must match that of the top-level browsing context.
この特能は、 首に[ ~UAが`~app文脈$に対し適用した`表示~mode$ ]を決定するために利用される。 そのようなわけで、 この特能の値たちは, `APPMANIFEST$r にて定義される`表示~mode$に対応する。 しかしながら、 非-~app文脈においても,表示域が他の~mode下 — ~fullscreenや~picture-in-pictureなど — にあるかどうか決定するために利用できる。 ◎ This feature is primarily used to determine which display mode the user agent has applied to an application context. As such, the values of this feature correspond to the display modes defined in [APPMANIFEST]. However, it can also be used in non-application contexts to determine whether the viewport is in other modes, such as fullscreen or picture-in-picture.
- `fullscreen@v
- 当の閲覧~文脈は、[ ~browserの~UI要素は隠される下で,可用な表示-区画~全体を占める ]よう表示されている。 ~fullscreen文脈を生じさせ得るものには、 次が挙げられる ⇒# `~app~manifest$における `fullscreen$l 表示~mode/ `Fullscreen API$cite の `requestFullscreen()$c ~method/ 他の何らかの手段(利用者は、~UAに組込みの~controlを利用して~fullscreen~modeを手動で作動化しているなど)。 ◎ The browsing context is displayed with browser UI elements hidden and takes up the entirety of the available display area. The fullscreen context may have been caused by the fullscreen display mode in the application manifest, by the requestFullscreen() method of the Fullscreen API, or through some other means (such as the user manually activating fullscreen mode using the user agent’s built-in controls).
- `fullscreen$l 表示~modeに対応する。 ◎ Corresponds to the fullscreen display mode.
- `standalone@v
- `standalone$l 表示~modeが利用-中にある。 `~app文脈$内に限り適用-可能になる。 ◎ The standalone display mode is in use. Only applicable in an application context.
- `minimal-ui@v
- `minimal-ui$l 表示~modeが利用-中にある。 `~app文脈$内に限り適用-可能になる。 ◎ The minimal-ui display mode is in use. Only applicable in an application context.
- `browser@v
- 当の閲覧~文脈は、[ ~UA内で~hyperlinkを開くための~platformに特有な規約 ]を利用して表示されている (例: ~URL~barなどの~controlを伴う~browser[ ~UItab/~UIwindow ]内に)。 これは、 非-`~app文脈$用に,適切な表示~modeが他に無い所で利用されるベキである。 ◎ The browsing context is displayed using the platform-specific convention for opening hyperlinks in the user agent (e.g., in a browser tab or web browser window with controls such as an address bar). This should be used for non-application contexts where no other display mode is appropriate.
- `browser$l 表示~modeに対応する。 ◎ Corresponds to the browser display mode.
- `picture-in-picture@v
- この~modeは、 利用者が自身の機器で[ 他の~siteや~appとヤリトリしている間 ]も~mediaを消費し続けることを許容する。 閲覧~文脈は、 常に上層に浮動している~UIwindow上に表示される。 ~UAは、 ~platformに特有な他の~UI要素を含めてもヨイ — “~UItabへ戻る”, “~site情報” などの~button,あるいは、 ~platformや~UAにて恒例な何であれ。 ◎ This mode allows users to continue consuming media while they interact with other sites or applications on their device. The browsing context is displayed in a floating and always-on-top window. A user agent may include other platform specific UI elements, such as "back-to-tab" and "site information" buttons or whatever is customary on the platform and user agent.
例えば,`~app~manifest$は、 次のように `standalone$l `表示~mode$を要請し得る: ◎ For example, the application manifest can request the standalone display mode as follows:
{ "display": "standalone" }
~UAが実際に `standalone$l ~modeを適用したかどうかは、 次の媒体~queryを利用して決定できる: ◎ This media query can be used to determine whether the user agent has actually applied the standalone mode:
@media (display-mode: standalone) { … }
~UAは、 現在~利用-中にある実際の~modeに依存して, `display-mode$d を他の値に設定することもある。 ◎ The user agent could set display-mode to any of the other values, depending on the actual mode currently in use.
`fullscreen$l `表示~mode$は、 `Fullscreen API$cite とは別物である。 ◎ The fullscreen display mode is distinct from the Fullscreen API.
`display-mode^d 用の値 `fullscreen$v はまた、 `fullscreen$ps 疑似類には直に関係しない。 `fullscreen$ps 疑似類は、 ある要素が~fullscreen要素~stackの中に置かれたとき,その要素に排他的に合致する。 しかしながら, `Fullscreen API^cite を利用して[ ある要素に対し `requestFullscreen()$c ~methodを~callすること ]には、[ ~browserが~OS~levelで~fullscreen~modeに入る副作用 ]がある。 そのような事例では、[ `fullscreen$ps 疑似類, `(display-mode: fullscreen)^css ]どちらも合致することになる。 ◎ The fullscreen value for display-mode is not directly related to the CSS :fullscreen pseudo-class. The :fullscreen pseudo-class matches an element exclusively when that element is put into the fullscreen element stack. However, a side effect of calling the requestFullscreen() method on an element using the Fullscreen API can be that the browser enters a fullscreen mode at the OS-level, in which case both :fullscreen and (display-mode: fullscreen) will match.
一部の~platformでは、 利用者 — または `Web Application Manifest^cite `APPMANIFEST$r — 用に,~web~appを[ `Fullscreen API^cite を呼出すことなく,~fullscreenの中に置く ]こともアリである。 これが起きたときは、 `fullscreen$ps 疑似類は合致しないが, `(display-mode: fullscreen)^css は合致することになる。 下の~CSS~codeに例を与える。 ◎ On some platforms, it is possible for a user—or a Web Application Manifest—to put a web application into fullscreen without invoking the Fullscreen API. When this happens, the :fullscreen pseudo class will not match, but (display-mode: fullscreen) will match. This is exemplified in CSS code below:
/* 次は、 表示域が~fullscreenになったとき適用される: ◎ applies when the viewport is fullscreen */ @media (display-mode: fullscreen) { … } /* 次は、 要素が~fullscreenになったとき適用される: ◎ applies when an element is fullscreen */ #game:fullscreen { … }
注記: 将来に, `APPMANIFEST$r に新たな`表示~mode$が追加されたなら、 この媒体~特能~用にも,それに合致する新たな値が追加され得る。 ◎ Note: Additional values for this media feature may be added in the future to match new display modes added to [APPMANIFEST].
5. 表示~品質に関する媒体~特能
5.1. ~display解像度: `resolution^d
◎述 `resolution@d ◎用 `media$at ◎値 `resolution$t | `infinite$v ◎型 `範囲$ ◎表終媒体~特能 `resolution$d は、 出力~装置の解像度を述べる。 すなわち,`~page~zoom$は織り込む一方で,~pinch~zoom【`視覚-表示域$の`拡縮率$vV】は 1.0 と見做す下での画素~密度。 ◎ The resolution media feature describes the resolution of the output device, i.e. the density of the pixels, taking into account the page zoom but assuming a pinch zoom of 1.0.
`resolution$d に対する`負な範囲は偽になる$。 ◎ The resolution media feature is false in the negative range
画素が正方形でない装置を~queryする際には、 `resolution$d は,縦~次元の密度を~queryする。 ◎ When querying media with non-square pixels, resolution queries the density in the vertical dimension.
印刷機に対しては、 これは網点~解像度(任意な有色~dotを印刷するための解像度)に対応する。 この解像度は、 ~grayscale印刷に対しては異なり得る。 ◎ For printers, this corresponds to the screening resolution (the resolution for printing dots of arbitrary color). Printers might have a different resolution for grayscale printing.
解像度に物理的な拘束のない出力~媒体(~vector~graphicsを出力するときなど)に対しては、 この特能の`実~値$は `infinite@v になるモノトスル【!match】。 `範囲~文脈$の下でこの媒体~特能を評価する目的においては、 `infinite$v は,アリな どの `resolution$t よりも大きいものと扱うモノトスル (すなわち、 `(resolution > 1000dpi)^css の様な~queryは, `実~値$ `infinite$v をとる媒体に対しては `真^i になる) ◎ For output mediums that have no physical constraints on resolution (such as outputting to vector graphics), this feature must match the infinite value. For the purpose of evaluating this media feature in the ranghrger than any possible <resolution>. (That is, a query like (resolution > 1000dpi) will be true for an infinite media.)
次の媒体~queryは、 単純に “高解像度” ~screen(~hardware画素から~CSS `px$u への比率が 2 以上のもの)を検出する: ◎ This media query simply detects “high-resolution” screens (those with a hardware pixel to CSS px ratio of at least 2):
@media (resolution >= 2dppx)
例えば,次の媒体~queryは、 装置の解像度が 1 ~CSS `in$u あたり 300 ~dot以上のときに限り,~stylesheetが利用されることを表出する: ◎ For example, this media query expresses that a style sheet is used on devices with resolution greater than 300 dots per CSS in:
@media print and (min-resolution: 300dpi) { … }
~CSS `cm$u 単位を利用する,上の例と等価な媒体~query: ◎ This media query is equivalent, but uses the CSS cm unit:
@media print and (min-resolution: 118dpcm) { … }
`resolution$t は、 物理的な長さ単位あたりの装置~画素~数ではなく, 1 ~CSS画素( `px$u )あたりの装置~画素~数を参照rする。 この対応付けは,~UAが決めるので、 常に~UAに既知である。 ◎ <resolution> does not refer to the number of device pixels per physical length unit, but the number of device pixels per css unit. This mapping is done by the user agent, so it is always known to the user agent.
~UAが,物理-画素の幾何についての知識がない, または 物理-画素の幾何が正方形である(またはそれに十分に近い)ことを知っている場合、 ~CSS画素あたりの装置~画素~数が,縦~軸と横~軸で異なる数に対応付けられることはない。 したがって、 縦, 横いずれの解像度にも違いは生じない。 ◎ If the user agent either has no knowledge of the geometry of physical pixels, or knows about the geometry physical pixels and they are (close enough to) square, it would not map a different number of device pixels per css pixels along each axis, and the would therefore be no difference between the vertical and horizontal resolution.
他の場合、 すなわち,~UAが縦~軸と横~軸で異なる数に対応付けるのは、 物理-画素が正方形でないことに呼応してであろう。 ~UAがこの知識を得る方法については,この仕様の視野~外であるが、 装置が 90 度~回転されたものと裁定するに十分な情報があれば,対応付けを入替えることができる。 ◎ Otherwise, if the UA chooses to map a different number along each axis, this would be to respond to physical pixels not being square either. How the UA comes to this knowledge is out of scope, but having enough information to take this decision, it can invert the mapping should the device be rotated 90 degrees.
5.2. ~display型: `scan^d
◎述 `scan@d ◎用 `media$at ◎値 `interlace$v | `progressive$v ◎型 `離散$ ◎表終媒体~特能 `scan$d は、 一部の出力~装置の走査法を述べる。 ◎ The scan media feature describes the scanning process of some output devices.
- `interlace@v
- CRT (ブラウン管)や一部の~plasma~TVの~screenでは、 “~interlaceな” 描画が利用されている: ~videoの各~frameに対し、 ~screen上の “偶数”, “奇数” 走査線を交替的に描画することで,人の~~知覚における様々な画像補正~能を利用して滑らかな動きを生産する。 これは、 半分の帯域幅~costで, FPS 【毎秒~frame数】が より高い放送を模倣-可能にする。 ◎ CRT and some types of plasma TV screens used “interlaced” rendering, where video frames alternated between specifying only the “even” lines on the screen and only the “odd” lines, exploiting various automatic mental image-correction abilities to produce smooth motion. This allowed them to simulate a higher FPS broadcast at half the bandwidth cost.
-
~interlaceな~screenに表示されるときは、 作者は:
- “櫛形残像” を避けるため,~frame間の速い運動を避けるべきである。
- `“twitter”@https://en.wikipedia.org/wiki/Interlaced_video#Interline_twitter$ 【モアレ(干渉縞)の一種】 を避けるため,~screen上の細部が `1px^v より幅広になることを確保するべきである。
- `progressive@v
- “~progressiveな” 描画を利用する~screenは、 各~frameごとに~screenを全部的に表示するので,特別な扱いは必要ない。 ◎ A screen using “progressive” rendering displays each screen fully, and needs no special treatment.
- [ 現代の大多数の~screen/すべての~computer~screen ]は、 ~progressiveな描画を利用する。 ◎ Most modern screens, and all computer screens, use progressive rendering.
例えば,語 “feet” を成す字は、 ~serif~fontにおいては線が細く,~interlaceな装置~上では “twitter” を生じさせ得る。 媒体~特能 `scan$d を利用すれば、 これを検出して, “twitter” が起こりにくい代替~fontを利用するようにできる: ◎ For example, the “feet” of letters in serif fonts are very small features that can provoke “twitter” on interlaced devices. The scan media feature can be used to detect this, and use an alternative font with less chance of “twitter”:
@media (scan: interlace) { body { font-family: sans-serif; } }
注記: これを書いている時点では、 既知な どの実装も, `scan^d に対しては `interlace^v ではなく `progressive^v に合致する。 ◎ Note: At the time of writing, all known implementations match scan: progressive rather than scan: interlace.
5.3. ~console~displayの検出-法: `grid^d
◎述 `grid@d ◎用 `media$at ◎値 `mq-boolean$t ◎型 `離散$ ◎表終媒体~特能 `grid$d は、 出力~装置が[ ~grid, ~bitmap ]のいずれであるかを~queryするために利用される。 出力~装置が~gridに基づく場合(例えば “tty” 端末や, ~~特定の等幅~fontで表示する携帯電話)の`実~値$は `1^v になり、 他の場合は `0^v になる。 ◎ The grid media feature is used to query whether the output device is grid or bitmap. If the output device is grid-based (e.g., a “tty” terminal, or a phone display with only one fixed font), the value will be 1. Otherwise, the value will be 0.
値~型 `mq-boolean@t は、[ `0^v か `1^v ]のみをとり得る `integer$t 値である。 他のどの整数~値も無効にされる。 注記: ~CSSにおいては, `-0^v は常に `0^v に等価であり, 妥当な `mq-boolean$t 値として受容される。 ◎ The <mq-boolean> value type is an <integer> with the value 0 or 1. Any other integer value is invalid. Note that -0 is always equivalent to 0 in CSS, and so is also accepted as a valid <mq-boolean> value.
注記: `mq-boolean$t 型は、 旧来の目的においてのみ存在する。 今,この特能を設計するなら、 それぞれの`実~値$に対応する適正な名前の~keywordを利用するであろう。 ◎ Note: The <mq-boolean> type exists only for legacy purposes. If this feature were being designed today, it would instead use proper named keywords for its values.
幅狭な~console~screenを検出する例: ◎ Here is an example that detects a narrow console screen:
@media (grid) and (max-width: 15em) { … }
注記: これを書いている時点では、 既知な どの実装も, `grid^d に対しては `1^v ではなく `0^v に合致する。 ◎ Note: At the time of writing, all known implementations match grid: 0 rather than grid: 1.
5.4. ~display更新~頻度: `update^d
◎述 `update@d ◎用 `media$at ◎値 `none$v | `slow$v | `fast$v ◎型 `離散$ ◎表終媒体~特能 `update$d は、 出力~装置が,すでに描画された内容の外観を改変する能を備えているかどうかを~queryするために利用される。 これは、 次に挙げる値を受容する: ◎ The update media feature is used to query the ability of the output device to modify the appearance of content once it has been rendered. It accepts the following values:
- `none@v
- いったん描画された~layoutは更新されない。 例:紙~上に印刷された文書 ◎ Once it has been rendered, the layout can no longer be updated. Example: documents printed on paper.
- `slow@v
- ~layoutは~CSSによる通例の規則に則って動的に変化し得るが、 出力~装置は,その変化を[ 滑らかな~animationとして知覚される程 十分~素早く描画する†/表示する ]ことはできない。 例: E-ink ~screenや 電力が厳しい装置。 ◎ The layout may change dynamically according to the usual rules of CSS, but the output device is not able to render or display changes quickly enough for them to be perceived as a smooth animation. Example: E-ink screens or severely under-powered devices.
- 【† 原語の “`render^en” は視覚-媒体~以外にも適用し得る語であるが、 例えば聴覚-媒体においては,この特能はイミを成さない(有意な効果は無い)であろう。 】
- `fast@v
- ~layoutは,~CSSによる通例の規則に則って動的に変化でき、 出力~装置にも速度~面で~~特に拘束されることなく, CSS Animations などによる常時更新にも利用できる。 例:~computer~screen。 ◎ The layout may change dynamically according to the usual rules of CSS, and the output device is not unusually constrained in speed, so regularly-updating things like CSS Animations can be used. Example: computer screens.
例えば、 ~pageの~styleが~linkに対し ~hover時にのみ下線を引くときでも、 印刷されるときは,常に下線を表示するよう求まれることもあろう: ◎ For example, if a page styles its links to only add underlines on hover, it may want to always display underlines when printed:
@media (update) {
a { text-decoration: none; }
a:hover, a:focus { text-decoration: underline; }
}
/*
更新がない~UAにおいては常に、
~linkに対する既定の下線が引かれる。
◎
In non-updating UAs, the links get their default underline at all times.
*/
5.5. ~display技術の検出-法: `environment-blending^d 特能
◎述 `environment-blending@d ◎用 `media$at ◎値 `opaque$v | `additive$v | `subtractive$v ◎型 `離散$ ◎表終媒体~特能 `environment-blending$d は、 利用者の~displayの特性を~queryする。 作者は、 ~display技術に応じて~pageの視覚-や~layoutを調整することにより, ~~視認性を~~改善できるようになる。 ◎ The environment-blending media feature is used to query the characteristics of the user’s display so the author can adjust the style of the document. An author might choose to adjust the visuals and/or layout of the page depending on the display technology to increase the appeal or improve legibility.
妥当な値は: ◎ The following values are valid:
- `opaque@v
- 文書は,伝統的な~monitorや紙などの不透明な媒体~上に具現化されている。 黒は暗になり,白は 100% 明になる。 ◎ The document is rendered on an opaque medium, such as a traditional monitor or paper. Black is dark and white is 100% light.
- `additive@v
- ~displayは、 ~canvasの色と実世界のそれを加法的に混色している。 黒は全-透明になり【すなわち、実世界の風景が透過する】,白は 100% 明になる。 ◎ The display blends the colors of the canvas with the real world using additive mixing. Black is fully transparent and white is 100% light.
- 例えば、 車内 `head-up^en ~display。 【 “HUD”— 外の風景と重ね合わせて表示する装置】 ◎ For example: a head-up display in a car.
- `subtractive@v
- ~displayは、 ~canvasの色と実世界のそれを減法的に混色している。 白は全-透明になり,色が暗なほど【実世界との】~contrastが高くなる。 ◎ The display blends the colors of the canvas with the real world using subtractive mixing. White is fully transparent and dark colors have the most contrast.
- 例えば、 浴室の鏡に埋込まれた~LCD~display。 ◎ For example: an LCD display embedded in a bathroom mirror.
`subtractive$v 値の必要性はあるのか? ◎ Is there a need for the subtractive value?
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^d
◎述 `color@d ◎用 `media$at ◎値 `integer$t ◎型 `範囲$ ◎表終媒体~特能は `color$d は、 出力~装置における各~色~成分あたりの~bit数を述べる。 非~有色~装置に対する`実~値$は、 `0^v になる。 ◎ The color media feature describes the number of bits per color component of the output device. If the device is not a color device, the value is zero.
`color$d に対する`負な範囲は偽になる$。 ◎ color is false in the negative range.
例えば,次の2つの媒体~queryは、[ ~stylesheetが適用されるのは,装置が有色であるときに限られる ]ことを表出する: ◎ For example, these two media queries express that a style sheet applies to all color devices:
@media (color) { … } @media (min-color: 1) { … }
次の媒体~queryは、[ ~stylesheetが適用されるのは,装置が有色で, 色の各~成分あたり 8 ~bit以上のときに限られる ]ことを表出する: ◎ This media query expresses that a style sheet applies to color devices with at least 8 bits per color component:
@media (color >= 8) { … }
色~成分ごとに~bit数が異なる場合、 最~小な数が利用される。 ◎ If different color components are represented by different number of bits, the smallest number is used.
例えば ( R, G, B ) 成分を順に ( 3, 3, 2 ) ~bitで表現する 8 ~bit色~systemの場合、 `color$d 媒体~特能の`実~値$は `2^v になる。 ◎ For instance, if an 8-bit color system represents the red component with 3 bits, the green component with 3 bits, and the blue component with 2 bits, the color media feature will have a value of 2.
有index色~装置に対しては、 色~検索表の中の各~色あたりの最小な~bit数が利用される。 ◎ In a device with indexed colors, the minimum number of bits per color component in the lookup table is used.
注記: 上述の機能性が述べ得る色の能力は,表層~levelに限られる。 一般には、 `color-gamut$d の方が作者の必要に関連する。 更なる機能性が要求される場合、 `RFC2879$r が、 より詳細化された媒体~特能を供する — 将来的に~supportされ得る。 ◎ Note: The described functionality is only able to describe color capabilities at a superficial level. color-gamut, is generally more relevant to authors’ needs. If further functionality is required, RFC2879 [RFC2879] provides more specific media features which may be supported at a later stage.
6.2. 有index色~screen: `color-index^d
◎述 `color-index@d ◎用 `media$at ◎値 `integer$t ◎型 `範囲$ ◎表終媒体~特能 `color-index$d は、 出力~装置の色~検索表に含まれる色~数を述べる。 色~検索表を利用しない装置に対する`実~値$は、 `0^v になる。 ◎ The color-index media feature describes the number of entries in the color lookup table of the output device. If the device does not use a color lookup table, the value is zero.
`color-index$d に対する`負な範囲は偽になる$。 ◎ color-index is false in the negative range.
例えば次の 2 つは,どちらも、[ 有index色~装置ならば,~stylesheetを適用する ]ことを表出する: ◎ For example, here are two ways to express that a style sheet applies to all color index devices:
@media (color-index) { … } @media (color-index >= 1) { … }
次の媒体~queryは、[ ~stylesheetが適用されるのは, 256 色~以上の有index色~装置に限られる ]ことを表出する: ◎ This media query expresses that a style sheet applies to a color index device with 256 or more entries:
<?xml-stylesheet media="(min-color-index: 256)" href="http://www.example.com/…" ?>
6.3. 単彩色~screen: `monochrome^d
◎述 `monochrome@d ◎用 `media$at ◎値 `integer$t ◎型 `範囲$ ◎表終媒体~特能 `monochrome$d は、 単彩色~frame~buffer内の画素あたりの~bit数を述べる。 単彩色でない出力~装置に対する`実~値$は、 `0^v になる。 【単彩色( `monochrome^en )— 無彩色(灰色)に限らず, “濃淡のみ” の装置も該当するであろう。】 ◎ The monochrome media feature describes the number of bits per pixel in a monochrome frame buffer. If the device is not a monochrome device, the output device value will be 0.
`monochrome$d に対する`負な範囲は偽になる$。 ◎ monochrome is false in the negative range.
例えば,次のものは、[ すべての単彩色~装置に~stylesheetを適用する ]ことを表出する: ◎ For example, this is how to express that a style sheet applies to all monochrome devices:
@media (monochrome) { … }
次のものは、[ 画素あたり 2 ~bit以上の単彩色~装置に~stylesheetを適用する ]こと表出する。 ◎ Express that a style sheet applies to monochrome devices with more than 2 bits per pixels:
@media (monochrome >= 2) { … }
次のものは、 有色~page用の~stylesheetと単彩色~用の別の~stylesheetを表出する: ◎ Express that there is one style sheet for color pages and another for monochrome:
<link rel="stylesheet" media="print and (color)" href="http://…" /> <link rel="stylesheet" media="print and (monochrome)" href="http://…" />
6.4. 有色~displayの色域: `color-gamut^d
◎述 `color-gamut@d ◎用 `media$at ◎値 `srgb$v | `p3$v | `rec2020$v ◎型 `離散$ ◎表終`color-gamut$d 媒体~特能は、 ~UAと出力~装置が~supportする色の近似的な範囲を述べる。 すなわち,~UAが指定された色~空間を伴う内容を受取った場合には、 適切な色で — または それに十分近い何かで適切に — 出力~装置に描画させられる。 ◎ The color-gamut media feature describes the approximate range of colors that are supported by the UA and output device. That is, if the UA receives content with colors in the specified space it can cause the output device to render the appropriate color, or something appropriately close enough.
注記: この~queryは、 いくつかの理由から,近似的な範囲を利用するようにされている。 第一に、 ~display~hardwareには,ばらつきがある。 例えば, "Rec. 2020" を~supportするものと主張する装置であっても、 実際には全部的な色域より有意に狭い範囲で描画するものもある。 第二に、 ~supportされる色~範囲は 装置ごとに多種多様であり, それらすべてを挙げていっては長大になり過ぎる。 ほとんどの事例では、 作者は~displayの正確な能力を知る必要はなく, sRGB 以上か, または sRGB より有意に良いかを区別するだけで済む。 そうやって,色~profile付きの適切な画像を利用者に~serveできる。 ◎ Note: The query uses approximate ranges for a few reasons. Firstly, there are a lot of differences in display hardware. For example, a device might claim to support "Rec. 2020", but actually renders a significantly lower range of the full gamut. Secondly, there are a lot of different color ranges that different devices support, and enumerating them all would be tedious. In most cases the author does not need to know the exact capabilities of the display, just whether it is better than sRGB, or significantly better than sRGB. That way they can serve appropriate images, tagged with color profiles, to the user.
- `srgb@v
- ~UAも出力~装置も、 sRGB に指定されるもの以上の色域を,近似的に~supportできる。 ◎ The UA and output device can support approximately the sRGB gamut or more.
- 注記: 大部分の有色~displayは、 この型の~queryに対し `真^i を返せるものと期待できる。 ◎ Note: It is expected that the vast majority of color displays will be able to return true to a query of this type.
- `p3@v
- ~UAも出力~装置も、 Display P3 `Display-P3$r 色~空間に指定されるもの以上の色域を,近似的に~supportできる。 ◎ The UA and output device can support approximately the gamut specified by the Display P3 [Display-P3] Color Space or more.
- 注記: `p3$v 色域は `srgb$v より~~真に広い。 ◎ Note: The p3 gamut is larger than and includes the srgb gamut.
- `rec2020@v
- ~UAも出力~装置も、 `ITU-R Recommendation BT.2020^cite 色~空間に指定されるもの以上の色域を,近似的に~supportできる。 ◎ The UA and output device can support approximately the gamut specified by the ITU-R Recommendation BT.2020 Color Space or more.
- 注記: `rec2020$v 色域は `p3$v 色域より~~真に広い。 ◎ Note: The rec2020 gamut is larger than and includes the p3 gamut.
次の表tに、 これらの色~空間の原色を挙げる — 各 色は、 `COLORIMETRY$r に定義される,色~空間における純色度( `chromaticity^en )座標で表されている: ◎ The following table lists the primary colors of these color spaces in terms of their color space chromaticity coordinates, as defined in [COLORIMETRY].
色~空間 ◎ Color Space | 白色点 ◎ White Point | 原色 ◎ Primaries | ||||||
---|---|---|---|---|---|---|---|---|
Red | Green | Blue | ||||||
xW | yW | xR | yR | xG | yG | xB | yB | |
`srgb$v | 0.3127 | 0.3290 | 0.640 | 0.330 | 0.300 | 0.600 | 0.150 | 0.060 |
`p3$v | 0.3127 | 0.3290 | 0.680 | 0.320 | 0.265 | 0.690 | 0.150 | 0.060 |
`rec2020$v | 0.3127 | 0.3290 | 0.708 | 0.292 | 0.170 | 0.797 | 0.131 | 0.046 |
注記: 上の表tに与えた情報は、 色~空間を全部的に述べるには十分でないが, 出力~装置が当の色域を近似的に受持てるかどうか決定するには足る。 更なる情報は、[ sRGB については `SRGB$r / Display P3 については `Display-P3$r / ITU-R Recommendation BT.2020 については `ITU-R-BT-2020-2$r ]を見よ。 ◎ Note: The table above does not contains enough information to fully describe the color spaces, but is sufficient to determine whether an output device approximately covers their respective gamuts. See [SRGB] for more information on sRGB, [Display-P3] for more information on Display P3, and [ITU-R-BT-2020-2] for more information on ITU-R Recommendation BT.2020.
例えば,次の媒体~queryは、 ~displayが Display P3 による色~範囲を~supportするときに適用される: ◎ For example, this media query applies when the display supports colors in the range of Display P3:
@media (color-gamut: p3) { … }
注記: 出力~装置は、[ その全部的な出力~色域が十分~広い/ ~supportする色域が 別の~supportする色域を含む ]場合、 この媒体~特能に対する複数の`~test値$に対し, `真^i を返し得る。 その結果、 この特能は “~~昇格式に” 利用するのが最良になる — まず, `(color-gamut: srgb)^css が `真^i になるならば,基底となる値を設定した上で、 `(color-gamut: p3)^css が `真^i になるならば,それを上書きする,等々。 ◎ Note: An output device can return true for multiple values of this media feature, if its full output gamut is large enough, or one gamut is a subset of another supported gamut. As a result, this feature is best used in an "ascending" fashion—set a base value when (color-gamut: srgb) is true, then override it if (color-gamut: p3) is true, etc.
【 すなわち、 ~UAが `p3^v 色域を~supportするならば, この特能の`実~値$は値~集合 { `srgb^v, `p3^v } になり、 `rec2020$v 色域を~supportするならば, `実~値$は値~集合 { `srgb^v, `p3^v, `rec2020^v } になる。 】
注記: 単彩色~displayなど,一部の出力~装置は `srgb$v 色域でさえ~supportし得ない。 そのような装置を~testするときは、 この特能を,真偽-文脈の下で `not (color-gamut)^css のように否定形にして利用できる。 【`実~値$は空~集合になる。】 ◎ Note: Some output devices, such as monochrome displays, cannot support even the srgb gamut. To test for these devices, you can use this feature in a negated boolean-context fashion: not (color-gamut).
6.5. `dynamic-range^d 特能
【この節は、~level 4 に対する追加。】
◎述 `dynamic-range@d ◎用 `media$at ◎値 `standard$v | `high$v ◎型 `離散$ ◎表終`dynamic-range$d は、[ ~UA, 出力~装置 ]が~supportする[ 最大-明るさ, 色~深度, ~contrast比 ]の組合nを表現する。 ◎ dynamic-range represents the combination of max brightness, color depth, and contrast ratio that are supported by the user agent and output device.
- `high@v
-
~UAと出力~装置は、 どちらも,次に挙げる判定基準をすべて充足する: ◎ The user agent and the output device fulfill all of the following criteria:
- `高い~peak明るさ$を~supportする。 ◎ they support a high peak brightness it has a high peak brightness
- `高い~contrast比$を~supportする。 ◎ they support a high contrast ratio
- 色~深度は 24~bitを超える, あるいは~RGBの各~色~成分のそれは 8~bitを超える。 ◎ the color depth is greater than 24 bit or 8 bit per color component of RGB
- 注記: 一部の装置は、 そのような広域な動的~範囲~能力を常に作動化するとは限らず, (ときには~program的に/ときには利用者により/ときには内容に基づいて) 作動化される必要がある。 この媒体~特能は、 そのような~modeが作動中かどうかは~testしない — ~testするのは、[ 当の装置は、 そのような視覚的~能力を備えるかどうか ]だけである。 ◎ Note: Some devices have high dynamic range capabilities that are not always on, and that need to be activated (sometimes programmatically, sometimes by the user, sometimes based on the content). This media feature does not test whether such a mode is active, just whether the device is capable of high dynamic range visuals.
- `standard@v
- この値は、 任意の視覚的な装置に合致する — 視覚的な能力を欠如している装置には合致しない。 ◎ This value matches on any visual device, and not on devices lacking visual capabilities.
注記: この媒体~特能は同時に複数の値に合致し得る — `high$v に合致している~UAは、 `standard$v にも合致することになる。 ◎ Note: More than one value of this media feature can match simultaneously: a user agent matching high will also match standard.
【 すなわち、 `high$v に合致する下では,この特能の`実~値$は値~集合 { `high^v, `standard^v } になる。 】
6.5.1. 表示の~contrastと明るさの決定-法
`~peak明るさ@ とは、[ ~LCD【液晶~display】~screenなど,光を発する装置においては、 それが生産し得る最も明るい点/ 紙や~e-inkなど,光を反射する装置においては、 光を最も吸収しない点 ]が,どれだけ明るいかを参照rする。 ◎ Peak brightness refers to how bright the brightest point a light-emitting device such as an LCD screen can produce, or in the case of a light reflective device such as paper or e-ink, the point at which it least absorbs light.
注記: 一部の装置では、 所与の時点に生産し得る`~peak明るさ$は[ 短時間/表面の限られた部位 ]に限られる。 ◎ Note: Some devices can only produce their peak brightness for brief periods of time or on a small portion of their surface at any given time.
`~contrast比@ は、 ~systemが生産-可能な[ 最も明るい色の輝度 ]の[ 最も暗な色の輝度 ]に対する比である。 ◎ The contrast ratio is the ratio of the luminance of the brightest color to that of the darkest color that the system is capable of producing.
この仕様は、 これらの品質を測定する精確な仕方は定義しない。 何をもって[ `~contrast比$が `高い@cR / `~peak明るさ$が `高い@pR ]とされるか決定するのは、 ~UAに委ねられる。 それでも,~UAは、 次の意図に適合するよう試みるモノトスル: `高い~peak明るさ$能力がある装置は, “白より明るい” 高明度を表示でき、[ 深い黒も呈示すると同時に,そうする能(総体的に明るい画像においても,漂白されずに) ]は,~contrast比が`高い$cRことを指示するものになる。 ◎ This specification does not define precise ways by which these qualities can be measured; it also lets the user agent determine what counts as a high contrast ratio and as a high peak brightness. User agents must nonetheless attempt to conform to the following intent: a device capable of high peak brightness can display “brighter than white” highlights, and a simultaneous ability to do so while also presenting deep blacks (rather than an overall bright but washed out image) is indicative of a high contrast ratio.
注記: [ `dynamic-range$d, `video-dynamic-range$d ]の(`実~値$の)決定は,~UAに依存することになるが、 意味論は,広く依存-可能になると期待される。 ◎ Note: The determination for dynamic-range and video-dynamic-range will be vary depending on the user agent, but is expected to have broadly dependable semantics.
6.6. 表示における反転d色の検出-法: `inverted-colors^d 特能
【この節は、~level 4 に対する追加。】
◎述 `inverted-colors@d ◎用 `media$at ◎値 `none$v | `inverted$v ◎型 `離散$ ◎表終媒体~特能 `inverted-colors$d は、 内容の色が反転して表示されているかどうかを指示する。 ◎ The inverted-colors media feature indicates whether the content is displayed normally, or whether colors have been inverted.
これは,[ ~UAまたは下層~OSが,全画面で強制的に色を反転している ]ことを指示するものであり、 そうするよう要請するものではない。 これは、[ 利用者が~textと~~背景の明/暗を切替えれるようにする,単純な~accessibilityの特能 ]として供されることがある。 しかしながら、[ 写真まで反転する / 影を強調する ]などの,内容の可読性を~~損なう副作用もある。 ◎ Note: This is an indication that the user agent or underlying operating system has forcibly inverted all colors, not a request to do so. This is sometimes provided as a simple accessibility feature, allowing users to switch between light-on-dark and dark-on-light text. However, this has unpleasant side effects, such as inverting pictures, or turning shadows into highlights, which reduce the readability of the content.
- `none@v
- 色は通常と~~同じに表示されている。 ◎ Colors are displayed normally.
- `inverted@v
- 表示~区画~内のすべての画素は反転されている。 ◎ All pixels within the displayed area have been inverted.
-
この値は、 ~UAが何らかの種類の内容を自覚する反転 — 画像を保全するなど — を行なった場合には,合致しない【すなわち、`実~値$はこの値にならない】モノトスル。 ◎ This value must not match if the user agent has done some kind of content aware inversion such as one that preserves the images.
注記: これは、 この媒体~特能の目標が,[ `すべての画素^emを反転するような,内容を自覚しない~approachによる望ましくない効果 ]を[ 作者が軽減することを可能化する ]ことにあるからである。 内容を自覚する事例においても作者が対抗策をとれるとした場合、 ~UAの対抗策と互いに打ち消しあう~riskがある。 ◎ Note: This is because the goal of this media feature is to enable authors to mitigate the undesirable effects of the non content aware approach that invert all the pixels. If the author were to take counter measures even in the content-aware cases, their counter measures and the UA’s would be at risk of cancelling each other.
作者は、 自身の~stylesheetに依存して, 画像や動画を反転したいと望むこともあろう: ◎ Depending on their style sheet, authors may wish to invert images and videos:
@media (inverted-colors) { img:not(picture > img), picture, video { filter: invert(100%); } }
作者は、 ~CSSを介して注入された画像(背景など)を反転したり影を不能化することもあろう: ◎ Authors may also invert images injected via CSS (such as backgrounds), or disable shadows:
@media (inverted-colors) { * { text-shadow: none !important; box-shadow: none !important; } }
7. 対話~媒体に関する特能
“対話” 媒体~特能は、 利用者が~pageと対話する方法についての様々な側面を反映する。 ◎ The “interaction” media features reflect various aspects of how the user interacts with the page.
`pointer$d と `hover$d の種々の組合nに合致する,代表的な装置の例: ◎ Typical examples of devices matching combinations of pointer and hover:
`pointer$d: `none$v1
| `pointer$d: `coarse$v1
| `pointer$d: `fine$v1
| |
---|---|---|---|
`hover$d: `none$v1
| ~keyboardのみの制御, 連列的/空間的(十字key)~focus~navi ◎ keyboard-only controls, sequential/spatial (d-pad) focus navigation | ~smartphone, ~touch~screen ◎ smartphones, touch screens | 基本的な~stylus~digitizer( Cintiq, Wacom, 等々) ◎ basic stylus digitizers (Cintiq, Wacom, etc) |
`hover$d: `hover$v1
| Nintendo Wii ~controller, Xbox Kinect ◎ Nintendo Wii controller, Kinect | ~mouse, ~touch~pad, 高度な~stylus~digitizer( Surface, Samsung Note, Wacom Intuos Pro, 等々) ◎ mouse, touch pad, advanced stylus digitizers (Surface, Samsung Note, Wacom Intuos Pro, etc) |
[ `pointer$d / `hover$d ]特能は “首” ~pointing装置の特性に関係する一方で、[ `any-pointer$d / `any-hover$d ]は,可用になり得るすべての~pointing装置の~propを~queryするときに利用できる。 ◎ The pointer and hover features relate to the characteristics of the “primary” pointing device, while any-pointer and any-hover can be used to query the properties of all potentially available pointing devices.
注記: この仕様は,[ 何が “首” ~pointing装置とされるかを,~UAがどう裁定するべきか ]は定義しないが、 ~UAには,[ 稼働している装置や環境についての知識, 可用な~pointing装置の個数や型, これらのどの入力を[ 一般に あるいは現在 ]利用しているか ]を組合せて,これを決定するべき、 と期待されている。 首~入力機構を成す装置は~pointing装置でないが,利用~頻度がより少ない副次~入力~用の~pointing装置は在る状況では、 ~UAは[ ~pointing装置でないそれを首と扱う ]ものと裁定してもヨイ(その結果、 `pointer$d の`実~値$は `none$v になる)。 ~UAは、[ 利用者~環境や利用者が~UAと対話する仕方 ]の変化に呼応して,[ どの型の~pointing装置が首と判断されるか,動的に変更する ]ものと裁定してもヨイ。 ◎ Note: While this specification does not define how user agents should decide what the “primary” pointing device is, the expectation is that user agents should make this determination by combining knowledge about the device/environment they are running on, the number and type of pointing devices available, and a notion of which of these is generally and/or currently being used. In situations where the primary input mechanism for a device is not a pointing device, but there is a secondary – and less frequently used – input that is a pointing devices, the user agent may decide to treat the non-pointing device as the primary (resulting in 'pointer: none'). user agents may also decide to dynamically change what type of pointing device is deemed to be primary, in response to changes in the user environment or in the way the user is interacting with the UA.
注記: [ `pointer$d / `hover$d / `any-pointer$d / `any-hover$d ]特能が関係するのは,~pointing装置の特性や それらの有無に限られ、 ~keyboardなどの~pointing装置でない入力機構の有無を検出することには利用できない。 作者は、 これらの特能を~queryした結果に関わらず, ~pointing装置でない入力の~~可能性も織り込むべきである。 ◎ Note: The pointer, hover, any-pointer and any-hover features only relate to the characteristics, or the complete absence, of pointing devices, and can not be used to detect the presence of non-pointing device input mechanisms such as keyboards. Authors should take into account the potential presence of non-pointing device inputs, regardless of which values are matched when querying these features.
注記: [ `pointer$d / `hover$d ]は,[ ~pageの主途の[ ~styleと対話~mode ]を(首~pointing装置の特性や有無に基づいて)首~入力機構に適するように設計する ]ために利用できるが、 作者は[ `any-pointer$d / `any-hover$d ]を利用して,検出され得るすべての型の~pointing装置を織り込むことを強く考慮するべきである。 ◎ While pointer and hover can be used to design the main style and interaction mode of the page to suit the primary input mechanism (based on the characteristics, or complete absence, of the primary pointing device), authors should strongly consider using any-pointer and any-hover to take into account all possible types of pointing devices that have been detected.
7.1. ~pointing装置の品質: `pointer^d
◎述 `pointer@d ◎用 `media$at ◎値 `none$v | `coarse$v | `fine$v ◎型 `離散$ ◎表終媒体~特能 `pointer$d は、 ~mouseなどの~pointing装置が在ること, その正確度を~queryするために利用される。 複数の~pointing装置が在る場合、 媒体~特能 `pointer$d は,[ ~UAにより決定される “首” ~pointing装置 ]の特性を反映するモノトスル。 (可用な`すべて^emの~pointing装置の能力を~queryする方法については、 媒体~特能 `any-pointer$d を見よ。) ◎ The pointer media feature is used to query the presence and accuracy of a pointing device such as a mouse. If multiple pointing devices are present, the pointer media feature must reflect the characteristics of the “primary” pointing device, as determined by the user agent. (To query the capabilities of any available pointing devices, see the any-pointer media feature.)
- `none@v
- 首~入力機構を成す装置には、 ~pointing装置は含まれていない。 ◎ The primary input mechanism of the device does not include a pointing device.
- `coarse@v
- 首~入力機構を成す装置には,~pointing装置も含まれているが、 その正確度は制限されている。 例として、 ~touch~screenや動き検出~sensor( Xbox の周辺機器 Kinect の様な)が挙げられる。 ◎ The primary input mechanism of the device includes a pointing device of limited accuracy. Examples include touchscreens and motion-detection sensors (like the Kinect peripheral for the Xbox.)
- `fine@v
- 首~入力機構を成す装置には,正確aな~pointing装置も含まれている。 例として、 ~mouse, ~touch~pad, 手描き~stylusが挙げられる。 ◎ The primary input mechanism of the device includes an accurate pointing device. Examples include mice, touchpads, and drawing styluses.
`coarse$v, `fine$v どちらも,~pointing装置が在ることを指示するが、 正確度に関して異なる。 ~zoom係数 1 の下で,隣接する小さな対象を~~確実に摘むことが困難または不可能な~pointing装置では、 `coarse$v が選抜されることになる。 ~zoom~levelが変化しても、 この媒体~特能の`実~値$には影響しない。 ◎ Both coarse and fine indicate the presence of a pointing device, but differ in accuracy. A pointing device with which it would be difficult or impossible to reliably pick one of several small adjacent targets at a zoom factor of 1 would qualify as coarse. Changing the zoom level does not affect the value of this media feature.
注記: ~UAは、 利用者に~zoom能や正確度が異なる副次~pointing装置も供し得るので、 この媒体~特能の`実~値$が `coarse$v であっても, 利用者が正確aな~clickを遂行-可能なことはあり得る。 この値は、 利用者が決して正確aに~clickできないことを指示するものではなく, 簡便でないことのみを指示する。 作者には、 `coarse$v 値に反応するよう,正確aな~click操作に依拠しない~pageを設計することが期待されている。 ◎ Note: As the UA may provide the user with the ability to zoom, or as secondary pointing devices may have a different accuracy, the user may be able to perform accurate clicks even if the value of this media feature is coarse. This media feature does not indicate that the user will never be able to click accurately, only that it is inconvenient for them to do so. Authors are expected to react to a value of coarse by designing pages that do not rely on accurate clicking to be operated.
~accessibilityの理由から、 装置が備える~pointing装置を `fine$v として述べれるとしても、 ~UAは,利用者が~pointing装置の正確aな操作が[ 困難/全く操作できない ]ことを指示するためとして,この媒体~queryの`実~値$に[ `coarse$v / `none$v ]を与えてもヨイ。 加えて,利用者は[ 首~pointing装置の正確度が `fine$v であっても, 正確度が `coarse$v の~pointing装置を追加的に可用にし得る ]ので、 作者は[ そのような装置があり得ることも織り込むために, 媒体~特能 `any-pointer$d を~queryしたい ]と望むこともあろう。 ◎ For accessibility reasons, even on devices whose pointing device can be described as fine, the UA may give a value of coarse or none to this media query, to indicate that the user has difficulties manipulating the pointing device accurately or at all. In addition, even if the primary pointing device has fine pointing accuracy, there may be additional coarse pointing devices available to the user. Authors may wish to query the any-pointer media feature to take these other coarse potential pointing devices into account.
/*
正確aでない首~pointing装置の下では,~radio~buttonや~check-boxを大きくする
◎
Make radio buttons and check boxes larger if we have an inaccurate primary pointing device
*/
@media (pointer:coarse) {
input[type="checkbox"], input[type="radio"] {
min-width:30px;
min-height:40px;
background:transparent;
}
}
7.2. ~hover能力: `hover^d
◎述 `hover@d ◎用 `media$at ◎値 `none$v | `hover$v ◎型 `離散$ ◎表終媒体~特能 `hover$d は、[ ~page上の要素に対する首~pointing装置による~hover能 ]を~queryするために利用される。 複数の~pointing装置が在る場合、 媒体~特能 `hover$d は,[ ~UAにより決定される “首” ~pointing装置 ]の特性を反映するモノトスル。 (可用な~pointing装置 `すべて^emの能力を~queryする方法については、 媒体~特能 `any-hover$d を見よ。) ◎ The hover media feature is used to query the user’s ability to hover over elements on the page with the primary pointing device. If a device has multiple pointing devices, the hover media feature must reflect the characteristics of the “primary” pointing device, as determined by the user agent. (To query the capabilities of any available pointing devices, see the any-hover media feature.)
- `none@v
- 次を指示する ⇒ 首~pointing装置は、 無いか, ~hoverできない。 ◎ Indicates that the primary pointing device can’t hover, or that there is no pointing device.\
- 例として、[ ~touch~screen / 基本的な手描き~stylusを利用する~screen ]が挙げられる。 ◎ Examples include touchscreens and screens that use a basic drawing stylus.
- ~hoverはできるが,通常の利用の仕方の一部でなく不便な~pointing装置も、 この値に合致する。 例えば,長押しが~hoverに扱われるような~touch~screenは、 `hover$d: `none^v に合致することになる。 ◎ Pointing devices that can hover, but for which doing so is inconvenient and not part of the normal way they are used, also match this value. For example, a touchscreen where a long press is treated as hovering would match hover: none.
- `hover@v
- 次を指示する ⇒ 首~pointing装置は、 ~pageの各~所で容易に~hoverできる。 ◎ Indicates that the primary pointing device can easily hover over parts of the page.\
- 例として、 Nintendo Wii ~controllerの様な,~mouse, ~screen上の点を物理的に指す装置などが挙げられる。 ◎ Examples include mice and devices that physically point at the screen, like the Nintendo Wii controller.
例えば,~touch~screen装置では、 ~mouseでも制御できるとしても, 首~pointing装置(~touch~screen)では利用者は~hoverできないので, `hover$d `媒体~特能$は `none$v に合致するべきである。 ◎ For example, on a touch screen device that can also be controlled by an optional mouse, the hover media feature should match hover: none, as the primary pointing device (the touch screen) does not allow the user to hover.
しかしながら、
利用者は副~mouseでは~hoverできる。
したがって,作者は、[
`hover$d: `none^v
が `真^i に評価される装置~上では, `:hover^css 疑似類は決して合致しない
]と見做さないよう気を付けるべきであるが、
~hoverできなくても全部的に利用-可能になるように~layoutを設計するべきである。
◎
However, despite this, the optional mouse does allow users to hover. Authors should therefore be careful not to assume that the ':hover' pseudo class will never match on a device where 'hover:none' is true, but they should design layouts that do not depend on hovering to be fully usable.
~accessibilityの理由から、 ~UAは,装置が~hoverを~supportするときでも、 それなしでもきちんと働く~layoutも~opt-inするために, `hover$d の`実~値$に `none$v を与えてもヨイ。 また,首~入力機構の `hover$d の`実~値$が `hover$v のときでも、 利用者には~hover能力が無い入力機構も追加的に可用にされ得ることに注意。 ◎ For accessibility reasons, even on devices that do support hovering, the UA may give a value of hover: none to this media query, to opt into layouts that work well without hovering. Note that even if the primary input mechanism has 'hover: hover' capability, there may be additional input mechanisms available to the user that do not provide hover capabilities.
/*
簡便に~hover可能な装置に限り,~hoverで作動化される~drop-down~menuを利用する
◎
Only use a hover-activated drop down menu on devices that can conveniently 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^d, `any-hover^d
◎述 `any-pointer@d ◎用 `media$at ◎値 `none$v1 | `coarse$v1 | `fine$v1 ◎型 `離散$ ◎表終 ◎述 `any-hover@d ◎用 `media$at ◎値 `none$v1 | `hover$v1 ◎型 `離散$ ◎表終媒体~特能[ `any-pointer$d / `any-hover$d ]は、 利用者に可用なすべての~pointing装置の能力の和集合に対応することを除いて,媒体~特能[ `pointer$d / `hover$d ]と~~同じになる。 `any-pointer$d の事例では、 ~pointing装置ごとに特性が異なる場合には,合致する`~test値$は複数あり得る。 ◎ The any-pointer and any-hover media features are identical to the pointer and hover media features, but they correspond to the union of capabilities of all the pointing devices available to the user. In the case of any-pointer, more than one of the values can match, if different pointing devices have different characteristics.
`any-pointer$d / `any-hover$d に対する`~test値$ `none^v が合致するのは、[ どの~pointing装置の`実~値$も `none^v に合致するか,~pointing装置は皆無なとき ]に限られるモノトスル。 ◎ any-pointer and any-hover must only match none if all of the pointing devices would match none for the corresponding query, or there are no pointing devices at all.
注記: `any-pointer$d は、 ~pointing装置が在ること, および その正確度を~queryするために利用される。 それは、 ~pointing装置でない入力は織り込まない — すなわち、 ~screen上の~pointerを移動しない[ 十字key/~keyboard ]のみによる~controlなどの,他の入力機構が在ることを~testするときには利用できない。 `any-pointer$d に対する`~test値$ `none^v が `真^i に評価されるのは、 ~pointing装置は皆無の場合に限られる。 ◎ any-pointer is used to query the presence and accuracy of pointing devices. It does not take into account any additional non-pointing device inputs, and can not be used to test for the presence of other input mechanisms, such as d-pads or keyboard-only controls, that don’t move an on-screen pointer. 'any-pointer:none' will only evaluate to true if there are no pointing devices at all present.
~mouseと~keyboardを備える伝統的な~desktop環境においては、 `any-pointer$d に対する`~test値$ `none^v は, 非~pointer入力(~keyboard)が在っても(~mouseが在ることに因り) `偽^i になる。 ◎ On a traditional desktop environment with a mouse and keyboard, 'any-pointer:none' will be false (due to the presence of the mouse), even though a non-pointer input (the keyboard) is also present.
注記: `any-hover$d に対する`~test値$ `none^v が `真^i に評価されるのは、 どの~pointing装置も~hover能力を欠くか,~pointing装置は皆無の場合に限られる。 そのようなわけで、[ ~hover能力を欠く~pointing装置が 一つでも在るかどうか ]ではなく,[ ~hover能力がある~pointing装置が 一つでも在るかどうか ]を~testする~queryとして解されるべきである。 前者については、 現時点では, `any-hover$d その他の対話~用の媒体~特能を利用しても決定できない。 加えて、 元来~hover能力を欠く[ 十字key/~keyboard ]のみによる制御など,~pointing装置でない入力は織り込まれない。 ◎ 'any-hover:none' will only evaluate to true if there are no pointing devices, or if all the pointing devices present lack hover capabilities. As such, it should be understood as a query to test if any hover-capable pointing devices are present, rather than whether or not any of the pointing devices is hover-incapable. The latter scenario can currently not be determined using any-hover or any other interaction media feature. Additionally, it does not take into account any non-pointing device inputs, such as d-pads or keyboard-only controls, which by their very nature are also not hover-capable.
~mouseと~touch~screenを備え,~touchが可能化された~~機器においては、 `any-hover$d に対する`~test値$ `none^v は, ~hover能力を欠く~pointing装置 (~touch~screen)が在っても (~hover能力がある~mouseが在ることに因り) `偽^i に評価されることになる。 現時点では、 ~pointing装置ごとに~hover能力が異なる事例において, 異なる~styleを供することはアリでない。 ◎ On a touch-enabled laptop with a mouse and a touchscreen, 'any-hover:none' will evaluate to false (due to the presence of the hover-capable mouse), even though a non-hover-capable pointing device (the touchscreen) is also present. It is currently not possible to provide different styles for cases where different pointing devices have different hover capabilities.
注記: [ `any-hover$d / `any-pointer$d が,これらの能力を備える入力機構が 1 つ以上は可用であることを指示する ]ことに基づいて,[ ~hover, あるいは正確aな~pointing ]のみに依拠するような~pageを設計しても、 使用感が悪くなる可能性が高い。 しかしながら,作者は、 この情報を利用して,[ 利用者に可用な追加的な~pointing装置に基づいて,供したいと望む~styleと機能性についての裁定を伝える ]こともできる。 ◎ Designing a page that relies on hovering or accurate pointing only because any-hover or any-pointer indicate that at least one of the available input mechanisms has these capabilities is likely to result in a poor experience. However, authors may use this information to inform their decision about the style and functionality they wish to provide based on any additional pointing devices that are available to the user.
~screen上で~cursorを制御できる~smart~TVは,いくつもあるが、 正確aに操作oするのは困難な~~簡素な~controllerであることが多い。 ◎ A number of smart TVs come with a way to control an on-screen cursor, but it is often fairly basic controller which is difficult to operate accurately.
そのような~smart~TVにおける~browserでは、[ `pointer$d, `any-pointer$d ]どちらも `coarse$v を`実~値$にとり、 作者は,対象が大きく~clickし易い~layoutを供せるようになる。 ◎ A browser in such a smart TV would have coarse as the value of both pointer and any-pointer, allowing authors to provide a layout with large and easy to reach click targets.
利用者は,~bluetooth~mouseを備えた~TVを持っていて,ときには余分の便利~用にそれを利用することもあるが、 そのような~mouseは,~TVを操作oする主途の仕方ではない。 `pointer$d は依然として `coarse$v に合致する一方で, `any-pointer$d は今度は `coarse$v, `fine$v の両者に合致する。 【`実~値$は、これら 2 つの値からなる集合になる。】 ◎ The user may also have paired a Bluetooth mouse with the TV, and occasionally use it for extra convenience, but this mouse is not the main way the TV is operated. pointer still matches coarse, while any-pointer now both matches coarse and fine.
(`any-pointer^d: `fine^v)
が今度は `真^i になる事実に基づいて,小さい~click対象に切替えるのは、
適切にならないであろう。
それは、
~TVに期待される使用感を逸脱して利用者を驚かせるだけでなく、
ごく不便にもなり得る:
普段~TVの制御に使わない~mouseは、
手の届かない,ソファのクッションの下に隠れているかもしれない…
◎
Switching to small click targets based on the fact that (any-pointer: fine) is now true would not be appropriate. It would not only surprise the user by providing an experience out of line with what they expect on a TV, but may also be quite inconvenient: the mouse, not being the primary way to control the TV, may be out of reach, hidden under one of the cushions on the sofa...
対照的に、
同じ~TV上で~scrollすることを考える。
~scrollbarは、
正確aな~pointing装置でなければ操作-は困難である。
(`pointer^d: `coarse^v)
が `真^i になることに基づいて、[
見れる内容が更にあることを指示する,代替になる仕方
]も用意された下では、
作者は,依然として[
(`pointer^d: `fine^v)
が `真^i のときは,追加で~scrollbarを示し、
`偽^i のときは,まるごと隠して視覚的にスッキリさせたい
]と求めることもあろう。
◎
By contrast, consider scrolling on the same TV. Scrollbars are difficult to manipulate without an accurate pointing device. Having prepared an alternative way to indicate that there is more content to be seen based on (pointer: coarse) being true, an author may want to still show the scrollbars in addition if (any-pointer: fine) is true, or to hide them altogether to reduce visual clutter if (any-pointer: fine) is false.
8. `video-^d が接頭された特能
【この節は、~level 4 に対する追加。】
一部の~UA(多くの~TVを含む)は、[ ~video, ~graphic ]を別個な~screen特性を有する別々な “平面( `plane^en )” — ~video平面, ~graphics平面 — に描画する。 そのような能は、 “双平面” ( `bi-plane^en ) と称される。 ~video平面を述べるため、 `video-^d が接頭された各種~特能が供される。 ◎ Some user agents, including many TVs, render video and graphics in two separate "planes" (bi-plane) with distinct screen characteristics. A set of video-prefixed features is provided to describe the video plane.
双平面を実装する~UAは、[ 次に挙げる特能~用には~video平面/ 他の【 `video-^d を外した】特能~用には~graphics平面 ]に基づいて,それぞれの`実~値$を決定するモノトスル ⇒# `video-color-gamut$d, `video-dynamic-range$d ◎ Any bi-plane implementation must return values based on the video plane for the following features: video-color-gamut; video-dynamic-range. All other features must return values based on the graphics plane.
双平面を実装しない~UAは、[ `video-^d が接頭された特能, 対応する そうでない特能 【例: `video-color-gamut$d には `color-gamut$d が対応する】 ]どちらに対しても,同じ`実~値$を与えるモノトスル。 ◎ Non bi-plane implementations must return the same values for video-prefixed features and their non-prefixed counterparts.
8.1. `video-color-gamut^d 特能
◎述 `video-color-gamut@d ◎用 `media$at ◎値 `srgb^v | `p3^v | `rec2020^v ◎型 `離散$ ◎表終`video-color-gamut$d 媒体~特能は、[ ~UA, 出力~装置の~video平面 ]が~supportする色の近似的な範囲を述べる。 すなわち,~UAが指定された色~空間を伴う内容を受取った場合には、 適切な色で — または それに十分近い何かで適切に — 出力~装置に描画させられる。 ◎ The video-color-gamut media feature describes the approximate range of colors that are supported by the UA and output device’s video plane. That is, if the UA receives content with colors in the specified space it can cause the output device to render the appropriate color, or something appropriately close enough.
値と色~空間の定義は、 `color-gamut$d と同じである。 ◎ Value and color space definitions are the same as color-gamut
8.2. `video-dynamic-range^d 特能
◎述 `video-dynamic-range@d ◎用 `media$at ◎値 `standard^v | `high^v ◎型 `離散$ ◎表終`video-dynamic-range$d は、[ ~UA, 出力~装置 ]の~video平面が~supportする[ 最大-明るさ, 色~深度, ~contrast比 ]の組合nを表現する。 ◎ video-dynamic-range represents the combination of max brightness, color depth, and contrast ratio that are supported by the UA and output device’s video plane.
~supportされる値は、 `dynamic-range$d と同じである。 ◎ Supported values are the same as dynamic-range.
9. ~scriptingに関する媒体~特能
【この節は、~level 4 に対する追加。】
9.1. ~scripting~support:`scripting^d 特能
◎述 `scripting@d ◎用 `media$at ◎値 `none$v | `initial-only$v | `enabled$v ◎型 `離散$ ◎表終媒体~特能 `scripting$d は、[ ~JSなどの~script用~言語が,現在の文書にて~supportされているかどうか ]を~queryするために利用される。 ◎ The scripting media feature is used to query whether scripting languages, such as JavaScript, are supported on the current document.
- `enabled@v
- 次を指示する ⇒ ~UAは~pageの~scriptingを~supportしていて、 現在の文書における~scriptingは文書が存続する限り作動中である。 ◎ Indicates that the user agent supports scripting of the page, and that scripting in the current document is enabled for the lifetime of the document.
- `initial-only@v
- 次を指示する ⇒ ~UAは~pageの~scriptingを~supportしていて、 現在の文書における~scriptingは~pageの初期 読込n時だけ可能化されていているが,その後は~supportされない。 ◎ Indicates that the user agent supports scripting of the page, and that scripting in the current document is enabled during the initial page load, but is not supported afterwards.\
- 例えば、 印刷された~pageや, (~pageを~server上で具現化して,~pageのほぼ静的な~versionを利用者に送信するような)事前具現化~network~proxy。 ◎ Examples are printed pages, or pre-rendering network proxies that render a page on a server and send a nearly-static version of the page to the user.
- どこまでを初期~scriptingに含めるべきか — すなわち、 `実~値$が `initial-only$v になるための~~境を,明示的に設定するべきか? そのようなものがあれば、 作者は依存できるものを知った上で,それに則って~scriptを誂えることも可能になる。 一方で、 含めるべき~~範囲を突き詰めるのは困難である: 狭め過ぎた場合、 作者が依存できる~scriptingの便宜性は,実用的になる所まで拘束されるであろう — 実際には,すべての~UAがより有意に広い所まで~supportできるとしても。 が,より広げようとすると、 ~UAのうち,[ 読込n時の~scriptingは~supportするが、 事例によっては複階的な経験則に基づいてそれを制約するもの ]を除外することになる。 一例として、 保守的な定義は,少なくとも[ すべての~inline~scriptを走らせて `DOMContentLoaded^et ~eventを発火する所 ]まで含める見込みが高い。 が、 ほとんどの(あるいはすべてかもしれない) `initial-only$v ~UAが外部~script( `async^a, `defer^a も含む)を読込んで `load^et ~eventも発火する場合、 これに拘束しても,作者にとっては有用になるとは見えない。 一方で,[ 外部~scriptが読込まれ, `load^et ~eventが発火される所 ]まで要求すると、 Opera mini の様な,[ 概して走らすが,制限時間や他の経験則に基づいて走らせないこともある ]ような~UAを除外することになる。 [`503$issue] ◎ Should there be an explicit minimum threshold to meet before a UA is allowed to claim initial-only? Having one would mean authors would know what they can depend on, and could tailor their scripts accordingly. On the other hand, pinpointing that threshold is difficult: if it is set too low, the scripting facilities that authors can depend on may be to constrained to be practical, even though actual UAs may potentially all support significantly more. But trying to set it higher may cause us to exclude UAs that do support scripting at loading time, but restrict it in some cases based on complex heuristics. For instance, conservative definitions likely include at least running all inline scripts and firing the DOMContentLoaded event. But it does not seem useful for authors to constrain themselves to this if most (or maybe all) initial-only UAs also load external scripts (including async and defer) and fire the load event. On the other hand, requiring external scripts to be loaded and the load event to be fired could exclude UAs like Opera mini, which typically do run them, but may decide not to based on timeouts and other heuristics. [Issue #503]
- `none@v
- 次を指示する ⇒ この文書に対しては,~UAは~scriptを走らせない。 これには[ ~script用~言語を~supportしない場合や, ~supportしていても現在の文書に対しては作動中でない場合 ]も含まれる。 ◎ Indicates that the user agent will not run scripts for this document; either it doesn’t support a scripting language, or the support isn’t active for the current document.
一部の~UAは、 ~scriptごと, あるいは~domainごとに,~scriptingの~supportを切る能を備えている — 文書ごとに,一部の~scriptは許容しつつ, すべてを走らすことはないような。 媒体~特能 `scripting$d は、 その種の~scriptを走らすのも許容されるかどうかまで検出するほど木目細かではない。 そのような局面では、 媒体~特能 `scripting$d の`実~値$は, 文書と同じ~domainを生成元とする~scriptを走らすことが許容されて[ いるならば `enabled$v または `initial-only$v / いないならば `none$v ]になるべきである。 ◎ Some user agents have the ability to turn off scripting support on a per script basis or per domain basis, allowing some, but not all, scripts to run in a particular document. The scripting media feature does not allow fine grained detection of which script is allowed to run. In this scenario, the value of the scripting media feature should be enabled or initial-only if scripts originating on the same domain as the document are allowed to run, and none otherwise.
注記: この媒体~特能は、 どの~scriptを走らすことが許容されているかを木目細かく検出できるよう, ~CSSの将来~levelにて拡張され得る。 ◎ Note: A future level of CSS may extend this media feature to allow fine-grained detection of which script is allowed to run.
10. ~custom媒体~query
【この節は、~level 4 に対する追加。】
媒体~queryを利用する文書を設計する際には、 複数の場所で同じ媒体~queryが利用され得る — 複数個の `import$at 文を選抜するためなど。 同じ媒体~queryを何度も繰返すのは、 編集-時の危険要素になる — 作者は、 何か変更する度に,それらすべてを全く同じに編集しなければならなくなる。 あるいは、 ~CSSの中で~~発見が困難な~bugに悩まされることになる。 ◎ When designing documents that use media queries, the same media query may be used in multiple places, such as to qualify multiple @import statements. Repeating the same media query multiple times is an editing hazard; an author making a change must edit every copy in the same way, or suffer from difficult-to-find bugs in their CSS.
これを~~改善するため、 この仕様は,`~custom媒体~query$を定義する手法を定義する。 それは単に,より長く複階的な媒体~queryを指す別名であり、 複数~箇所で利用される媒体~queryに,代わりに`~custom媒体~query$をあてがえるようにする。 これは,媒体~queryを記せる所なら どこでも利用でき、 媒体~queryを編集する際にも 1 行の~codeに触れるだけで済むようになる。 ◎ To help ameliorate this, this specification defines a method of defining custom media queries, which are simply-named aliases for longer and more complex media queries. In this way, a media query used in multiple places can instead be assigned to a custom media query, which can be used everywhere, and editing the media query requires touching only one line of code.
`~custom媒体~query@ は、 `custom-media$at 規則で定義される: ◎ A custom media query is defined with the @custom-media rule:
`custom-media@at = @custom-media `extension-name$t [ `media-query-list$t | `true$v | `false$v ];
しかる後、 `extension-name$t 【すなわち, `dashed-ident$t 】 を,媒体~queryを記せる所で利用できるようになる。 それは、 `真偽-文脈$の下で利用されなければナラナイ — 他の文脈(`素-形$/`範囲~形$)で利用された場合、 構文~errorになる。 `media-query-list$t が与えられた場合、 この`~custom媒体~query$は,それが表現する `media-query-list$t が[ 真に評価されるならば真, 偽に評価されるならば偽 ]に評価される。 [ `true@v / `false@v ]が与えられた場合、 当の`~custom媒体~query$は[ 真 / 偽 ]に評価される。 ◎ The <extension-name> can then be used in a media feature. It must be used in a boolean context; using them in a normal or range context is a syntax error. If a <media-query-list> is given, the custom media query evaluates to true if the <media-query-list> it represents evaluates to true, and false otherwise. If true or false is given, the custom media query evaluates to true or false, respectively.
`~custom媒体~query$は、 論理的に評価される — ~textな代用として扱われることなく。 一例として、 次の~code片は…: ◎ The custom media query is evaluated logically, not treated as a textual substitution. Take the following code snippet for instance:
/*
`--modern^css は[
色, ~hover
]どちらかは~supportする装置を~targetにする:
◎
--modern targets modern devices that support color or hover
*/
@custom-media --modern (color), (hover);
@media (--modern) and (width > 1024px) {
.a { color: green; }
}
…は、 次と等価になる: ◎ It is equivalent to:
@media ((color) or (hover)) and (width > 1024px) { .a { color: green; } }
それを,次が意味されたかのように処理することは、 不正である: ◎ Processing it as if it meant the following would be incorrect:
@media (color), (hover) and (width > 1024px) { .a { color: green; } }
`custom-media$at 規則は、 他の`~custom媒体~query$も参照rできるが,~loopは禁止される — `~custom媒体~query$は、 それを直接的/間接的に参照rしている別の`~custom媒体~query$を通して定義されてはナラナイ。 そのような、 循環依存を伴う`~custom媒体~query$を定義しようと試みられた場合、 その~loop内のすべての`~custom媒体~query$の定義を失敗させる【すなわち、~UAは,それらを無視する】モノトスル。 ◎ A @custom-media rule can refer to other custom media queries. However, loops are forbidden, and a custom media query must not be defined in terms of itself or of another custom media query that directly or indirectly refers to it. Any such attempt of defining a custom media query with a circular dependency must cause all the custom media queries in the loop to fail to be defined.
複数個の `custom-media$at 規則が同じ `extension-name$t を宣言している場合、 最後のものを除くすべては,無視される。 ◎ If multiple @custom-media rules declare the same <extension-name>, the truth value is based on the last one alone, ignoring all previous declarations of the same <extension-name>.
注記: ~error取扱いの目的においては、 未定義な`媒体~特能$は,偽に評価される`媒体~特能$から異なる。 詳細は `§ ~errorの取扱い@#error-handling$ を見よ。 ◎ Note: For error handling purposes, an undefined media feature is different from a media feature that evaluates to false. See Media Queries 4 § 3.2 Error Handling for details.
例えば,ある~responsive~siteが特定0の場合分けを何箇所かに利用する場合、 手頃な名前で代用aできる: ◎ For example, if a responsive site uses a particular breakpoint in several places, it can alias that with a reasonable name:
@custom-media --narrow-window (max-width: 30em); @media (--narrow-window) { /* 幅狭な~UIwindow~style ◎ narrow window styles */ } @media (--narrow-window) and (script) { /* ~scriptが許容されるときのための特別な~style ◎ special styles for when script is allowed */ } /* etc */
10.1. ~scriptに基づく~custom媒体~query
~JS用に,名前( `extension-name$t )から値への対応付けを定義する。 値は `MediaQueryList$I ~objまたは真偽値をとり得る — この場合、 名前は上と同じに扱われる。 あるいは、 数や文字列もとることができる — その場合、 通常の媒体~queryと~~同じに扱われ,[ 【!normal】`素-文脈$/`範囲~文脈$ ]の構文でも次の様に利用できる: ◎ Define a map of names to values for JS. Values can be either a MediaQueryList object or a boolean, in which case it’s treated identically to the above, or can be a number or a string, in which case it’s treated like a normal MQ, and can use the normal or range context syntax. Like:
<script> CSS.customMedia.set('--foo', 5); </script> <style> @media (_foo: 5) { ... } @media (_foo < 10) { ... } </style>
11. 利用者-選好に関する媒体~特能
【この節は、~level 4 に対する追加。】
11.1. ~page上の~~動きを抑えるよう欲されていることの検出-法: `prefers-reduced-motion^d 特能
◎述 `prefers-reduced-motion@d ◎用 `media$at ◎値 `no-preference$v | `reduce$v ◎型 `離散$ ◎表終`prefers-reduced-motion$d 媒体~特能は、 次を検出するために利用される ⇒ 利用者は、 本質的でない動きの量を最小限にするよう~systemに要請しているかどうか ◎ The prefers-reduced-motion media feature is used to detect if the user has requested the system minimize the amount of non-essential motion it uses.
- `no-preference@v
- 次を指示する ⇒ ~systemは、 利用者の選好を知らない。 ◎ Indicates that the user has made no preference known to the system.\
- この~keywordは、 この媒体~特能における`ゼロ値$である。 ◎ This keyword value evaluates as false in the boolean context.
- `reduce@v
- 次を指示する ⇒ 利用者は、 次のようにされた~UIを選好することを~systemに通知した ⇒ 動きに基づく~animationのうち,次に該当するものは、 除去するか置換する ⇒# 前庭動き過敏性( `vestibular motion sensitivity^en )を抱える者に不快感を誘発する/ 注意欠陥( `attention deficit^en )を抱える者にとって気が散る ◎ Indicates that user has notified the system that they prefer an interface that removes or replaces the types of motion-based animation that either trigger discomfort for those with vestibular motion sensitivity, or distraction for those with attention deficits.
11.2. ~page上の透明度を抑制するよう欲されていることの検出-法: `prefers-reduced-transparency^d 特能
◎述 `prefers-reduced-transparency@d ◎用 `media$at ◎値 `no-preference$v | `reduce$v ◎型 `離散$ ◎表終`prefers-reduced-transparency$d 媒体~特能は、 次を検出するために利用される ⇒ 利用者は、 層の透明度を増す効果を最小限にするよう,~systemに要請しているかどうか ◎ The prefers-reduced-transparency media feature is used to detect if the user has requested the system minimize the amount of transparent or translucent layer effects it uses.
- `no-preference@v
- 次を指示する ⇒ ~systemは、 利用者の選好を知らない。 ◎ Indicates that the user has made no preference known to the system.\
- この~keywordは、 この媒体~特能における`ゼロ値$である。 ◎ This keyword value evaluates as false in the boolean context.
- `reduce@v
- 次を指示する ⇒ 利用者は、[ 層の透明度を増す効果を最小限にする~UIを選好する ]ことを~systemに通知した。 ◎ Indicates that user has notified the system that they prefer an interface that minimizes the amount of transparent or translucent layer effects.
これは周りの選好 — 例: ~pattern~fillや背景 — とどう相互作用するか? それらは透明度についてではないが,形状認識に干渉する。 ◎ How does this interact with preferences around e.g. pattern fills and backgrounds? They’re not about transparency, but they also interfere with shape recognition.
11.3. ~page上の要素の色~contrastの増減が欲されていることの検出-法: `prefers-contrast^d 特能
◎述 `prefers-contrast@d ◎用 `media$at ◎値 `no-preference$v | `less$v | `more$v | `custom$v ◎型 `離散$ ◎表終`prefers-contrast$d 媒体~特能は、[ 利用者は、 ~pageの~contrastを上げるか下げるよう要請しているかどうか ]を検出するために利用される。 例えば、[ 隣接する色の~contrast比を調整する/ ~borderを調整するなどにより,要素を目立ち度合いを変更する ]などにより。 ◎ The prefers-contrast media feature is used to detect if the user has requested more or less contrast in the page. This could be responded to, for example, by adjusting the contrast ratio between adjacent colors, or by changing how much elements stand out visually, such as by adjusting their borders.
- `no-preference@v
- 次を指示する ⇒ ~systemは、 利用者の選好を知らない。 ◎ Indicates that the user has made no preference known to the system.\
- この~keywordは、 この媒体~特能における`ゼロ値$である。 ◎ This keyword value evaluates as false in the boolean context.
- `less@v
- 次を指示する ⇒ 利用者は、 より低~contrastな~UIを選好することを~systemに通知した。 ◎ Indicates that user has notified the system that they prefer an interface that has a lower level of contrast.
- `more@v
- 次を指示する ⇒ 利用者は、 より高~contrastな~UIを選好することを~systemに通知した。 ◎ Indicates that user has notified the system that they prefer an interface that has a higher level of contrast.
- `custom@v
- 次を指示する ⇒ 利用者は、 特定の色からなる集合を利用するよう求めているが,その色~集合に含意される~contrastは[ `more$v, `less$v ]どちらにも合致しない。 ◎ Indicates that the user has indicated wanting a specific set of colors to be used, but the contrast implied by these particular colors is such that neither more nor less match.
- 注記: この値は、 `強制d色~mode$の利用者が選んだ~paletteは,特に高~contrastでも低~contrastでもないときに合致することになる。 `§ 強制d色~modeの検出-法@#forced-colors$( `forced-colors^d 特能)を見よ。 ◎ Note: This value will match for users of forced colors mode who have picked a palette that is neither particularly high nor low contrast. See § 11.4 Detecting Forced Colors Mode: the forced-colors feature.
- 例えば, ~rust(錆色)な背景~上に~cyanな~text を~~求めている利用者は、 特に[ 高~contrast/低~contrast ]の必要を — 少なくとも光度に関しては — 表出していないが,それは選好の欠如を表出するものでもない。 ◎ A user calling for cyan text over a rust background is not—at least in terms of luminosity—expressing a need for particularly high or low contrast, but this is not a lack of a preference either.
注記: 作者は、 `prefers-contrast$d 用の`~test値$に[ `more$v / `less$v ]いずれか適切な方を利用して,~contrastを[ 上げたい/下げたい ]とする特定の利用者-選好に応答できる。 ◎ Note: Authors can respond to specific user preferences for more or less contrast using prefers-contrast: more or prefers-contrast: less, as appropriate.
`~test値$を伴わない `@media (prefers-contrast) { … }^css 【その`媒体~条件$は、 `not (prefers-contrast: no-preference)^css と等価になる】 を利用して,高~contrast用の~styleを適用するのは、 不正であり,利用者に敵対的になる — 真逆を要請した者にも高~contrast用の~styleを課すことになるので。 ◎ Using an unqualified @media (prefers-contrast) { … } to apply high contrast styles is incorrect and user-hostile, as it would also impose high contrast styles to people who have requested the exact opposite.
しかしながら、[ 高~contrast, 低~contrast ]どちらの選好に対しても,視覚的な乱れや色の複階性を抑制するよう応答することも共通的にある。 その事例では、[ `more$v / `less$v ]を指定することなく `@media (prefers-contrast) { … }^css を利用して,[ 背景~画像を素な色に置換する/ 装飾的な~gradientを切る/ ~border画像や~box影を単純なベタな~borderに置換する ]などを行うことは適切になる。 `prefers-contrast$d の`実~値$が `custom$v のときでも — `more$v や `less$v と同じく — `真偽-文脈$においては `真^i に評価されるので、 そのような単純~化は,`強制d色~mode$の利用者が選んだ色による結果が特に[ 高~contrast/低~contrast ]にならないときでも利用者に便益があり,望ましいふるまいになる — `強制d色~mode$により施行される抑制された~paletteは、 ~pageに対し,何らかの視覚的な単純~化を~~求めているので。 ◎ However, it is also common to reduce visual clutter and color complexity in response to both high and low contrast preferences. In that case, it is appropriate to use @media (prefers-contrast) { … } without specifying more or less, to do things like replacing background images with plain colors, turning off decorative gradients, or replacing border images or box shadows with simple solid borders. As prefers-contrast: custom—like prefers-contrast: more or prefers-contrast: less—evaluates to true in a boolean context, such simplifications would also benefit users of forced colors mode, even when their colors of choice do not result in a particularly high or low contrast. This is desirable, as the reduced palette enforced by forced colors mode calls for some visual simplification of the page.
~contrastを[ 上げる/下げる ]選好は、 様々な状況から発生し得る — 例えば: ◎ Preference for more or less contrast may arise from a variety of different situations. Here are some examples:
- 多くの利用者は、 背景との~contrast差が小さい~textを読むときに困難さを~~覚え, ~contrastを上げることを選好するであろう。 ◎ Many users have difficulty reading text that has a small difference in contrast to the text background and would prefer a larger contrast.
- 片頭痛を患う者は、 ~pageの~contrastが強いとき視覚的に苦痛を~~覚えることもあり, 低~contrastを選好することになろう。 ◎ People suffering from migraine may find strongly contrasting pages to be visually painful and would prefer a low contrast.
- 失読症を~~抱える一部の者は、 ~contrastが高い~textは,読むのが難しくなるほどに,字が — 裏から発する光が明る過ぎるかのように — 眩しく, あるいは煌くように感じる結果、 低~contrastな方が快適であると見出すこともある。 ◎ Some people with dyslexia find high contrast text hard to read, as they feel that the letters shine / sparkle as if backlit by too bright a light, and find low contrast to be more comfortable.
- 利用者が もっと[ 高い/低い ]~contrastを選好するよう至らすものには、 環境~上の要因もある。 `§ 利用者-選好の自動的な取扱い@#auto-pref$も見よ。 ◎ Environmental factors may also lead a user to prefer more or less contrast. See also § 11.7 Automatic handling of User Preferences.
この~listは、 もっと精緻化され, 拡げられるべきである。 ◎ This list should be refined and expanded.
11.4. 強制d色~modeの検出-法: `forced-colors^d 特能
◎述 `forced-colors@d ◎用 `media$at ◎値 `none$v | `active$v ◎型 `離散$ ◎表終- `active@v
- `強制d色~mode$が作動中であることを指示する。 ~UAは、 ~pageに対し利用者が選んだ制限付き色~paletteを施行する。 ~UAは、 当の色~paletteを,`~system色$( `system-color$t ~keyword)を通して作者に供することになる。 詳細は、 `CSS-COLOR-ADJUST-1$r `§ 強制d色~palette@~CSSCOLORADJUST#forced$ を見よ。 ◎ Indicates that forced colors mode is active: the user agent enforces a user-chosen limited color palette on the page, The UA will provide the color palette to authors through the CSS system color keywords. See CSS Color Adjustment §3 Forced Color Palettes for details.
- これは、 ~contrastを上げる選好を指示する`とは限らない^em。 利用者の選好に合致するよう強制的に色が調整されていても、 その選好は,[ ~contrastを[ 下げる/上げる ], このどちらにも該当しない決め事に基づく何か ]のどれもあり得る。 ◎ This does not necessarily indicate a preference for more contrast. The colors have been forcibly adjusted to match the preference of the user, but that preference can be for less or more contrast, or some other arrangement that is neither particularly low or high contrast.
-
加えて、 ~UAは, `強制d色~mode$が作動中【!In addition to forced-colors: active】なときは、 利用者が選んだ強制d色~paletteに応じて: ◎ ↓
- `prefers-contrast$d の`実~値$は、 次に与える値をとるようにするモノトスル ⇒# 当の~paletteは特に高~contrastであることを決定できるならば `more$v1 / 当の~paletteは特に低~contrastであることを決定できるならば `less$v1 / 他の場合は `custom$v1 ◎ In addition to forced-colors: active, the user agent must also match one of prefers-contrast: more or prefers-contrast: less if it can determine that the forced color palette chosen by the user has a particularly high or low contrast, and must make prefers-contrast: custom match otherwise.
- 類似に,当の~paletteが `prefers-color-scheme$d が述べる色~schemeのどれか 1 つに収まるならば ⇒ `prefers-color-scheme^d の`実~値$は、 対応する値【 `light$v1 / `dark$v1 】をとるようにするモノトスル。 ◎ Similarly, if the forced color palette chosen by the user fits within one of the color schemes described by prefers-color-scheme, the corresponding value must also match.
- `none@v
- `強制d色~mode$は作動中でない。 ◎ Forced colors mode is not active.
`強制d色~mode$が作動中なとき,作者にとって可用になる色は、 `~system色$に限られる。 ~UAは,この制限付き~paletteを自動的に施行することになるが、 媒体~特能 `forced-colors$d を利用すれば、 作者は そのことを検出でき,これらの色を適切な所で異なる仕方で利用することを選べる。 ◎ When forced colors mode is active, the only colors that are available to the author are system colors. The user agent will enforce this limited palette automatically, but the author may choose a different way of using these colors, using the forced-colors media feature to detect when it is appropriate to do so.
11.5. 明な/暗な色~schemeが欲されていることの検出-法: `prefers-color-scheme^d 特能
◎述 `prefers-color-scheme@d ◎用 `media$at ◎値 `light$v | `dark$v ◎型 `離散$ ◎表終`prefers-color-scheme$d 媒体~特能は、 次を反映する ⇒ 利用者は、[ 明な/暗な ]色~themeを~pageに利用するよう欲しているかどうか ◎ The prefers-color-scheme media feature reflects the user’s desire that the page use a light or dark color theme.
- `light@v
-
次のいずれかを指示する:
- 利用者は、 ~pageに対し,明な~theme(明な背景に暗な~text)の選好を表出した。
- 利用者は、 まだ選好を能動的に表出していない (したがって, “~webにおける既定” を成す明な~themeを受取るべきである)。
- `dark@v
- 次を指示する ⇒ 利用者は、 ~pageに対し,暗な~theme(暗な背景に明な~text)の選好を表出した。 ◎ Indicates that user has expressed the preference for a page that has a dark theme (light text on dark background).
注記: この特能~用の値は、 将来に拡げられるかもしれない( 明な色~scheme用に,もっと能動的な選好/ “`sepia^en” の様な 他の型の色~schemeに対する選好を表出するために)。 そのようなわけで,この媒体~特能は、[ `(prefers-color-scheme: dark)^css と `(not (prefers-color-scheme: dark))^css ]のように否定と組みで利用するのが,将来にも最も~~安全な仕方になる — そうすれば、 新たな値は【すなわち,`実~値$が新たな値をとるようになった場合でも】,どちらかの~style付け~blockで捉えられることが確保されるので。 ◎ Note: The values for this feature might be expanded in the future (to express a more active preference for light color schemes, or preferences for other types of color schemes like "sepia"). As such, the most future-friendly way to use this media feature is by negation such as (prefers-color-scheme: dark) and (not (prefers-color-scheme: dark)), which ensures that new values fall into at least one of the styling blocks.
利用者が選好を表出する手法は、 【環境に応じて】変わり得る — ~OSから公開される~system~~全般~設定や,~UAが制御する設定など。 ◎ The method by which the user expresses their preference can vary. It might be a system-wide setting exposed by the Operating System, or a setting controlled by the user agent.
注記: 利用者-選好は媒体に応じても変わり得る。 例えば利用者は、 ~screenが眩しいときは暗な~themeを選好し,印刷~時には明な~themeを選好することもあろう (~inkを節約するため/ べた~~塗り背景を~~白い字形で打ち抜くより~~白い紙に~textをべた~~塗りする方が良く印刷できるため)。 ~UAには、 そのような変動を考慮に入れることが期待される — 文脈から選好を取り出すより, `prefers-color-scheme$d が媒体に適切な選好を反映するよう。 ◎ Note: User preferences can also vary by medium. For example, a user may prefer dark themes on a glowing screen, but light themes when printing (to save ink and/or because inked text on blank paper prints better than blank letterforms knocked out of an inked background). UAs are expected to take such variances into consideration so that prefers-color-scheme reflects preferences appropriate to the medium rather than preferences taken out of context.
【この媒体~特能に反映される】`選好される色~scheme$を[ 他の文書に埋込まれた~SVG文書のうち, `~secure~animate化~mode$を利用しているもの ]において評価する場合には、[ それを埋込んでいる~nodeにおける`使用~色~scheme$の値 ]を反映するモノトスル。 ◎ If evaluated in an embedded SVG document using the "Secure Animated" embedding mode, the preferred color scheme must reflect the value of the used color scheme on the embedding node in the embedding document.
なぜこれを行うのか? ◎ Why do this?
最も外縁な文書は, 利用者の選好を直に取得する必要がある一方で、 埋込まれた文書~用には, それを埋込んでいる文脈の周囲の内容に合致するよう, 当の文脈の周囲の色~schemeを利用する方が有用になる。 ◎ While the outermost document needs to get the user’s preference directly, it’s more useful for an embedded document to use the color scheme of its surrounding embedding context, so it matches the surrounding content.
しかしながら、 これは,埋込んでいる文書から埋込まれた文書への通信を可能化するので、 現時点では,`~secure~animate化~mode$を利用している~SVGに制約される — それは,[ 外部~資源を読込む/~scriptを走らす ]ことはないので、 そこでの色~schemeに対する応答は,外界からは観測し得ない。 ◎ However, this enables communication from the embedding document to the embedded document, so it’s currently restricted to SVG’s using the "Secure Animated" mode, which can’t load external resources or run script, and thus can’t respond to the color scheme in any way observable to the outside world.
【 より制約される`~secure静的~mode$が言及されてないのは何故? 】
`iframe^e 用にも類似なことを行うか否か,どの条件の下で行うかは、 `7213$issue 【および `7493$issue】にて論じられている。 ◎ Whether or not to do similar for iframes, and under what conditions, is being discussed in Issue 7213.
注記: この特能は、 以前は — 他の `prefers-*^d 特能の様に — 作者【利用者?】は選好を能動的に表出していないことを指示する `no-preference^v 値があった。 しかしながら、 各~UAは, “既定の” 挙動を `light$v 選好として表出することに収束したので、 `no-preference^v には決して合致しない。 ◎ This feature, like the other prefers-* features, previously had a no-preference value to indicate an author not expressing an active preference. However, user agents converged on expressing the "default" behavior as a light preference, and never matching no-preference.
~UAは,将来に “選好なし” と “明な表示を本当に求める” との相違を公開したいと望むようになったなら、 それについて論じるため,~CSS~WGに連絡されたし。 ◎ If a future user agent wishes to expose a difference between "no preference" and "really wants a light display", please contact the CSSWG to discuss this.
11.6. ~pageが読込む~data量uを抑制するよう欲されていることの検出-法: `prefers-reduced-data^d 特能
この特能は、 ~data量uが制限された低所得者層へ偏ることに伴い,欲されない指紋収集の~sourceになり得る。 [`10076$issue] ◎ This feature may be an undesired source of fingerprinting, with a bias towards low income with limited data. [Issue #10076]
◎述 `prefers-reduced-data@d ◎用 `media$at ◎値 `no-preference$v | `reduce$v ◎型 `離散$ ◎表終媒体~特能 `prefers-reduced-data$d は、 次を検出するために利用される ⇒ 利用者は、[ 具現化される~page用に,より少ない~dataを利用する代替-内容を~serveする ]よう選好しているかどうか ◎ The prefers-reduced-data media feature is used to detect if the user has a preference for being served alternate content that uses less data for the page to be rendered.
- `no-preference@v
- 次を指示する ⇒ ~systemは、 利用者の選好を知らない。 ◎ Indicates that the user has made no preference known to the system.\
- この~keywordは、 この媒体~特能における`ゼロ値$である。 ◎ This keyword value evaluates as false in the boolean context.
- `reduce@v
- 次を指示する ⇒ 利用者は、 軽量な代替-内容の選好を表出した。 ◎ Indicates that user has expressed the preference for lightweight alternate content.
利用者が選好を表出する手法は、 【環境に応じて】変わり得る — ~OSが公開する~system~~全般~設定や,~UAが制御する設定など。 ~UAは、 `Save-Data$h `~client~hint~header$を設定するときに利用するものと同じ[ 利用者/~system ]選好に基づいて,これを設定することを考慮してもヨイ。 ◎ The method by which the user expresses their preference can vary. It might be a system-wide setting exposed by the Operating System, or a setting controlled by the user agent. User agents may consider setting this based on the same user or system preference as they use to set the Save-Data HTTP request header.
注記: ~UAには、 この値に対する~toggleを取扱うときに — ~page読込nの[ 後/間 ]どちらで~toggleされようが — 利用者~本位な自前の裁量を利用することが奨励される。 その首な目標には、 不必要な~dataを~downloadしないことが挙げられよう。 ある~pageが,すでに高~品質な~assetを読込んだが、 利用者は自身の選好を `reduce$v へ変更した場合を考える — たぶん,当の~pageは、 文書をすぐには更新しない代わりに, 利用者が~pageの~reloadを明示的に呼出すまで待機することもできる。 あるいは、 ある~pageがすべてを~downloadするのに長い時間かかっていて, 利用者が自身の選好を `reduce$v へ変更した場合を考える — これは、[ 即時に より小さな~assetを~downloadするよう切替えて,利用者の帯域幅を節約する ]ための良好な~~機会にもなろう。 ~UAは、 これらの様な状況~用に自身にとって適切な~logicを実装してかまわないが, そのような状況が存在することを自覚するべきである。 ◎ Note: User agents are encouraged to use their own user centered discretion when handling a toggle of this value, whether it’s toggled post page load or during page load. A primary goal could be to not download unnecessary data. Consider, if a page is already loaded with high quality assets and the user changes their preference to reduced, the page could perhaps not update the document right away, instead wait for an explicit page reload invocation from the user. Consider also, if a page is taking a long time to download and a user changes their preference to reduced, this could be a nice point to save the user’s bandwidth and immediately switch to downloading smaller assets. User agents are free to implement logic as they see appropriate for situations like these, and also ought to be aware the situations exist.
例えば,~siteは、[ 利用者が~data節約~modeを選好した場合 ]には,より小さな画像を~serveすることで尊守することもできる。 ◎ For example, a site could honour the preference of a user who has turned on data-saving mode by serving a smaller image.
.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は、[ 装置, 環境, 等々 ]についての知識に基づいて 利用者の選好を自動的に推定してもヨイ。 そのような事例では、 自動的に決定される選好を[ ~opt-outする/上書きする ]仕方も利用者~向けに提供することが推奨される。 ◎ User agents may have explicit settings allowing users to indicate their preferences or may make the determination based on settings in the underlying operating system. User agents may also automatically infer the preferences of the user based on knowledge about the device, the environment, etc. In such case, it is recommended that they also offer a way for users to opt out of or override the automatically determined preferences.
色~scheme用の選好( `prefers-color-scheme$d )を `light$v1 か `dark$v1 か明示的に選ぶことを利用者に許容することに加えて、 ~UAは,それを現在の時刻に基づいて — 日没から夜明けまでは `dark^v 用の選好を表出するように — 自動的に決定する~modeを備えることもできる。 ◎ In addition to allowing users to explicitly choose between a preference for a light or dark color scheme, a user agent could have a mode where the determination is automatically made based on the current time, expressing a preference for dark between sunset and dawn.
利用される~displayの種別によっては、 環境光~levelが変化すると,読取るのが困難か不快になるまでになり得る。 ◎ Depending on the type of display used, changes in the ambient light level may make the reading experience difficult or uncomfortable.
一例として,液晶~displayは、 明るく照らされた環境においては,読取るのが難しくなるまで漂白され得る。 装置が そのような~screenと環境光~sensorを備える場合、 ~screenを読取るのが困難になる条件を検出したときには, `prefers-contrast$d の`実~値$を自動的に `more$v1 に切替えることもできる。 当の装置が~e-ink~displayであるなら、 明るい日差しでも読めるので,~UAは同じ調整を為さないことになる。 ◎ For instance, liquid crystal displays can be washed out and very hard to read in brightly lit environments. A device with such a screen and with an ambient light sensor could automatically switch prefers-contrast to more when it detects conditions that would make the screen difficult to read. A user agent on a device with an e-ink display would not make the same adjustment, as such displays remain readable in bright daylight.
反対の状況においては、[ 光を発する~screen(~LCD, ~OLED, 等々)と環境光~sensor ]を備える装置が稼働していて,[ 過度な~contrastや明るさは,読手にとって眩し過ぎるか不快になる ]ほど薄暗い環境で利用されるときは、 ~UAは[ `prefers-contrast$d は `less$v1, `prefers-color-scheme$d は `dark$v1 ]に自動的に切替えることもできる。 ◎ In the opposite situation, user agents running of device with a light-emitting screen (LCD, OLED, etc.) and an ambient light sensor could automatically switch prefers-contrast to less and prefers-color-scheme to dark when used in a dim environment where excessive contrast and brightness would be distracting or uncomfortable to the reader.
~UAは、 利用-中にある~network接続が許容する~data量uは無制限か従量制かに応じて, `prefers-reduced-data$d の`実~値$を自動的に[ `no-preference$v / `reduce$v ](同順)に切替えることもできる。 ◎ A user agent could automatically switch between prefers-reduced-data: no-preference and reduce depending on whether the network connection in use allows for unlimited data or is on a metered plan.
12. 利用者~選好に対する~scriptによる制御
~web~site作者が[ 利用者の~system選好を尊重する一方で,それらの選好を上書きすることも許容される ]よう求めることは,共通的にある。 それを助けるため、 この仕様は,作者~用に[ `PreferenceManager$I ~interfaceを利用して `§ 利用者-選好に関する媒体~特能@#mf-user-preferences$ を上書きする ]ための仕方を定義する。 ◎ It is common for website authors to want to respect the user’s system preferences while also allowing those preferences to be overridden. To help with this, this specification defines a way for authors to override the § 11 User Preference Media Features using the PreferenceManager interface.
この上書きは、 当の選好を[ これらの選好により影響される様々な~platform特能 ]と統合することを許容する。 ◎ This override allows the preference to integrate with various platform features that are affected by these preferences.
12.1. `Navigator^I ~interfaceに対する拡張
[`Exposed$=Window, `SecureContext$] partial interface `Navigator$I { [`SameObject$] readonly attribute `PreferenceManager$I `preferences$m; };
12.1.1. `preferences^m 属性
`preferences@m 取得子は、 常に同じ `PreferenceManager$I ~objを返す。 ◎ When getting the preferences attribute always return the same instance of the PreferenceManager object.
12.1.2. `PreferenceManager^I ~interface
[`Exposed$=Window, `SecureContext$] interface `PreferenceManager@I { readonly attribute `PreferenceObject$I `colorScheme$m; readonly attribute `PreferenceObject$I `contrast$m; readonly attribute `PreferenceObject$I `reducedMotion$m; readonly attribute `PreferenceObject$I `reducedTransparency$m; readonly attribute `PreferenceObject$I `reducedData$m; };
12.1.3. `colorScheme^m 属性
`colorScheme@m 属性が返す `PreferenceObject$I ~objは、 ~site上の色~schemeに関する利用者の選好を上書きするために利用される。 これは、 `prefers-color-scheme$d 媒体~特能を~modelにする。 ◎ The colorScheme attribute is a PreferenceObject used to override the user’s preference for the color scheme of the site. This is modeled after the § 11.5 Detecting the desire for light or dark color schemes: the prefers-color-scheme feature.
`colorScheme@gVV ときは ⇒ ~RET « "`light$v1", "`dark$v1" » ◎ The get valid values for colorScheme algorithm, when invoked, must run these steps: • Let validValues be a new empty sequence. • Add light to validValues. • Add dark to validValues. • Return validValues.
この選好~用に ある上書きが設定された場合、 ~UAは,[ 以下に挙げるものに,この上書きを利用する ]モノトスル: ◎ If an override is set for this preference:
- `生成元$docが同じ文書たちに適用される すべての~stylesheet — ~UA~stylesheetも含む — 内の `prefers-color-scheme$d 媒体~特能。 ◎ The user agent MUST use this override for the § 11.5 Detecting the desire for light or dark color schemes: the prefers-color-scheme feature in all stylesheets applied to an origin including the UA style sheet.
- `matchMedia()$m を介して~queryされたとき。 `CSSOM-VIEW-1$r ◎ The user agent MUST also use this override when queried via `matchMedia()` from CSSOM View § 4 Extensions to the Window Interface.
- `使用~色~scheme$を計算するとき。 ◎ The user agent MUST also use this override when calculating the used color scheme.
- `Sec-CH-Prefers-Color-Scheme$h `~client~hint~header$を送信するとき。 `USER-PREFERENCE-MEDIA-FEATURES-HEADERS$r ◎ The user agent MUST also use this override when sending User Preference Media Features Client Hints Headers § 2.5 Sec-CH-Prefers-Color-Scheme.
- `prefers-color-scheme$d 媒体~特能により,通常は影響される~UA特能。 ◎ The user agent MUST also use this override for any UA features that are normally affected by § 11.5 Detecting the desire for light or dark color schemes: the prefers-color-scheme feature.
12.1.4. `contrast^m 属性
`contrast@m 属性が返す `PreferenceObject$I ~objは、[ ~site上の~contrastに関する利用者の選好 ]を上書きするために利用される。 これは、 `prefers-contrast$d 媒体~特能を~modelにする。 ◎ The contrast attribute is a PreferenceObject used to override the user’s preference for the contrast of the site. This is modeled after the § 11.3 Detecting the desire for increased or decreased color contrast from elements on the page: the prefers-contrast feature.
`contrast@gVV ときは ⇒ ~RET « "`more$v1", "`less$v1", "`no-preference$v1" » ◎ The get valid values for contrast algorithm, when invoked, must run these steps: • Let validValues be a new empty sequence. • Add more to validValues. • Add less to validValues. • Add no-preference to validValues. • Return validValues.
この選好~用に ある上書きが設定された場合、 ~UAは,[ 以下に挙げるものに,この上書きを利用する ]モノトスル: ◎ If an override is set for this preference:
- `生成元$docが同じ文書たちに適用される すべての~stylesheet — ~UA~stylesheetも含む — 内の `prefers-contrast$d 媒体~特能。 ◎ The user agent MUST use this override for the § 11.3 Detecting the desire for increased or decreased color contrast from elements on the page: the prefers-contrast feature in all stylesheets applied to an origin including the UA style sheet.
- `matchMedia()$m を介して~queryされたとき。 `CSSOM-VIEW-1$r ◎ The user agent MUST also use this override when queried via `matchMedia()` from CSSOM View § 4 Extensions to the Window Interface.
- `Sec-CH-Prefers-Contrast$h `~client~hint~header$を送信するとき。 `USER-PREFERENCE-MEDIA-FEATURES-HEADERS$r ◎ The user agent MUST also use this override when sending User Preference Media Features Client Hints Headers § 2.3 Sec-CH-Prefers-Contrast.
- `prefers-contrast$d 媒体~特能により,通常は影響される~UA特能。 ◎ The user agent MUST also use this override for any UA features that are normally affected by § 11.3 Detecting the desire for increased or decreased color contrast from elements on the page: the prefers-contrast feature.
注記: 媒体~特能とは違って、 この選好には `custom$v1 は設定-`可能でない^em — これは、 `forced-colors$d 媒体~特能と緊密に関わるので。 ◎ Note: Unlike the media feature this preference is NOT able to be set to custom as this is tightly coupled to the § 11.4 Detecting Forced Colors Mode: the forced-colors feature.
12.1.5. `reducedMotion^m 属性
`reducedMotion@m 属性が返す `PreferenceObject$I ~objは、[ ~site上の動きを抑制することに関する利用者の選好 ]を上書きするために利用される。 これは、 `prefers-reduced-motion$d 媒体~特能を~modelにする。 ◎ The reducedMotion attribute is a PreferenceObject used to override the user’s preference for reduced motion on the site. This is modeled after the § 11.1 Detecting the desire for less motion on the page: the prefers-reduced-motion feature.
`reducedMotion@gVV ときは ⇒ ~RET « "`reduce$v1", "`no-preference$v1" » ◎ The get valid values for reducedMotion algorithm, when invoked, must run these steps: • Let validValues be a new empty sequence. • Add reduce to validValues. • Add no-preference to validValues. • Return validValues.
この選好~用に ある上書きが設定された場合、 ~UAは,[ 以下に挙げるものに,この上書きを利用する ]モノトスル: ◎ If an override is set for this preference:
- `生成元$docが同じ文書たちに適用される すべての~stylesheet — ~UA~stylesheetも含む — 内の `prefers-reduced-motion$d 媒体~特能。 ◎ The user agent MUST use this override for the § 11.1 Detecting the desire for less motion on the page: the prefers-reduced-motion feature in all stylesheets applied to an origin including the UA style sheet.
- `matchMedia()$m を介して~queryされたとき。 `CSSOM-VIEW-1$r ◎ The user agent MUST also use this override when queried via `matchMedia()` from CSSOM View § 4 Extensions to the Window Interface.
- `Sec-CH-Prefers-Reduced-Motion$h `~client~hint~header$を送信するとき。 `USER-PREFERENCE-MEDIA-FEATURES-HEADERS$r ◎ The user agent MUST also use this override when sending User Preference Media Features Client Hints Headers § 2.1 Sec-CH-Prefers-Reduced-Motion.
- `prefers-reduced-motion$d 媒体~特能により,通常は影響される~UA特能。 ◎ The user agent MUST also use this override for any UA features that are normally affected by § 11.1 Detecting the desire for less motion on the page: the prefers-reduced-motion feature.
注記: この選好により影響される~UA特能の例としては、[ 滑らかな~scroll法を不能化すること ]や[ `marquee@~HTMLobs#the-marquee-element$e 要素を静止すること ]も挙げれる。 ◎ Note: An example of a UA feature that is affected by this preference could be disabling smooth scrolling, or pausing marquee elements.
12.1.6. `reducedTransparency^m 属性
`reducedTransparency@m 属性が返す `PreferenceObject$I ~objは、[ ~site上の透明度を抑制することに関する利用者の選好 ]を上書きするために利用される。 これは、 `prefers-reduced-transparency$d 媒体~特能を~modelにする。 ◎ The reducedTransparency attribute is a PreferenceObject used to override the user’s preference for reduced transparency on the site. This is modeled after the § 11.2 Detecting the desire for reduced transparency on the page: the prefers-reduced-transparency feature.
`reducedTransparency@gVV ときは ⇒ ~RET « "`reduce$v1", "`no-preference$v1" » ◎ The get valid values for reducedTransparency algorithm, when invoked, must run these steps: • Let validValues be a new empty sequence. • Add reduce to validValues. • Add no-preference to validValues. • Return validValues.
この選好~用に ある上書きが設定された場合、 ~UAは,[ 以下に挙げるものに,この上書きを利用する ]モノトスル: ◎ If an override is set for this preference:
- `生成元$docが同じ文書たちに適用される すべての~stylesheet — ~UA~stylesheetも含む — 内の `prefers-reduced-transparency$d 媒体~特能。 ◎ The user agent MUST use this override for the § 11.2 Detecting the desire for reduced transparency on the page: the prefers-reduced-transparency feature in all stylesheets applied to an origin including the UA style sheet.
- `matchMedia()$m を介して~queryされたとき。 `CSSOM-VIEW-1$r ◎ The user agent MUST also use this override when queried via `matchMedia()` from CSSOM View § 4 Extensions to the Window Interface.
- `Sec-CH-Prefers-Reduced-Transparency$h `~client~hint~header$を送信するとき。 `USER-PREFERENCE-MEDIA-FEATURES-HEADERS$r ◎ The user agent MUST also use this override when sending User Preference Media Features Client Hints Headers § 2.2 Sec-CH-Prefers-Reduced-Transparency.
- `prefers-reduced-transparency$d 媒体~特能により,通常は影響される~UA特能。 ◎ The user agent MUST also use this override for any UA features that are normally affected by § 11.2 Detecting the desire for reduced transparency on the page: the prefers-reduced-transparency feature.
12.1.7. `reducedData^m 属性
`reducedData@m 属性が返す `PreferenceObject$I ~objは、[ ~site上の~data量uを抑制することに関する利用者の選好 ]を上書きするために利用される。 これは、 `prefers-reduced-data$d 媒体~特能を~modelにする。 ◎ 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 § 11.6 Detecting the desire for reduced data usage when loading a page: the prefers-reduced-data feature.
`reducedData@gVV ときは ⇒ ~RET « "`reduce$v1", "`no-preference$v1" » ◎ The get valid values for reducedData algorithm, when invoked, must run these steps: • Let validValues be a new empty sequence. • Add reduce to validValues. • Add no-preference to validValues. • Return validValues.
この選好~用に ある上書きが設定された場合、 ~UAは,[ 以下に挙げるものに,この上書きを利用する ]モノトスル: ◎ If an override is set for this preference:
- `生成元$docが同じ文書たちに適用される すべての~stylesheet — ~UA~stylesheetも含む — 内の `prefers-reduced-data$d 媒体~特能。 ◎ The user agent MUST use this override for the § 11.6 Detecting the desire for reduced data usage when loading a page: the prefers-reduced-data feature in all stylesheets applied to an origin including the UA style sheet.
- `matchMedia()$m を介して~queryされたとき。 `CSSOM-VIEW-1$r ◎ The user agent MUST also use this override when queried via `matchMedia()` from CSSOM View § 4 Extensions to the Window Interface.
- `Save-Data$h `~client~hint~header$を送信するとき。 ◎ The user agent MUST also use this override when sending Save Data API § 2.1.1 Save-Data Request Header Field.
- `saveData@https://wicg.github.io/savedata/#dfn-savedata$c 属性を計算するとき。 `SAVEDATA$r ◎ The user agent MUST also use this override when calculating the Save Data API § 2.1 saveData attribute.
- `prefers-reduced-data$d 媒体~特能により,通常は影響される~UA特能。 ◎ The user agent MUST also use this override for any UA features that are normally affected by § 11.6 Detecting the desire for reduced data usage when loading a page: the prefers-reduced-data feature.
12.1.8. `PreferenceObject^I ~interface
[`Exposed$=Window, `SecureContext$] interface `PreferenceObject@I : `EventTarget$I { readonly attribute `DOMString$? `override$m; readonly attribute `DOMString$ `value$m; readonly attribute `FrozenArray$<`DOMString$> `validValues$m; `undefined$ `clearOverride$m(); `Promise$<`undefined$> `requestOverride$m(`DOMString$? %value); attribute `EventHandler$I `onchange$m; };
各 `PreferenceObject$I は、 それを返した[ `PreferenceManager$I ~interfaceの属性 ]の`識別子$を その `名前@prF として内部的に保持する。
【 この用語は、 原文に現れる句 “`the preference object’s name^en( `PreferenceObject$I の名前)” を明確化するための,この訳による追加。 】
`override@m 取得子~手続きは: ◎ 12.1.8.1. override attribute ◎ The override attribute, when accessed, must run these steps:
- %選好 ~LET コレの`名前$prF ◎ Let preference be the preference object’s name.
- ~RET [ %選好 用の上書きは存在するならば その値 / ~ELSE_ ~NULL ] ◎ Let override be null. ◎ If an override for preference exists, set override to the value of that override. ◎ Return override.
`value@m 取得子~手続きは: ◎ 12.1.8.2. value attribute ◎ The value attribute, when accessed, must run these steps:
- %選好 ~LET コレの`名前$prF ◎ Let preference be the preference object’s name.
- ~RET [ %選好 用の上書きは存在するならば その値 / ~ELSE_ ~UAによる %選好 用の値 ] ◎ Let value be null. ◎ If an override for preference exists, set value to the value of that override. ◎ If value is null, set value to the UA value of the preference. ◎ Return value.
`validValues@m 取得子~手続きは: ◎ 12.1.8.3. validValues attribute ◎ The validValues attribute, when accessed, must run these steps:
- %選好 ~LET コレの`名前$prF ◎ Let preference be the preference object’s name.
- ~RET %選好 に応じて ⇒# "`colorScheme$m" ならば `colorScheme$gVV() / "`contrast$m" ならば `contrast$gVV() / "`reducedMotion$m" ならば `reducedMotion$gVV() / "`reducedTransparency$m" ならば `reducedTransparency$gVV() / "`reducedData$m" ならば `reducedData$gVV() ◎ Switch on preference: • "colorScheme" •• Return the result of get valid values for colorScheme. • "contrast" •• Return the result of get valid values for contrast. • "reducedMotion" •• Return the result of get valid values for reducedMotion. • "reducedTransparency" •• Return the result of get valid values for reducedTransparency. • "reducedData" •• Return the result of get valid values for reducedData.
`onchange@m 属性は、 【!重言:`onchange$m 】 `~event~handler~event型$ `change@et に対応する`~event~handler$用の`~event~handler~IDL属性$である。 ◎ 12.1.8.4. onchange event handler attribute ◎ The onchange attribute is an event handler IDL attribute for the onchange event handler, whose event handler event type is change.
~UAは、[ ある `PreferenceObject$I ~obj %選好~obj の状態が変化したことに自覚した ]ときは,次を走らすとする ⇒ `選好~obj更新-時の~手続き$( %選好~obj ) ◎ Whenever the user agent is aware that the state of a PreferenceObject instance value has changed, it runs the PreferenceObject update steps
`選好~obj更新-時の~手続き@ は、 所与の ( `PreferenceObject$I ~obj %選好~obj ) に対し: ◎ Whenever the user agent is aware that the state of a PreferenceObject instance value has changed, it runs the PreferenceObject update steps: • Let preference be the PreferenceObject object that value is associated with.
- %大域~obj ~LET %選好~obj【!コレ】 に`関連な大域~obj$ ◎ ↓
-
~IF[ %大域~obj は `Window$I ~objである ]: ◎ If this's relevant global object is a Window object, then:
- %文書 ~LET %大域~obj に`結付けられた文書$ ◎ Let document be preference’s relevant global object's associated Document.
- ~IF[ %文書 ~EQ ~NULL ]~OR[ %文書 は`全部的に作動中$でない ] ⇒ ~RET ◎ If document is null or document is not fully active, terminate this algorithm.
- `~eventを発火する$( %選好~obj, `change$et ) ◎ Fire an event named change at preference.
`requestOverride(value)@m ~method手続きは: ◎ 12.1.8.5. requestOverride() method ◎ The requestOverride(value) method, when invoked, must run these steps:
- %~promise ~LET `新たな~promise$ ◎ Let result be a new promise.
- %許容されるか ~LET 次を実行した結果 ⇒ 当の要請は許容されるかどうか裁定するための~UA定義な【真偽値を返す】~algo ◎ Let allowed be false. ◎ Set allowed to the result of executing a UA defined algorithm for deciding whether the request is allowed.
- ~IF[ %許容されるか ~EQ ~F ] ⇒ ~RET `却下される~promise$( `NotAllowedError$E 例外 ) ◎ If allowed is false, return a promise rejected with a "NotAllowedError" DOMException. ◎ ↓ Let value be the method’s argument.
- %~promise ~LET `新たな~promise$ ◎ Let result be a new promise.
-
~IF[ %value ~IN { ~NULL, 空~文字列 } ]: ◎ If value is null or the empty string:
- コレ上の `clearOverride$m ~method手続き() ◎ Run clearOverride.
- `~promiseを解決する$( %~promise ) ◎ Resolve and\
- ~RET %~promise ◎ return result.
- %現在の値 ~LET コレの `value$m【!%value】 ◎ Let currentValue be the preference object’s value.
- %妥当な値~群 ~LET ~NULL ◎ Let validValues be null.
- %妥当な値~群 ~SET %選好 に応じて ⇒# "`colorScheme$m" ならば `colorScheme$gVV() / "`contrast$m" ならば `contrast$gVV() / "`reducedMotion$m" ならば `reducedMotion$gVV() / "`reducedTransparency$m" ならば `reducedTransparency$gVV() / "`reducedData$m" ならば `reducedData$gVV() ◎ Switch on preference: • "colorScheme" •• Return the result of get valid values for colorScheme. • "contrast" •• Return the result of get valid values for contrast. • "reducedMotion" •• Return the result of get valid values for reducedMotion. • "reducedTransparency" •• Return the result of get valid values for reducedTransparency. • "reducedData" •• Return the result of get valid values for reducedData.
-
~IF[ %value ~NIN %妥当な値~群 ]: ◎ If value is not in validValues:
- `~promiseを却下する$( %~promise, `TypeError$E 例外 ) ◎ Reject result with a "TypeError" DOMException.
- ~RET %~promise ◎ Return result.
- %以前の上書き ~LET [ %選好 用の上書きは存在するならば その値 / ~ELSE_ ~NULL ] ◎ Let previousOverride be null. ◎ If an override for preference exists, set previousOverride to the value of that override.
- ~IF[ %value ~NEQ %以前の上書き ] ⇒ %選好 用の上書き ~SET %value ◎ If value is different from previousOverride: • Set the preference override for preference to value.
- ~IF[ %以前の上書き ~EQ ~NULL ]~AND[ %value ~EQ %現在の値 ] ⇒ `~eventを発火する$( コレ, `change$et ) ◎ If previousOverride is null, then: • If value is the same as currentValue, then: •• Fire an event named change at this.
- `~promiseを解決する$( %~promise ) ◎ Resolve and\
- ~RET %~promise ◎ return result.
この~algoは、[ 選好~用の上書きを設定することが正確に何を行うのか ]について,もっと詳細が必要である。 ◎ This algorithm needs more detail on what exactly setting the preference override does.
ここでは `TypeError^E は正しいのか? ◎ Is TypeError correct here?
注記: `change$et ~eventは,算出d値【何の?】が変化したときに発火されるが、 値は まだ変化してないときでも, 新たな上書きが設定されたときには発火される。 ◎ Note: The `change` event is fired when the computed value changes, but when a new override is set it is also fired if the value hasn’t changed.
`clearOverride()@m ~method手続きは: ◎ 12.1.8.6. clearOverride() method ◎ The clearOverride() method, when invoked, must run these steps:
- %選好 ~LET コレの`名前$prF ◎ Let preference be the preference object’s name.
- %上書き ~LET ~NULL ◎ Let override be null.
- ~IF[ %選好 用の上書きは存在する ] ⇒ %上書き ~SET その上書きの値 ◎ If an override for preference exists, set override to the value of that override.
- ~IF[ %上書き ~EQ ~NULL ] ⇒ ~RET ◎ If override is null, then return.
- %選好 用の上書きを~clearする ◎ Clear the override for preference.
- %新たな値 ~LET コレの `value$m【!%value】 ◎ Let newValue be the preference object’s value.
- ~IF[ %新たな値 ~EQ %上書き ] ⇒ 【何も記されていない。 ~RET ?】 ◎ If newValue is equal to override, then:
- `~eventを発火する$( コレ, `change$et ) ◎ Fire an event named change at this.
注記: `change$et ~eventは,算出d値【何の?】が変化したときに発火されるが、 値は まだ変化してないときでも, 上書きが~clearされたときには発火される。 ◎ Note: The `change` event is fired when the computed value changes, but when an override is cleared it is also fired if the value hasn’t changed.
非推奨にされた媒体~特能
以下の`媒体~特能$は 非推奨にされた。 それらの後方-互換性は保たれるが、 新たに記される~stylesheetには適切でない。 作者は、 それらを利用してはならない。 ~UAは、 それらを指定されたとおりに~supportするモノトスル。 ◎ The following media features are deprecated. They are kept for backward compatibility, but are not appropriate for newly written style sheets. Authors must not use them. User agents must support them as specified.
表示域(`~paged媒体$の場合は`~page~box$)の~sizeを~queryする場合は、 `媒体~特能$[ `width$d, `height$d, `aspect-ratio$d ]が利用されるべきである — [ `device-width$d, `device-height$d, `device-aspect-ratio$d ]ではなく — これらは、 ~layoutされている文書に可用な空間の大きさに関わらず,装置の物理的~sizeを参照rするので。 `device-*^d `媒体~特能$は、 携帯~機器かどうか検出するための代用1として利用されることもあるが、 作者は代わりに[ ~style付けを試みる装置の側面を より良く表現する`媒体~特能$ ]を利用するべきである。 ◎ To query for the size of the viewport (or the page box on page media), the width, height and aspect-ratio media features should be used, rather than device-width, device-height and device-aspect-ratio, which refer to the physical size of the device regardless of how much space is available for the document being laid out. The device-* media features are also sometimes used as a proxy to detect mobile devices. Instead, authors should use media features that better represent the aspect of the device that they are attempting to style against.
`device-width^d
◎述 `device-width@d ◎用 `media$at ◎値 `length$t ◎型 `範囲$ ◎表終媒体~特能 `device-width$d は、 出力~装置の描画面の横幅を述べる。 この特能の`実~値$は、 `連続的~媒体$用には,`~Webに公開される~screen区画$の横幅になり、 `~paged媒体$用には,~page~sheet【`用紙$】~sizeの横幅になる。 ◎ 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$d に対する`負な範囲は偽になる$。 ◎ device-width is false in the negative range.
@media (device-width < 800px) { … }
上の例の~stylesheetは、 長さ `800px^v より小さい~screenにのみ適用されることになる。 `§ 単位$にて述べたように、 `px$u 単位は,物理的~画素ではなく論理的なものによる。 ◎ In the example above, the style sheet will apply only to screens less than 800px in length. The px unit is of the logical kind, as described in the Units section.
注記: 縦置き/横置きなど,複数の方位で利用できる装置に対しては、 媒体~特能 `device-*^d は,現在の方位も反映する。 ◎ Note: If a device can be used in multiple orientations, such as portrait and landscape, the device-* media features reflect the current orientation.
`device-height^d
◎述 `device-height@d ◎用 `media$at ◎値 `length$t ◎型 `範囲$ ◎表終媒体~特能 `device-height$d は、 出力~装置の描画面の縦幅を述べる。 この特能の`実~値$は、 `連続的~媒体$用には,`~Webに公開される~screen区画$の縦幅になり、 `~paged媒体$用には,~page~sheet【`用紙$】~sizeの縦幅になる。 ◎ 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$d に対する`負な範囲は偽になる$。 ◎ device-height is false in the negative range.
<link rel="stylesheet" media="(device-height > 600px)" />
上の例では、 ~stylesheetは,縦方向に 600 画素より高い~screenのみに適用されることになる。 `px$u 単位の定義は~CSSの他の部分と同じであることに注意。 ◎ In the example above, the style sheet will apply only to screens taller than 600 vertical pixels. Note that the definition of the px unit is the same as in other parts of CSS.
`device-aspect-ratio^d
◎述 `device-aspect-ratio@d ◎用 `media$at ◎値 `ratio$t ◎型 `範囲$ ◎表終媒体~特能 `device-aspect-ratio$d の`実~値$は、 媒体~特能 `device-width$d の`実~値$から媒体~特能 `device-height$d の`実~値$への比率として定義される。 ◎ 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.
例えば、[ 画素が正方形で,横 × 縦が 1280 × 720 画素 ]の~screen装置(いわゆる “16:9” )に対しては、 次に挙げるどの媒体~queryも合致することになる: ◎ For example, if a screen device with square pixels has 1280 horizontal pixels and 720 vertical pixels (commonly referred to as “16:9”), the following media queries will all match the device:
@media (device-aspect-ratio: 16/9) { … } @media (device-aspect-ratio: 32/18) { … } @media (device-aspect-ratio: 1280/720) { … } @media (device-aspect-ratio: 2560/1440) { … }
~privacyの考慮点
◎非規範的この節は`不完全@~CSSissue?q=is%3Aopen+is%3Aissue+label%3Amediaqueries-5+label%3Aprivacy-tracker$である。 ◎ this section is incomplete
媒体~特能 `prefers-reduced-data$d は、 ~data量uが制限された低所得者層へ偏ることに伴い,欲されない指紋収集の~sourceになり得る。 ◎ The prefers-reduced-data media feature may be an undesired source of fingerprinting, with a bias towards low income with limited data.
`PreferenceManager$I ~objは、 一部の[ 利用者-選好に関する`媒体~特能$ ]を~queryすることを許容する。 これは、 ~privacy漏洩ではない — その情報は、 すでに`媒体~特能$自体を利用することで自明に可用なので。 ◎ The PreferenceManager object allows querying some user-preference media features. This is not a privacy leak, as that information is already trivially available by using media features themselves.
`PreferenceManager$I ~objは、 これらの[ 利用者-選好に関する`媒体~特能$ ]を上書きすることも許容する。 これは、[ ~privacy, ~accessibility ]どちらの退歩でもない — `媒体~特能$は、 単純に~queryしないことでも【作者は】無視-可能なので。 ◎ The PreferenceManager object also allows overriding these user-preference media features; this is also neither a privacy nor accessibility regression, as the media features were already ignorable by simply not querying them.
~level 4 の~privacyの考慮点
【 便宜のため、 ~level 4 の `§ ~privacyの考慮点@~CSSWG/mediaqueries-4/#privacy$ ( 2024年 1月 24日 時点) (`自己-考査~質問票@~SECQ$に対する回答は除く) の日本語訳をここに与える。 】
媒体~queryは、 ~scriptからは見出すのが困難または不可能なものも含め,~page環境の様々な側面を~CSSから~queryすることを可能化する。 これは、 利用者からの指紋収集を増強して,~privacyを危めるものになり得るが、 その~riskは一般に低い。 同じ情報は、 少なくとも,~scriptから~UA文字列【 `userAgent$c 】を精査することを介して `推定-可能^emになるはずなので。 しかしながら,~UA文字列の偽装は媒体~queryには影響しないので、 検出~技法をいくぶん堅牢にするものにはなる。 ◎ Media Queries enable CSS to query various aspects of the page’s environment, including things that can be difficult or impossible to find via scripting. This is potentially a privacy hazard, allowing enhanced fingerprinting of a user, but the risk is generally low. At minimum, the same information should be inferrable via scripting by examining the user agent string. However, UA string spoofing does not affect Media Queries, making this a somewhat more robust detection technique.
それでも、 媒体~queryにより是認される情報は比較的粗く, これに関して多くの情報量を供与するものではない。 ◎ That said, the information granted by Media Queries is relatively coarse, and does not contribute much entropy in this regard.
少数の旧来の媒体~特能( `device-width$d, `device-height$d, `device-aspect-ratio$d )は、 そうすることに明瞭な便益はないのに,~UAが稼働している環境についての情報を公開する。 それらは互換性の理由から~~保たれるが、 ~privacyと~securityのため,~UAには正確aでない情報を報告することも許容される。 ◎ A few legacy Media Features (device-width, device-height, and device-aspect-ratio) expose information about the environment in which the UA is running without any clear benefit to doing so. They are retained for compatibility reasons, but for the sake of privacy and security, UAs have been allowed to report inaccurate information.
~securityの考慮点
◎非規範的この節は`不完全@~CSSissue?q=is%3Aopen+is%3Aissue+label%3Amediaqueries-5+label%3Asecurity-tracker+$である。 ◎ this section is incomplete
`display-mode$d 媒体~特能は、[ 利用者の局所的な~computing環境を成す いくつかの側面への~access ]を生成元に許容する — 特に[ `~app~manifest$の `display@~APPMANIFEST#dfn-display$c ~member `APPMANIFEST$r ]と一緒に利用されるとき,[ ~UAの~native~UIに対し,何らかの制御を講じること ]を生成元に許容する — ~scriptは、 ~CSS媒体~queryを通して~web~appの表示~modeを知れるので。 そのような事例では、 攻撃者は[ ある~appが~fullscreen内に表示されている事実 ]を[ 別の~appの~UIを真似る ]ために悪用することもできる。 ◎ The display-mode media feature allows an origin access to aspects of a user’s local computing environment and, particularly when used together with an application manifest display member [APPMANIFEST], allows an origin some measure of control over a user agent’s native UI. Through a CSS media query, a script can know the display mode of a web application. An attacker could, in such a case, exploit the fact that an application is being displayed in fullscreen to mimic the user interface of another application.
~level 4 の~securityの考慮点
【 便宜のため、 ~level 4 の `§ ~securityの考慮点@~CSSWG/mediaqueries-4/#security$ ( 2024年 1月 24日 時点) の日本語訳をここに与える。 】
この仕様に対し報告された新たな~securityの考慮点は無い。 ◎ No new security considerations have been reported on this specification.
変更点
◎非規範的- `2021 年 12月 18日 作業草案@~TR/2021/WD-mediaqueries-5-20211218/$ からの変更点 (編集上のもの,小さな明確化は除く) ◎ Changes Since the 18 December 2021 Working Draft ◎ In addition to editorial changes and minor clarifications, the following changes and additions were made to this module since the 2021-12-18 Working Draft:
- `Display-P3$r への規範的な参照を~~追加した。 ◎ Establish a normative reference for [Display-P3]
- 媒体~型としての `layer^vm の利用は、 単に未知なものとして扱うのでなく,許容しないようにした — `~cascade層$との互換性を得るため。 ◎ Disallow use of layer as a media type, rather than merely treat it as an unknown one, for compatibility with cascade layers.
- `prefers-reduced-motion$d の意図を明確化した。 ◎ Clarify intent of prefers-reduced-motion
- `2020年 7月 31日 作業草案@~TR/2020/WD-mediaqueries-5-20200731/$ からの変更点と追加 (編集上のもの,小さな明確化は除く) ◎ Changes Since the 2020-07-31 Working Draft ◎ In addition to editorial changes and minor clarifications, the following changes and additions were made to this module since the 2020-07-31 Working Draft:
- `APPMANIFEST$r から `display-mode$d を採用した。 ( `6343$issue ) ◎ Adopted display-mode from [APPMANIFEST]. (See Issue 6343)
- 媒体~特能[ `video-width^d, `video-height^d, `video-resolution^d ]を落とした — それは、[ `双平面~実装@#video-prefixed-features$における~video平面の幾何 ]について~queryすることが意味されていた。 ( `5044$issue を見よ) ◎ Dropped the media features what were meant to query about the geometry of the video plane in bi-plane implementations: video-width, video-height, and video-resolution. (See Issue 5044)
- `prefers-contrast$d 用の値[ `high^v / `low^v ]を[ `more$v1 / `less$v1 ]に改称した。 ( `2943$issue ) ◎ Renamed prefers-contrast values high and low to more and prefers-contrast less. (See Issue 2943)
- `prefers-contrast$d と `forced-colors$d の相互作用を作業し直した — `prefers-contrast$d 用の値 `forced^v を退役させた一方で, 値 `custom$v1 を導入した ( `5433$issue, `6036$issue ) ◎ Rework the interaction between prefers-contrast and forced-colors, retiring prefers-contrast: forced and introducing custom. (See Issue 5433) and Issue 6036)
- 媒体~特能[ `horizontal-viewport-segments$d, `vertical-viewport-segments$d ]を追加した。 ( `6234$issue ) ◎ Added the horizontal-viewport-segments and vertical-viewport-segments media feature. (See Issue 6234)
- 媒体~特能 `nav-controls$d を 追加した。 ( `6234$issue ) ◎ Added the nav-controls media feature. (See Issue 6234)
- `dynamic-range$d が同時に複数の値に合致するのもアリにした。 ( `6793$issue ) ◎ Make it possible for multiple values of dynamic-range to match at the same time. (See Issue 6793)
- `2020年 7月 15日 作業草案@~TR/2020/WD-mediaqueries-5-20200715/$ からの変更点 ◎ Changes Since the 2020-07-15 Working Draft ◎ The following additions were made to this module since the 2020-07-15 Working Draft:
- `inverted-colors$d 用の~UA~stylesheet規則を追加した。 【が、後に`除去された@https://github.com/w3c/csswg-drafts/commit/6ea2265e8c887e16b560c0ce6f3b9f269b921f12$。】 ◎ Added a UA style sheet rule for inverted-colors.
- `prefers-contrast$d 用の値として `forced$v1 を追加した。 ◎ Added the prefers-contrast: forced value.
- `light-level@d 【!Ambient Light Sensorから参照】 媒体~特能は除去した — [ `prefers-contrast$d, `prefers-color-scheme$d ]と~~重なって冗長なので。 それに伴い、 ~UAがこれらの媒体~特能の`実~値$を[ `light-level^d が応答するものと期待されていた同じ要因 ]に基づいて,どう自動的に推定するかについて例を追加した。 ◎ Remove the light-level media feature as it is redundant with prefers-contrast and prefers-color-scheme; add examples of how these media features may be automatically inferred by the user agent based on the same factors light-level was expected to respond to.
- `2020年 6月 3日 作業草案@~TR/2020/WD-mediaqueries-5-20200603/$ からの変更点 ◎ Changes Since the 2020-06-03 Working Draft ◎ The following additions were made to this module since the 2020-06-03 Working Draft:
- ~level 4 の内容を この仕様に併合した。 それまでは、 ~level 4 からの差分として保守されていた。 ◎ Merged the content of level 4 into this specification. It previously was maintained as a delta over level 4.
- 少数の編集上の手直し。 ◎ Made a few editorial tweaks.
- `2020年 3月 18日 作業草案@~TR/2020/WD-mediaqueries-5-20200318/$ からの変更点 ◎ Changes Since the 2020-03-18 Working Draft ◎ The following additions were made to this module since the 2020-03-18 Working Draft:
- 次に挙げる媒体~特能を追加した ⇒# 各種 `video-*^d, `dynamic-range$d ◎ Added video-* and dynamic-range media features
- `prefers-color-scheme$d 用の値 `no-preference^v を除去した。 ◎ Removed 'prefers-color-scheme: no-preference'
- `2020年 3月 3日 最初の公な作業草案@~TR/2020/WD-mediaqueries-5-20200303/$ からの変更点 ◎ Changes Since the First Public Working Draft ◎ The following additions were made to this module since the 2020-03-03 First Public Working Draft:
- 既知な課題いくつかを文書~内に特に含めた。 ◎ Highlight some known issues inline in the document.
- `~level 4@~TR/mediaqueries-4/$ から,この~moduleの最初の公な作業草案までの変更点 ◎ Changes for FPWD (since the Media Queries Level 4) ◎ The following additions were made to create the First Public Working Draft of this module, since the Media Queries Level 4:
- 早期の Media Queries Level 4 草案から、 次に挙げる節を ここに復活した ⇒# § `light-level$d, § `inverted-colors$d, § `~custom媒体~query$ ◎ Reinstate the light-level, inverted-colors, and Custom Media Queries sections from earlier Media Queries Level 4 drafts.
- 次に挙げる媒体~特能を追加した ⇒# `prefers-reduced-motion$d, `prefers-reduced-transparency$d, 【`prefers-reduced-data$d,】 `prefers-contrast$d, `prefers-color-scheme$d, `forced-colors$d ◎ Added prefers-reduced-motion, prefers-reduced-transparency, prefers-contrast, prefers-color-scheme, and forced-colors media features.
~level 4 の変更点
【 便宜のため、 ~level 4 の `§ 変更点@~CSSWG/mediaqueries-4/#changes$ ( 2024年 1月 24日 時点) の日本語訳をここに与える。 】
- `2021年 12月 25日 勧告候補~草案@~TR/2021/CRD-mediaqueries-4-20211225/$からの変更点 ◎ Changes since the 25 December 2021 Candidate Recommendation Draft ◎ The following changes were made to this specification since the 25 December 2021 Candidate Recommendation Draft:
- `Display-P3$r への規範的な参照を~~追加した。 ◎ Establish a normative reference for [Display-P3]
- 媒体~型としての `layer^vm の利用は、 単に未知なものとして扱うのでなく,許容しないようにした — `~cascade層$との互換性を得るため。 ◎ Disallow use of layer as a media type, rather than merely treat it as an unknown one, for compatibility with cascade layers.
- `2020年 7月 21日 勧告候補~snapshot@~TR/2020/CR-mediaqueries-4-20200721/$からの変更点 ◎ Changes since the 21 July 2020 Candidate Recommendation ◎ The following changes were made to this specification since the 21 July 2020 Candidate Recommendation:
- `general-enclosed$t 内に空な関数を許容した。 ( `6803$issue ) ◎ Allow empty functions in (see Issue 6803).
- 文法をどう定義するかに関する編集上の手直し。 ( `6806$issue ) ◎ Editorial tweak to how the grammar is defined (see Issue 6806).
- `2017年 9月 5日 勧告候補~snapshot@~TR/2017/CR-mediaqueries-4-20170905/$ からの変更点: ◎ Changes since the 5 September 2017 Candidate Recommendation ◎ The following changes were made to this specification since the 5 September 2017 Candidate Recommendation:
- 媒体~型 `speech$vm は非推奨にした。 媒体~型は排他的であるが、 それは,~screen~reader — その名が指示するように,~screenに具現化した結果に基づいて働く~UA — 用にはなり得ず,媒体~型 `screen$vm に合致することになるので。 `speech^vm を純粋な音声~UA用とすることもできたが、 そのような既知な実装は無い。 ◎ Deprecate the speech media type. As media types are exclusive, it cannot be about screen readers, which as their name indicates, work based on a screen rendition, and therefore match the screen media type. It could have been about pure-audio UAs, but no such implementation is known.
- `CSS-SYNTAX-3$r を参照して,~tokenの構文解析は ~ASCII大小無視であることを喚起する注記を追加した。 ◎ Add note referencing the syntax spec to remind that token parsing is ascii case insensitive
- 比較を伴わない `(width 500px)^css の様な形を不用意に許容していた文法~内の~bugを修正した。 ◎ Fix a bug in the grammar that accidentally allowed forms like (width 500px), without any comparison
-
`ratio$t の定義を `CSS-VALUES-4$r に委任した。 それは今や、 この~module以外からも利用されるので。 ◎ Delegate the definition of <ratio> to [CSS-VALUES-4], as it is now used by more than just mediaqueries.
注記: `CSS-VALUES-4$r は、 `ratio^t の定義を[ `ratio^t = `integer$t / `integer^t ]から[ `ratio^t = `number [0,∞]$t [ / `number [0,∞]^t ]? ]へ拡げた。 ◎ Note: [CSS-VALUES-4] has expanded the definition from <ratio> = <integer> / <integer> to <ratio> = <number [0,∞]> [ / <number [0,∞]> ]?
- 編集上の様々な[ 手直し, 言い回しの改善, 明確化 ]。 ◎ Various editorial tweaks, phrasing improvements, and clarifications.
- 用語[ `連続的~媒体$, `~paged媒体$ ]の定義を追加した。 ◎ Add definitions for the terms continuous media and paged media.
- `overflow-block$d 用の値 `optional-paged^v を落とした — それが述べる挙動を備える~UAは、 現在は無いことに因り。 ◎ Dropped the optional-paged value of overflow-block due to a lack of current UAs having the behavior that it described.
- `update$d は、 ~risk下にあるとした。 ◎ Mark update at risk.
- `2017年 5月 19日 作業草案@~TR/2017/WD-mediaqueries-4-20170519/$ からの変更点: ◎ Changes since the 19 May 2017 Working Draft ◎ The following changes were made to this specification since the 19 May 2017 Working Draft :
- `範囲~型$の媒体~特能に対する負な値は、 構文解析に失敗するのでなく,`負な範囲は偽になる$よう変更した。 ◎ Changed range media features to be false in the negative range instead of failing to parse negative values.
- 色域に必要な色~空間についての十分な情報を,仕様の中に直に含ませた。 ◎ Included enough information about the color spaces needed by color-gamut directly into the specification.
- ~risk下にあった,次に挙げる媒体~特能は、 もはや,そうでなくなった 【!#changes-2017-9 に記されるはずだが、ここに記されている】 ⇒ `hover$d, `pointer$d, `any-hover$d, `any-pointer$d ◎ Marked hover, pointer, any-hover, and any-pointer as no longer at-risk.
- `2012年 6月 19日 勧告 Media Queries Level 3@~TR/css3-mediaqueries/$ からの変更点: ◎ Changes Since Media Queries Level 3 ◎ The following changes were made to this specification since the 19 June 2012 Recommendation of Media Queries Level 3:
- 大幅な,編集上の書直しと再編成。 ◎ Large editorial rewrite and reorganization of the document.
- `真偽-文脈@#mq-boolean-context$下での`媒体~特能$は、 今や, `素-文脈$の下で`~test値$が~keyword `none^v であるとき `真^i に評価される場合も, `偽^i に評価される。 ◎ Boolean-context media features are now additionally false if they would be true for the keyword none.
- 数的な値をとる`媒体~特能$は、 今や `範囲~文脈@#mq-range-context$の下で評価されるように記せる。 ◎ Media features with numeric values can now be written in a range context.
- 次に挙げる媒体~特能が追加された ⇒ `pointer$d, `any-pointer$d, `hover$d, `any-hover$d, `update$d, `color-gamut$d, `overflow-block$d, `overflow-inline$d ◎ The pointer, any-pointer, hover, any-hover, update, color-gamut, overflow-block, and overflow-inline media features were added.
- 次に挙げる~keywordは、 `媒体~型$として認識されないようにした — 無効な`媒体~型$としても(代わりに構文~errorを誘発する) ⇒ `or^vm, `and^vm, `only$vm, `not$vm ◎ or, and, only and not are disallowed from being recognized as media types, even invalid ones. (They’ll trigger a syntax error instead.)
- 次を除く`媒体~型$を、 すべて非推奨にした ⇒ `screen$vm, `print$vm, `speech$vm, `all$vm ◎ All media types except for screen, print, speech, and all are deprecated.
- `device-width$d, `device-height$d, `device-aspect-ratio$d は、 非推奨にされた。 加えて,~privacyと~security上の理由から、 それらは,~screenに代えて`~Webに公開される~screen区画$を指すようにされた。 ◎ Deprecated device-width, device-height, device-aspect-ratio, and made them refer to the Web-exposed screen area instead of the screen for privacy and security reasons.
- 一部の事例では、 Mediaqueries は~stylesheetの評価に依存する。 【?】 ◎ Mediaqueries may depend on the evaluation of style sheets in some cases
謝辞
◎非規範的この仕様は、 W3C ~WGによる, Cascading Style Sheets における成果である。 ◎ This specification is the product of the W3C Working Group on Cascading Style Sheets.
~commentを寄せられ,この仕様を改善した次の方々に:
Comments from 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, and 張俊芝 improved this specification.