1. 序論
`css-variables-1$r 仕様は、 “~cascadeしている変数” の概念を定義した — それは、 `~custom~prop$の値から作成される作者~定義な変数であり， `var$f 関数を介して他の任意な~propの中へ代入される能力がある。 ◎ The [css-variables-1] specification defined the concept of "cascading variables", author-defined variables created from the value of custom properties, capable of being substituted into arbitrary other properties via the var() function.
この仕様は、 `環境~変数$の概念を定義する。 それは、 ~cascadeしている変数に関係するが，より単純である。 ~cascadeしている変数は，対応する`~custom~prop$が異なる値をとるに伴い変化し得るが、 `環境~変数$は，~page全体を通して “大域的” である — その値は、 文書~内のどこでも同じになる。 `環境~変数$の値は、 `var$f 関数と類似に， `env$f 関数を利用して任意な所在の中へ値を代入できる。 ◎ This specification defines a related, but simpler, concept of environment variables. Unlike "cascading variables", which can change throughout the page as their corresponding custom property takes on different values, an environment variable is "global" to a particular document—its value is the same everywhere. The env() function can then be used to substitute the value into arbitrary locations, similar to the var() function.
これらの “大域的な” 変数には、 ~cascadeしている変数に比べて，便益も難点もある： ◎ These "global" variables have both benefits and downsides versus cascading variables:
- 多くの変数 — 例：~themeを設定しておくもの, 特定0の数量的な値を書き易くするもの — は、 ~page内の~~場所に応じて変化するものとは意味されない。 これらを適正な意図が伝わるよう定義するためには、 `~custom~prop$の代わりに`環境~変数$を利用する方が， 作者にとって良くなり （特に，同じ文書に対し複数人が協同しているとき）, ~UAにとっても良くなる （これらの変数を より最適な仕方で格納できるので）。 ◎ Many variables aren’t meant to change over the course of a page; they set up themes, or are helpers for particular numerical values. Using environment variables instead of custom properties to define these communicates the proper intent, which is good both for the author of the document (particularly when multiple people are collaborating on a single document), and for the user agent, as it can store these variables in a more optimal way.
- `環境~変数$は、 特定0の要素から値を取り出すことには依存しないので， そのような明白な要素が無いため `var$f 関数は無効になる所でも — `media$at 規則~内など — 利用できる。 ◎ Because environment variables don’t depend on the value of anything drawn from a particular element, they can be used in places where there is no obvious element to draw from, such as in @media rules, where the var() function would not be valid.
- `env$f を介して，~UAからの情報 — 表示域の~margin （そこに既定で~lay-outすることを （そうすると，例えば~screen内の “出っ張り” と重合するので） 避けるための）など — を検索取得できる。 一方で， `var$f は、 その資質 — 要素に特有であること — から，そのような情報を注ぎ込む場所としては適切でなかった。 ◎ Information from the user agent itself, such as the margin of the viewport to avoid laying out in by default (for example, to avoid overlapping a "notch" in the screen), can be retrieved via env(), whereas the element-specific nature of var() was not an appropriate place to pipe that information in.
ほとんどの`環境~変数$は、 ~scalarである — すなわち，一時に 1 個の値を有する。 しかしながら， 同時に複数個の値を表現するよう “~index化される” ものもある （例： `表示域~segment変数＠#viewport-segments$（ `viewport-segment-*^v ）における別個な~segmentたち【！panes of content】の~sizeや位置など）。 これらの~index化された変数を参照rするためには、 【作者は】当の変数~名と伴に 1 個以上の整数~indexを供さなければナラナイ （例： `viewport-segment-width 1 0^v の様に） — この個数は、 各`環境~変数$ごとに指定され，当の変数の `次元~数@ と称される — ~scalarな`環境~変数$の`次元~数$は 0 と定義される。 それは、 当の環境~変数を成す値たちから，所与の~indexたちが成す組に対応する値【！list or grid of possibilities】を選定する — 伝統的な~programming言語において， `values[ 0 ]^c 様な構文で~listから 要素を選定することと類似に。 ◎ Most environment variables will have a single value at a time. Some, however, are "indexed", representing multiple values at once, such as the sizes and positions of several distinct panes of content in the viewport-segment-* variables. To refer to these indexed variables, one or more integers must be provided alongside the variable name, like viewport-segment-width 1 0, to select a single value from the list or grid of possibilities, similar to selecting one element from a list in a traditional programming language with a syntax like values[0].
【 用語 “次元~数（ `number of dimensions^en ）” は、 明確化するための，この訳による追加。 】
2. 環境~変数
~CSSの `環境~変数@ は、 `declaration-value$t （ 0 個~以上の~CSS~tokenたちが成す連列であって、 どの~tokenが存在し得るかに関して，ほぼ制約が無いもの） に結付けられる名前であり，`~custom~prop$に類似する。 `環境~変数$には、［ ~UAにより定義されるもの, 作者【！利用者】により定義されるもの ］どちらもある （後者の名前は、 `custom-property-name$t であり，~custom識別子~用に標準な `--^css から開始する）。 ◎ A CSS environment variable is a name associated with a <declaration-value> (a sequence of zero more CSS tokens, with almost no restrictions on what tokens can exist), similar to a custom property. Environment variables can be defined by the user agent, or by the user. (In the latter case, the names are <custom-property-name>s, and start with `--` per standard for custom identifiers.)
~UA定義な`環境~変数$たちが成す集合を~scriptから可視にするか？ そうならば、 それらを公開する~APIを `Document$I 上に定義する。 ◎ Is the set of UA-defined environment variables visible to script? If so, define an API on Document to expose them.
作者が`環境~変数$をどう追加できるかを定義する — ~JS, ~CSSどちらを介しても行える方が好ましい。 ~CSS規則と~JS定義なモノを混ぜ合わせると、 `CSSFontFaceRule$I と `FontFace$I の~~比較対照によりデモられるとおり， 無秩序になり易いことに注意。 ◎ Define how authors can add environment variables, preferably both via JS and via CSS. Note that mixing CSS rules and JS-defined stuff can easily get messy, as demonstrated by CSSFontFaceRule vs FontFace...
公式的には、 ~UA定義な`環境~変数$として，以下の各下位節に挙げるものが定義される — ~UAは、 それらのみを~supportして，他は~supportしないモノトスル。 ◎ The following UA-defined environment variables are officially defined and must be supported. Additional UA-defined environment variables must not be supported unless/until they are added to this list.
2.1. 安全~区画~inset変数
| 名前 | 値 | `次元~数$ |
|---|---|---|
| `safe-area-inset-top@v | `length$t | 0 |
| `safe-area-inset-right@v | `length$t | 0 |
| `safe-area-inset-bottom@v | `length$t | 0 |
| `safe-area-inset-left@v | `length$t | 0 |
これら 4 個の`環境~変数$は、 順に，表示域の各~辺からの［ 上端, 右端, 下端, 左端 ］~insetで［ 安全な区画を成す矩形 ］を定義する。 矩形な~display用には、 これらはすべて 0 になるモノトスル。 矩形でない~display用には、 これらは，~UAにより選ばれる［ ~AND↓ を満たす矩形 ］を形成するモノトスル： ◎ The safe area insets are four environment variables that define a rectangle by its top, right, bottom, and left insets from the edge of the viewport. For rectangular displays, these must all be zero, but for nonrectangular displays they must form a rectangle, chosen by the user agent,＼
- 矩形の内側にある すべての内容は、 可視になる ◎ such that all content inside the rectangle is visible,＼
- いずれかの~insetを抑制すると［ ~displayの矩形でない資質 ］に因り［ 矩形の内側にある一部の内容 ］が不可視になる ◎ and such that reducing any of the insets would cause some content inside of the rectangle to be invisible due to the nonrectangular nature of the display.＼
【 すなわち、 ~displayの形状に収まる最大な矩形。 そのような矩形は、 “面積が最大” のような条件も追加されない限り， 一意になるとは限らないが （例えば，~displayの形状が上下左右対称かつ凸なら、 それに内接する どの矩形も条件を満たす）。 ~UAの動的な~UIが展開されている下では、 この形状からは，そのような~UIが占める区画も除外される （`動的な表示域~size$に基づく）ので、 これらの変数は，動的に変化し得る — そのことは、 `§ 最大~安全~区画~inset変数＠#safe-area-max-insets$の記述から推定される。 】
これは、 次を作者に許容する ⇒ 本質的な内容の~layoutを［ 安全な区画を成す矩形の内側を成す空間 ］に制限する ◎ This allows authors to limit the layout of essential content to the space inside of the safe area rectangle.
2.2. 最大~安全~区画~inset変数
| 名前 | 値 | `次元~数$ |
|---|---|---|
| `safe-area-max-inset-top@v | `length$t | 0 |
| `safe-area-max-inset-right@v | `length$t | 0 |
| `safe-area-max-inset-bottom@v | `length$t | 0 |
| `safe-area-max-inset-left@v | `length$t | 0 |
最大~安全~区画~inset†は、 `安全~区画~inset変数＠#safe-area-insets$に束ねられた 4 個の`環境~変数$である。 動的な値である安全~区画~inset変数と違って、 最大~安全~区画~insetは，静的な値であり、 各自に対応する動的な変数の最大~値を表現する — ~UAの動的~UIが収納され，`~layout表示域$の~sizeが`大きい表示域~size$になったときの。 ◎ The safe area maximum insets are four environment variables that are tied to the safe area inset variables. Unlike the safe area inset variables which are dynamic values, the safe area maximum insets are static values that represent the maximum value of their dynamic counterpart when dynamic UA interfaces are retracted, making the layout viewport size the large viewport size.
【† 原文では， “安全~区画~最大~inset” と称されるが、 この “最大” は~insetではなく区画を形容する — ~insetが大きくなるほど区画は狭くなるので，そう解釈する他にない。 】
2.3. 表示域~segment変数
| 名前 | 値 | `次元~数$ |
|---|---|---|
| `viewport-segment-width@v | `length$t | 2 |
| `viewport-segment-height@v | `length$t | 2 |
| `viewport-segment-top@v | `length$t | 2 |
| `viewport-segment-left@v | `length$t | 2 |
| `viewport-segment-bottom@v | `length$t | 2 |
| `viewport-segment-right@v | `length$t | 2 |
表示域~segmentは、 表示域を成す論理的に別々な各~領域の［ 位置と寸法 ］を定義する`環境~変数$である。 表示域~segmentは、 表示域が何個かの［ 分離帯として動作する~hardware特能 （別々な~displayの合間にある “折り目” など） ］により分割されるとき作成される — 各~segmentは、表示域を成す［ 作者が論理的に別個なものとして扱える領域 ］である。 ◎ The viewport segments are environment variables that define the position and dimensions of a logically separate region of the viewport. Viewport segments are created 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 divider; segments are the regions of the viewport that can be treated as logically distinct by the author.
各［ 表示域~segment`環境~変数$ ］の`次元~数$は 2 であり，［ ~segmentたちを分離している~hardware特能により作成された 2 次元な格子 ］において順に ~x, ~y 位置を表現する。 左端~辺に接する~colを成す各~segmentの~x 位置は 0, その右にある~colにおける~x位置は 1 になる, 等々。 類似に，上端~辺に接する~segmentの~y位置は 0 になる, 等々。 ◎ The viewport segment environment variables have two dimensions, which represent the x and y position, respectively, in the two dimensional grid created by the hardware features separating the segments. Segments along the left edge have x position 0, those in the next column to the right have x position 1, etc. Similarly, segments along the top edge have y position 0, etc.
注記： ある種の~hardware環境設定においては、 分離帯~自体が表示域の中で論理的な空間を占め得る。 分離帯の寸法は［ 表示域~segmentの位置の合間にある区画 ］を計算することにより算出できる。 ◎ Note: In certain hardware configurations, the separator itself may occupy logical space within the viewport. The dimensions of the separator can be computed by calculating the area between the position of the viewport segments.
表示域が横並びに 2 個の~segmentに分割されたときは、［ 左端／右端 ］にある表示域~segmentに対応する~index群は［ ( 0, 0 ) ／ ( 1, 0 ) ］になり， 前者の横幅は `env(viewport-segment-width 0 0【！, 300px】)^v として表現されよう。 類似に，表示域が縦並びに 2 個の~segmentに分割されたときは、［ 上端／下端 ］にある表示域~segmentに対応する~index群は［ ( 0, 0 ) ／ ( 0, 1 ) ］になろう。 ◎ When the viewport is split into two side-by-side segments, the viewport segment on the left would have indices (0, 0). Its width would be represented as env(viewport-segment-width 0 0, 300px). The viewport segment on the right would have indices (1, 0). Similarly, for a viewport split into two vertical segments, the viewport segment on the top would have indices (0, 0) and the one on the bottom (0, 1).
これらの変数は、 そのような~segmentが 2 個~以上~在るときに限り定義される。 表示域を分割している~hardware特能が無い場合、 代わりに，表示域~単位【？】を利用するベキである — さもなければ、 複数の~segmentを伴う機器で視られるとき， 内容は意図されたとおりに表示されなくなる【なぜ？】。 ◎ These variables are only defined when there are at least two such segments. Viewport units should be used instead when there is no hardware feature splitting the viewport, otherwise content will not display as intended when viewed on a device with multiple segments.
2.4. 選好される~text~zoom
| 名前 | 値 | `次元~数$ |
|---|---|---|
| `preferred-text-scale@v | `number$t | 0 |
`環境~変数$ `preferred-text-scale$v は、 利用者が選好した~text拡縮-係数 — 言い換えれば、 利用者が~OSや~UAの “既定の” ~font~sizeになるよう為した調整 — を表現する （ `text-size-adjust$p の効果がある機器においては、 これは，その値 `auto^v により適用される拡縮-係数になる）。 ◎ The preferred-text-scale environment variable represents the user’s preferred text scale factor; aka, the adjustment they make to the "default" font size of the OS and/or user agent. (On devices where text-size-adjust has an effect, this is the scale factor applied by text-size-adjust: auto.)
例えば、 `text-size-adjust$p を `auto^v にした結果，~text~sizeが 2 倍になる場合、 `env(preferred-text-scale)^v は `2^v に解決されよう。 ◎ For example, if text-size-adjust:auto would cause text sizes to double, then env(preferred-text-scale) would resolve to 2.
注記： `pem^u 単位 【まだ仕様~化されていない（`10674$issue）】は、 これと同じ情報を表現する — `1em^v 【 `1pem^v ？】は、 正確に `calc(1em * env(preferred-text-scale))^v と等価になる。 何かを直に~sizeするときは、 単に `bsem^u 【？】を長さに利用する方が簡便になる。 ◎ Note: The pem unit represents this same information; 1em is exactly equivalent to calc(1em * env(preferred-text-scale)). When directly sizing things, bsem is just a more convenient length to use.
この`環境~変数$を正しく利用するためには、 ~careが要求される。 既定では，~text拡縮は自動的に適用されるので、［ `env(preferred-text-scale)^v ／ `pem^u ］を利用すると拡縮-が`二重^emに適用される結果になり，~textや~UI要素が大き過ぎになる。 ◎ This environment variable requires care to be used correctly. By default, text scaling is applied automatically; using env(preferred-text-scale) or pem would result in the scale being double-applied, making text or UI elements too large.
概して、 作者は，次のいずれかを行うべきである： ◎ Typically, authors should either:
- ~page内のすべての~textが利用者の選好へ自動的に拡縮されることを確保するよう， `text-size-adjust$p を `calc(100% * env(preferred-text-scale))^v に設定する — 必要yなら、 ~text以外の~sizeも同じ拡縮-係数で拡縮する。 ◎ set text-size-adjust: calc(100% * env(preferred-text-scale));, to ensure that all the text in the page is automatically scaled to the user’s preference, and when necessary scale non-text sizes by the scale factor as well.
- `text-size-adjust$p を `none^v に設定した上で，［ この`環境~変数$／ `pem^u 単位 ］を一貫して利用する — 関連な~textや~UIを利用者の選好へ拡縮するよう。 ◎ or set text-size-adjust:none, and then consistently use this environment variable and/or the pem unit to scale relevant text and UI to the user’s preference.
3. 環境~変数の利用-法： `env$f 記法
`環境~変数$の値を~CSS文脈の中へ代入するためには、 `env$f 関数を利用する： ◎ In order to substitute the value of an environment variable into a CSS context, use the env() function:
`env@f = env( `custom-ident$t `integer$t*, `declaration-value$t? )
`env$f 関数は、［ どの要素のどの~propの値／ どの`~at-規則$内の どの記述子の値 ］を成すどの部分にも利用でき，［ ~CSS値が許容される他のいくつかの場所 ］にも利用できる。 ◎ The env() function can be used in place of any part of a value in any property on any element, or any part of a value in any descriptor on any at-rule, and in several other places where CSS values are allowed.
`env$f をどこで利用できるかを全部的に定義する — 例えば： ◎ Define the full set of places env() can be used.
- 媒体~query構文を成す どの部分も置換-可能になるベキか？ ◎ Should be able to replace any subset of MQ syntax, for example.
- 選択子を置換-可能になるベキか？ ◎ Should be able to replace selectors, maybe?
- それは、 規則~levelで［ ~style規則の中へ任意なモノを — 宣言たちが成す~blockを再利用する様に — 挿入できる ］よう働くベキか？ ◎ Should it work on a rule level, so you can insert arbitrary stuff into a rule, like reusing a block of declarations?
`env$f の最初の引数は、 代入されることになる`環境~変数$の名前を供する。 当の環境~変数の`次元~数$が 0 でない場合には、 後続する同じ個数の~indexたちに対応する値が代入~値として利用される 【！Following the first argument...】。 ~commaの後にも引数が供された場合、 それが~fallback値になり， 参照された`環境~変数$が存在しないときに代入~値として利用される。 ◎ The first argument to env() provides the name of an environment variable to be substituted. Following the first argument are integers that represent indices into the dimensions of the environment variable, if the provided name represents an array-like environment variable. The argument after the comma, if provided, is a fallback value, which is used as the substitution value when the referenced environment variable does not exist.
注記： ~fallbackの構文は、 ~custom~propと同様に~commaを許容する。 例えば， `env(foo, red, blue)^v は、 ~fallback値 `red, blue^v を定義する — すなわち、 最初の~commaから関数の終端までの合間にあるものすべてが， ~fallback値と見なされる。 ◎ Note: The syntax of the fallback, like that of custom properties, allows commas. For example, env(foo, red, blue) defines a fallback of red, blue; that is, anything between the first comma and the end of the function is considered a fallback value.
［ ~prop／記述子 ］宣言が何個かの `env$f 関数を包含していて，どれも構文上は妥当である場合、 当の宣言~全体の文法は，構文解析-時点では妥当と見做すモノトスル。 構文が検査されるのは、 `env$f 関数へ`代入-$された後 — ~propの場合は算出d値の時点 — に限られる。 ◎ If a property contains one or more env() functions, and those functions are syntactically valid, the entire property’s grammar must be assumed to be valid at parse time. It is only syntax-checked at computed-time, after env() functions have been substituted. ◎ If a descriptor contains one or more env() functions, and those functions are syntactically valid, the entire declaration’s grammar must be assumed to be valid at parse time. It is only syntax-checked after env() functions have been substituted.
［ ~prop／記述子 ］内の `env$f 関数 %関数 へ `代入-@ するときは： ◎ To substitute an env() in a property or descriptor:
- %名前 ~LET %関数 の最初の引数に供された名前 ◎ ↓
-
`(A)^i：
- ~IF［ %名前 は~UAが認識する`環境~変数$の名前でない ］ ⇒ ~BREAK `(A)^i
- %変数 ~LET %名前 により参照される`環境~変数$
- %~index群 ~LET %関数 内の %名前 に伴って給された整数たち
- ~IF［ %~index群 を成す整数の個数 ~EQ %変数 の`次元~数$ ］ ⇒ ~BREAK `(A)^i
- ~IF［ %変数 の %~index群 に対応する下位-値は在る ］ ⇒ %関数 を当の下位-値により置換する
- ~RET
-
~IF［ %関数 は 2 個目の引数として，~fallback値 %~fallback を伴う ］：
- %~fallback を成す ~EACH( `env$f 参照 %env ) に対し ⇒ %~fallback 内の %env へ`代入-$する
- %関数 を %~fallback で置換する
- ~ELSE ⇒ %関数 は`算出d値の時点で無効$とする。 ◎ Otherwise, the property or descriptor containing the env() function is invalid at computed-value time.
代入がいつ起こるかを定義する。 それは、 `var$f への代入より前になる必要がある。 代替として、 `env$f による代入は［ 未知な変数~名は構文~検査を失敗させるよう，構文解析-時点に起こる ］ベキか？ `var$f の様のように算出d値の時点に — `~custom~prop$の値が `var^f へ代入される【！picked up】前に，その値を他【！down】へ継承できることを確保するために — 起こるようにする理由は，特に無い ◎ Define when substitution happens. It has to be before var() substitution. Alternately, should env() substitution happen at parse time, so unknown variable names cause it to fail syntax checking? There’s no particular reason to have it happen at computed-value time, like var() does—that was to ensure that custom properties could inherit their value down before they were picked up by a var().
`env$f を他のどこで利用できるか解明されたなら、 それを［ いつ, どう ］代入するかを定義する。 ◎ When I figure out where else env() can go, define how/when it substitutes.
3.1. 略式~propにおける環境~変数
`env$f に対する代入が構文解析の間に起こる場合、 これは必要yでない。 ◎ If env() substitution happens during parsing, then this is unnecessary.
`略式~prop$に伴われる `env$f 関数は、 `var$f 関数と同じ困難さをもたらす。 `env$f が`略式~prop$内で利用された場合、 `CSS-VALUES-5$r `§ 略式~propにおける代入＠~CSSVAL5#substitution-in-shorthands$ 【！CSS Variables 1 , ~CSSVAR#variables-in-shorthands】 にて定義されるものと同じ効果になる。 ◎ The env() function causes the same difficulties with shorthand properties as the var() function does. When an env() is used in a shorthand property, then, it has the same effects as defined in CSS Variables 1 § 3.2 Variables in Shorthand Properties.
4. ~privacyの考慮点
この仕様が定義する`環境~変数$は、 ~privacyに敏感に`なり得る^em — それらは、 ~pageには まだ可用でないかもしれない追加的な情報を表現するので。 特に，それらは、［ 利用者が~pageを視るために利用している機器について追加的な情報を公開する ］ことにより，指紋収集~行路を表現するものになり得る。 ◎ The environment variables defined by this specification are potentially privacy-sensitive, since they represent additional information potentially not already avaialble to the page. In particular, they potentially represent a fingerprinting vector, by exposing additional information about the device a user is viewing the page with.
この仕様が定義する`環境~変数$は，これまでの所、 ~CSS~WGにより考査され，公開することは受容-可能であるものと判断された。 ◎ So far, the environment variables defined by this specifcation have been reviewed and deemed acceptable to expose by the CSSWG.
5. ~securityの考慮点
この仕様は、 機器についての［ いくつか新たな型を成す情報 ］に対し読専な~accessを供する。 ◎ This specification provides read-only access to some new types of information about the device.
この仕様が定義する`環境~変数$には、 ~securityに敏感な情報を公開するものは無い。 ◎ The environment variables defined by this specification do not expose any security-sensitive information.