CSS の値と単位 — CSS Values and Units Module Level 5

1.1. ~module間の相互作用

`~level 4$ は、 `CSS21$r の `§ 1.4.2.1＠~TR/CSS2/about.html#value-defs$, `§ 4.3＠~TR/CSS2/syndata.html#values$, `§ A.2＠~TR/CSS2/aural.html#aural-intro$ による各種~data型~定義を置換して，拡張する。 この~moduleは、 `~level 4$ を拡張する。 ◎ This module extends [CSS-VALUES-4] which replaces and extends the data type definitions in [CSS21] sections 1.4.2.1, 4.3, and A.2.

3.1. 関数-記法の定義

`~level 4$ の `§ 関数-記法の定義＠~CSSVAL#component-functions$ を見よ。 ◎ See CSS Values 4 § 2.6 Functional Notation Definitions.

random-item( `random-key$t, [`declaration-value$t?]# )

font-family: random-item(--x, serif, sans-serif, monospace);

font-family: random-item(--x, {Times, serif}, {Arial, sans-serif}, {Courier, monospace});

font-family: random-item(--x, {Times, serif}, sans-serif, {monospace});

background-image: linear-gradient(to left, {red}, magenta);

3.2. 真偽-式の複化子： `boolean-expr[]^t

いくつかの文脈（ `media$at, `supports$at, `if$f, ...など）は、［ 条件たちを指定して， それらを真偽-論理（ `and^v ／ `or^v ／ `not^v ／ ~group化）で組合せる ］ことを許容する。 それらは，同じ自明でない再帰的な構文~構造を利用するので、 特別な `boolean-expr[]@t 【！`boolean-expr@t】 生成規則が，この~patternを汎用~的に表現する。 ◎ Several contexts (such as @media, @supports, if(), ...) specify conditions, and allow combining those conditions with boolean logic (and/or/not/grouping). Because they use the same non-trivial recursive syntax structure, the special <boolean-expr> production represents this pattern generically.

`boolean-expr[]$t 記法は、 その中の角括弧~内に別の値~型 %型 を包装する （例： `boolean-expr[ <test> ]^t 【！`boolean[ <test> ]^t】）。 【言い換えれば、別の値~型（例： `test^t ）で~parameter化された型である。】 それは、 %型 を成す 1 個の値, あるいは 真偽-組合n — ~keyword［ `not^v【！＠~MQ5#valdef-media-not】／ `and^v ／ `or^v ］や［ ~group化するための丸括弧 ］を利用している組合n — 【を %型 を成す値たちに適用した結果】を表現する。 それは、 正式には，次と等価になる： ◎ The <boolean-expr[]> notation wraps another value type in the square brackets within it, e.g. <boolean[ <test> ]>, and represents that value type alone as well as boolean combinations using the not, and, and or keywords and grouping parenthesis. It is formally equivalent to:

`boolean-expr[ <test> ]^t
	= not `boolean-expr-group^t
	| `boolean-expr-group^t [ [ and `boolean-expr-group^t ]* | [ or `boolean-expr-group^t ]* ]

`boolean-expr-group^t
	= `test^t
	| ( `boolean-expr[ <test> ]^t )
	| `general-enclosed$t

`boolean-expr[]$t 生成規則は、［ `真^i ／ `偽^i ／ `未知^i ］値を表現する。 その値は、 ~Kleeneの 3-値~論理を利用して解決される — ただし，~top-levelの （すなわち，別の `boolean-expr[]$t を成す文法の内側に直に入子にされていない） `未知^i は、 他が指定されない限り， `偽^i に解決される。 詳細は `§ 真偽-論理＠#boolean-logic$を見よ。 ◎ The <boolean-expr[]> production represents a true, false, or unknown value. Its value is resolved using 3-value Kleene logic, with top-level unknown values (those not directly nested inside the grammar of another <boolean-expr[]>) resolving to false unless otherwise specified; see Appendix B: Boolean Logic for details.

`container-query^t
	= `boolean-expr[ <cq-test> ]^t
`cq-test^t
	= (`size-query^t)
	| style( `style-query^t )
	| scroll-state( `scroll-state-query^t )
`size-query^t
	= `boolean-expr[ ( <size-feature> ) ]^t
	| `size-feature^t
`style-query^t
	= `boolean-expr[ ( <style-feature> ) ]^t
	| `style-feature^t
`scroll-state-query^t
	= `boolean-expr[ ( <scroll-state-feature> ) ]^t
	| `scroll-state-feature^t

この論理を成す分岐 `general-enclosed$t は、 将来との互換性を許容する — 新たな式は、 それを~supportしない~UAにおいては，他が指定されない限り “未知なもの” として［ 構文解析される／見なされる ］ことになる — 当の式【！生成規則】を無効~化することなく。 そのような許容との一貫性を得るため、 `boolean-expr[]$t 内の `test^t 項は， `general-enclosed^t に合致する【にも合致する？】よう定義されるベキである。 ◎ The <general-enclosed> branch of the logic allows for future compatibility—unless otherwise specified new expressions in an older UA will be parsed and considered “unknown”, rather than invalidating the production. For consistency with that allowance, the <test> term in a <boolean-expr[]> should be defined to match <general-enclosed>.

3.3. ~CSSにおける~CSS構文の指定-法： `syntax^t 型

~CSSにおける一部の特能 — `attr$f 関数, `登録-済み~custom~prop$など — は、［ `別の^em値が，どう構文解析されるものと意味されるか ］を指定することを許容する。 これは、 `syntax$t 生成規則を介して宣言される。 それは、［ 仕様において~CSS特能を定義するために利用される，~CSSの`値~定義の構文$ ］を制限した形を真似る。 それは、 ある`構文~定義$を表現する： ◎ Some features in CSS, such as the attr() function or registered custom properties, allow you to specify how another value is meant to be parsed. This is declared via the <syntax> production, which resembles a limited form of the CSS value definition syntax used in specifications to define CSS features, and which represents a syntax definition:

`syntax@t
	= '*'
	| `syntax-component$t [ `syntax-combinator$t `syntax-component$t ]*
	| `syntax-string$t
`syntax-component@t
	= `syntax-single-component$t `syntax-multiplier$t?
	| '<' transform-list '>'
`syntax-single-component@t
	= '<' `syntax-type-name$t '>'
	| `ident$t
`syntax-type-name@t
	= angle
	| color
	| custom-ident
	| image
	| integer
	| length
	| length-percentage
	| number
	| percentage
	| resolution
	| string
	| time
	| url
	| transform-function
`syntax-combinator@t
	= '|'
`syntax-multiplier@t
	= [ '#' | '+' ]

`syntax-string@t
	= `string$t

`syntax-component$t 【を成す `syntax-single-component$t 】は、 次のいずれかからなる： ◎ A <syntax-component> consists of either＼

• `<^g, `>^g （山括弧）で括られた `syntax-type-name$t — `~supportされる構文~成分~名$のうち いずれかへ対応付けられる。 ◎ a <syntax-type-name> between <> (angle brackets), which maps to one of the supported syntax component names,＼
• `ident$t — 任意の`~keyword$を表現する。 ◎ or an <ident>, which represents any keyword.＼ ◎ ↓ Additionally, a <syntax-component> may contain a multiplier, which indicates a list of values.

注記： このことは、 `<length>^g と `length^g は、 2 つの異なる型を表すことを意味する： 前者は `length$t を述べる一方で、 後者は`~keyword$ `length^v を述べる。 ◎ Note: This means that <length> and length are two different types: the former describes a <length>, whereas the latter describes a keyword length.

`syntax-component$t は、 `複化子$を包含してもヨイ — それは、 成分~値たちが成す`~list$であることを指示する。 ◎ ↑

複数個の `syntax-component$t を `delim-token$t `|^g で`結合-＠~CSSPV1#combinator$してもヨイ — それは、 値に対し，各~構文~成分を指定した順序で照合させる。 ◎ Multiple <syntax-component>s may be combined with a | <delim-token>, causing the syntax components to be matched against a value in the specified order.

<percentage> | <number> | auto

red | <color>

`delim-token$t `*^g は、 `全称~構文~定義$を表現する。 ◎ The * <delim-token> represents the universal syntax definition.

値 `<transform-list>^v は、 `transform-list$t 生成規則に対応する — それは、 `transform-function$t+ に等価な便利~用の形である。 これは、 `syntax-multiplier$t が後続しなくともよいことに注意。 ◎ The <transform-list> production is a convenience form equivalent to <transform-function>+. Note that <transform-list> may not be followed by a <syntax-multiplier>.

次に挙げる箇所には、 `空白$は許容されない： ◎ Whitespace is not allowed＼

• `syntax-type-name$t とそれを括る山括弧 — `delim-token$t `<^g, `>^g — の合間 ◎ between the angle bracket <delim-token>s (< >) and the <syntax-type-name> they enclose,＼
• `syntax-multiplier$t の直前 ◎ nor is whitespace allowed to precede a <syntax-multiplier>.

注記： `空白$に対する制約は、 `<transform-list>^v にも適用される。 ◎ Note: The whitespace restrictions also apply to <transform-list>.

`syntax-string$t 値は、 `syntax$t の`文法に則って構文解析-$した結果が `失敗^i にならない `string$t であり，当の `syntax$t と同じ値を表現する。 ◎ A <syntax-string> is a <string> whose value successfully parses as a <syntax>, and represents the same value as that <syntax> would.

【 すなわち、 `string-token$t のうち，その .値 は［ `syntax$t を成す `syntax-string$t 以外の部分 ］に合致するもの。 】

注記： `syntax-string$t は、 ほぼ歴史的な目的で存在する — `syntax$t が定義される前は、 `property$at 規則が，この目的に `string$t を利用していた。 ◎ Note: <syntax-string> mostly exists for historical purposes; before <syntax> was defined, the @property rule used a <string> for this purpose.

4.1. 資源の所在指定子： `url$t 型

`~level 4$ の `§ 資源の所在指定子＠~CSSVAL#urls$ を見よ。 ◎ See CSS Values 4 § 4.5 Resource Locators: the <url> type.

`request-url-modifier$t
	= `cross-origin-modifier$t
	| `integrity-modifier$t
	| `referrer-policy-modifier$t

4.2. 二次元な位置決め： `position^t 型

`position@t 値は、 `整列~容器$（例：`背景~位置決め区画$）の内側における`整列~subject$（例：背景~画像）の位置を［ 指定された 2 辺 （既定では左端と上端）に対する~offset ］が成す~pairとして指定する。 その構文は： ◎ The <position> value specifies the position of an alignment subject (e.g. a background image) inside an alignment container (e.g. its background positioning area) as a pair of offsets between the specified edges (defaulting to the left and top). Its syntax is:

`position$t
	= `position-one$t
	| `position-two$t
	| `position-four$t
`position-one@t
	= left
	| center
	| right
	| top
	| bottom
	| x-start
	| x-end
	| y-start
	| y-end
	| block-start
	| block-end
	| inline-start
	| inline-end
	| `length-percentage$t
`position-two@t
	= [ left | center | right | x-start | x-end ] &&
	  [ top | center | bottom | y-start | y-end ]
	| [ left | center | right | x-start | x-end | `length-percentage$t ]
	  [ top | center | bottom | y-start | y-end | `length-percentage$t ]
	| [ block-start | center | block-end ] &&
	  [ inline-start | center | inline-end ]
	| [ start | center | end ]{2}
`position-four@t
	= [ [ left | right | x-start | x-end ] `length-percentage$t ] &&
	  [ [ top | bottom | y-start | y-end ] `length-percentage$t ]
	| [ [ block-start | block-end ] `length-percentage$t ] &&
	  [ [ inline-start | inline-end ] `length-percentage$t ]
	| [ [ start | end ] `length-percentage$t ]{2}

指定された成分~値の個数に応じて： ◎ ↓

• 1 個（ `position-one$t ） ⇒ 2 個目の値は `center$vP であると見做される。 ◎ If only one value is specified (<position-one>), the second value is assumed to be center.

• 2 個（ `position-two$t ）： ◎ If two values are given (<position-two>),＼

  • `length-percentage$t は、［ 1 個目／ 2 個目 ］の値としては［ 横／縦 ］位置を`整列~容器$の［ 左端／上端 ］辺から`整列~subject$の［ 左端／上端 ］辺までの~offsetとして表現する。 ◎ a <length-percentage> as the first value represents the horizontal position as the offset between the left edges of the alignment subject and alignment container,＼ and a <length-percentage> as the second value represents the vertical position as an offset between their top edges.
  • どちらの~keywordも［ `start^v ／ `end^v ］である場合、 順に，［ `塊-軸$, `行内-軸$ ］を表現する。 ◎ If both keywords are one of start or end, the first one represents the block axis and the second the inline axis.

  注記： 軸に特有な 2 個の~keywordが成す~pairは，並替えれる一方、 ~keywordと［ 長さ／百分率 ］の組合nは，そうでない。 なので、 `center left^v や `inline-start block-end^v は妥当であるが， `50% left^v は妥当でない。 ［ `start^v, `end^v ］は軸に特有でないので、［ `start end^v, `end start^v ］は異なる位置を表現する。 ◎ Note: A pair of axis-specific keywords can be reordered, while a combination of keyword and length or percentage cannot. So center left or inline-start block-end is valid, while 50% left is not. start and end aren’t axis-specific, so start end and end start represent two different positions.

• 4 個（ `position-four$t ） ⇒ 各 `length-percentage$t は、 その直前にある~keywordにより指定される辺に対する~offsetを表現する。 例えば【！background-position:】 `bottom 10px right 20px^v は、 【`整列~容器$の】［ 下端~辺から上への縦~offset `10px^v, 右端~辺から左への横~offset `20px^v ］を表現する。 ◎ If four values are given (<position-four>) then each <length-percentage> represents an offset between the edges specified by the preceding keyword. For example, background-position: bottom 10px right 20px represents a 10px vertical offset up from the bottom edge and a 20px horizontal offset leftward from the right edge.

いずれも、［ 正な値／負な値 ］は，`整列~容器$の辺から［ `内方^em／`外方^em ］への~offsetを表現する。 ◎ Positive values represent an offset inward from the edge of the alignment container. Negative values represent an offset outward from the edge of the alignment container.

background-position: left 10px top 15px;   /* 10px, 15px */
background-position: left      top     ;   /*  0px,  0px */
background-position:      10px     15px;   /* 10px, 15px */
background-position: left          15px;   /*  0px, 15px */
background-position:      10px top     ;   /* 10px,  0px */

background-position: right 3em bottom 10px

`position$t の`算出d値$は、 ( 横~offset, 縦~offset ) が成す~pair — 各~offsetは、 算出d `length-percentage$t 値【`算出d長さ$？】 — になる。 この［ 横~offset／縦~offset ］は、 `整列~容器$の［ 左端~辺／上端~辺 ］から`整列~subject$の［ 左端~辺／上端~辺 ］までの距離を表現する。 ◎ The computed value of a <position> is a pair of offsets (horizontal and vertical), each given as a computed <length-percentage> value, representing the distance between the left edges and top edges (respectively) of the alignment subject and alignment container.

`length-percentage$t

`length-percentage$t 値は、 `整列~容器$から`整列~subject$までの指定された辺に関する~offset【！の~size】を指定する。 ◎ A <length-percentage> value specifies the size of the offset between the specified edges of the alignment subject and alignment container.

例えば `background-position: 2cm 1cm$p は、 背景~画像の左上~隅を`背景~位置決め区画$の左上~隅から［ 右へ `2cm^v, 下へ `1cm^v ］の所に配置する。 ◎ For example, for background-position: 2cm 1cm, the top left corner of the background image is placed 2cm to the right and 1cm below the top left corner of the background positioning area.

［ 横~offset／縦~offset ］用の `percentage$t は、 `整列~容器$の［ 横幅／縦幅 ］から`整列~subject$の［ 横幅／縦幅 ］を減算した結果に相対的になる。 ◎ A <percentage> for the horizontal offset is relative to (width of alignment container - width of alignment subject). A <percentage> for the vertical offset is relative to (height of alignment container - height of alignment subject).

例えば： 値~pair `0% 0%^v に対しては、 `整列~subject$の左上~隅が，`整列~容器$の左上~隅に整列される。 値~pair `100% 100%^v に対しては、 `整列~subject$の右下~隅が，`整列~容器$の右下~隅に整列される。 値~pair `75% 50%^v に対しては、 `整列~subject$の左上~隅から［ 75% 右, 50% 下 ］を指す地点が，`整列~容器$の左上~隅から［ 75% 右, 50% 下 ］を指す地点に整列するよう配置される （下図）。 ◎ For example, with a value pair of 0% 0%, the upper left corner of the alignment subject is aligned with the upper left corner of the alignment container A value pair of 100% 100% places the lower right corner of the alignment subject in the lower right corner of the alignment container. With a value pair of 75% 50%, the point 75% across and 50% down the alignment subject is to be placed at the point 75% across and 50% down the alignment container.

`top@vP

`right@vP

`bottom@vP

`left@vP

対応する軸において， `整列~subject$の［ 上端／左端／右端／下端 ］辺（同順）を`整列~容器$の辺から指定された量（既定では `0%^v ）で~offsetする。 ◎ Offsets the top/left/right/bottom edges (respectively) of the alignment subject and alignment container by the specified amount (defaulting to 0%) in the corresponding axis.

`y-start@vP

`y-end@vP

`x-start@vP

`x-end@vP

順に，［ `縦~軸$における`始端$ ／ `縦~軸$における`終端$ ／ `横~軸$における`始端$ ／ `横~軸$における`終端$ ］側に対応する物理-辺~keywordと同じに算出される。 ◎ Computes the same as the physical edge keyword corresponding to the start/end side in the y/x axis.

`block-start@vP

`block-end@vP

`inline-start@vP

`inline-end@vP

順に，［ `塊-軸$における`始端$ ／ `塊-軸$における`終端$ ／ `行内-軸$における`始端$ ／ `行内-軸$における`終端$ ］側に対応する物理-辺~keywordと同じに算出される。 ◎ Computes the same as the physical edge keyword corresponding to the start/end side in the block/inline axis.

`center@vP

対応する軸における~offset `50%^v に算出される。 ◎ Computes to a 50% offset in the corresponding axis.

他が指定されない限り、 `~flow相対$な~keyword【が どの物理-辺~keywordに対応するか】は，それが指定された要素の`書字~mode$に則って解決される。 ◎ Unless otherwise specified, the flow-relative keywords are resolved according to the writing mode of the element on which the value is specified.

注記： `background-position$p ~propは，成分~値 3 個の構文も受容するが、 汎用~的には許容されない — ~prop値~内で他の［ 長さ／百分率 ］成分と組合されたとき，構文解析-時に多義性をもたらすので。 ◎ Note: The background-position property also accepts a three-value syntax. This has been disallowed generically because it creates parsing ambiguities when combined with other length or percentage components in a property value.

この構文が［ `background-position$p において，その`下位prop$たちへどう展開されるか ］を定義する必要がある — 例えば、 ある成分に `var$f が利用された場合に。 [`9690$issue] ◎ Need to define how this syntax would expand to the longhands of background-position if e.g. var() is used for some (or all) of the components. [Issue #9690]

6.1. 混合-百分率の正規化-法

混合-百分率の総和が 100% を超える場合、 それらは【総和が 100% になるよう均等に】縮小される。 100% 未満になる場合、 残りの百分率は［ `percentage$t が省略された値たちへ分配される ］か［ 当の特定の`混合-記法$により定義されるとおり， “~none型~値” へアテガわれる ］。 ◎ If the sum of the mix percentages are greater than 100%, they are scaled down; if it is less, any remaining percentage is distributed to values whose <percentage> is omitted, or else assigned to a “none” type value as defined by the specific mix notation.

6.2. 混合-記法の解決

妥当な`混合-記法$の： ◎ ↓

• `使用~値$は、 引数たちの加重平均になる — 当の特定の記法により指定されるとおりに。 ◎ The used value of a valid mix notation is the weighted average of its arguments, as specified by the specific notation.

• `算出d値$は：

  • 【算出d値の時点で】`使用~値$を計算できる場合、 `使用~値$と同じになる。
  • 他の場合、 各~引数が個別に算出された当の`混合-記法$になる。
  ◎ The computed value is the used value if it is possible to calculate. Otherwise, it is the mix notation itself, with its arguments computed individually.

6.3. 数量-値たち／次元-値たちの加重平均： `calc-mix^f 記法

`calc-mix@f `混合-記法$は、［ 数量-値たち／次元-値たち ］の加重平均を表現する。 【！Like `calc$f 】それは、 `~math関数$でもある。 その構文は： ◎ The calc-mix() mix notation represents a weighted average of numeric or dimensional value. Like calc(), it is a math function, with the following syntactic form:

`calc-mix()$t
	= calc-mix( [ `calc-sum$t `percentage[0,100]$t? ]# )

`calc-sum$t 引数たち %計算式たち を成す各~計算式は［ `number$t, `dimension$t, `percentage$t ］いずれにも解決され得るが、 %計算式たち が`一貫した型を有して$いない場合，当の関数は無効になる。 結果の`型$は、 次の結果になる ⇒ `型を入力と一貫させる$( `型を作成する$( %計算式たち を解決した結果の単位 ), %引数たち の`一貫した型$ ) ◎ The <calc-sum> arguments can resolve to any <number>, <dimension>, or <percentage>, but must have a consistent type or else the function is invalid. The result’s type will be the consistent type, made consistent with the type of the <calc-sum> values.

妥当な `calc-mix$f の： ◎ ↓

• `使用~値$は、 次の結果から加重平均を生産した結果になる ⇒ `混合-百分率たちを正規化する$( 指定された引数たち )

  各~itemの重みは、 正規化した結果における~itemの百分率により与えられる （ “残余” 混合-百分率は `一貫した型$を伴う 0 値に適用される — したがって，実質的に破棄される。）

  ◎ The used value of a valid calc-mix() is the result of producing a weighted average of its <calc-sum> values,＼ with the weight of each item given by its corresponding <percentage> after normalizing these mix percentages. (Any “leftover” mix percentage is applied to a consistently-typed zero value, and thus effectively discarded.)

• `算出d値$は： ◎ The computed value of a valid calc-mix() is＼

  • すべての［ `calc-sum$t 値, `percentage$t 値 ］を解決できるならば，`使用~値$と同じになる。 ◎ its used value if all of the <calc-sum> and <percentage> values in it can be resolved,＼
  • 他の場合、 各［ `calc-sum$t 値, `percentage$t 値 ］が個別に算出された `calc-mix()$f 記法になる。 ◎ and is a calc-mix() notation with each of its <calc-sum> and <percentage> values computed individually otherwise.

6.4. 変形~値たちの加重平均： `transform-mix^f 記法

`transform-mix@f `混合-記法$は、 `transform-list$t たちの加重平均を表現する。 その構文は： ◎ The transform-mix() mix notation represents a weighted average of <transform-list>, with the following syntactic form:

`transform-mix()$t
	= transform-mix( [ `transform-list$t && `percentage [0,100]$t ]# )

妥当な `transform-mix$f の： ◎ ↓

• `使用~値$は、 次の結果から加重平均を生産した結果になる ⇒ `混合-百分率たちを正規化する$( 指定された引数たち )

  各~itemの重みは、 正規化した結果における~itemの百分率により与えられる。 “残余” 混合-百分率は、 ~listに付加される`恒等~変形-関数$に適用される。 重み付けは、 正規化した結果を成す各~itemの値（各 `transform-list$t ）を補間することにより計算できる — 各~itemの重みを［ `恒等~変形-関数$から `transform-list$t へ向かう補間~進捗 ］として利用して。 `CSS-TRANSFORMS-1$r `§ 変形どうしの補間＠~TRANSFORM#interpolation-of-transforms$ を見よ。 ◎ The used value of a valid transform-mix() is the result of producing a weighted average of its <transform-list> values, with the weight of each item given by its corresponding <percentage> after normalizing these mix percentages. Any “leftover” mix percentage is applied to an identity transform appended to the list. The weighting can be calculated by interpolating each <transform-list> using its <percentage> weight as the interpolation progress from the identity transform towards the <transform-list>. See CSS Transforms 1 § 9 Interpolation of Transforms.

• `算出d値$は： ◎ ↑

  • 次が満たされるならば、 `使用~値$と同じになる ⇒ ［ すべての `percentage$t を全部的に解決できる ］~AND［ `transform-list$t たちを使用~値の時点の情報なしに補間できる ］ ◎ If every <percentage> weight can be fully resolved, and the <transform-list>s can be interpolated without used-value-time information, then the computed value is the used value;＼
  • 他の場合、 各［ `transform-list$t 値, `percentage$t 値 ］が個別に算出された `transform-mix$f 記法になる。 ◎ it is otherwise the transform-mix() notation itself with its arguments each computed according to their type.

`transform-mix$f 自体も `transform-function$t である。 【したがって，関数~内に入子にできることになる。】 ◎ transform-mix() is, itself, a <transform-function>.

7.1. `*-interpolate^f 族の構文

`補間~記法$の汎用な構文は： ◎ The generic syntax of the interpolation notations is as follows:

`*-interpolate()^t
	= *-interpolate(
		[
			`progress-source$t
			&& [ by `easing-function$t ]?
			&& `easing-function$t?
			&& `segment-options$t?
		] ,
		`input-position$t{1,2} : `output-value$t ,
		[
			[ `easing-function$t || `segment-options$t , ]?
			`input-position$t{1,2} : `output-value$t
		]#?
	)
◎
interpolate-function() = interpolate-function(
  [
    <progress-source> && [ by <easing-function> ]?
    && <easing-function>? && <segment-options>?
  ] ,
  <input-position>{1,2} : <output-value> ,
  [ [ <easing-function> || <segment-options> ]? , <input-position>{1,2} : <output-value> ]#?
)

【 `*-interpolate^v は、 個々の`補間~記法$の名前を表す。 】【 ［ `output-value$t, `segment-options$t ］の構文は、 個々の`補間~記法$に応じて変わる。 一部の補間~記法には、 `segment-options$t は無い（空である）。 】

これらは、 以下に述べるとおり， `補間~進捗$と`補間~map$を表現する。 ◎ These represent the interpolation progress and interpolation map as described below.

`progress-source$t
	= `percentage$t
	| `number$t
	| `dimension$t
	| `animation-timeline$tp

7.2. 検証と正規化

background-color: color-interpolate(300px in hsl, 200px: red, 500px: green, 600px: blue);

background-color: color-interpolate(25% in hsl, 0%: red, 75%: green, 100%: blue);

7.3. 補間~解決

妥当な`補間~記法$の： ◎ ↓

• `使用~値$は、 `補間~進捗$を指定された`補間~map$を通して対応付けた結果になる。 ◎ The used value of a valid interpolation notation is the result of mapping its interpolation progress through the specified interpolation map.

• `算出d値$は： ◎ The computed value is＼

  • 【算出d値の時点で】`使用~値$を計算できる場合、 `使用~値$と同じになる。 ◎ the used value if it is possible to calculate.＼
  • 他の場合、［ `補間~進捗$, `入力~位置$たち, 補間~option群 ］すべてを解決できるならば、 【当の進捗を挟む】 2 個の補間~停を伴う`補間~記法$へ単純~化される — それは、 当の［ `補間~進捗$, `入力~位置$たち ］用の `number$t 値たちを伴い， 他のすべての値は各自の型に則って算出される。 ◎ Otherwise, if its interpolation progress, input positions, and interpolation options can all be resolved, then it is simplified to a two-stop interpolation notation with <number> values for the interpolation progress and input positions, and all other values computed according to their type.＼
  • 他の場合、 各~引数が個別に算出された当の`補間~記法$になる。 ◎ Otherwise, it is the interpolation notation itself, with its arguments computed individually otherwise.

7.4. 補間された数量-値／次元-値： `calc-interpolate^f 記法

`calc-interpolate@f は、 補間された［ 数量-値／次元-値 ］を表現する`補間~記法$であり， 【！Like calc(),】`~math関数$でもある。 その構文は： ◎ The calc-interpolate() interpolation notation represents an interpolated numeric or dimensional value. Like calc(), it is a math function, with the following syntax:

`calc-interpolate()$t
	= calc-interpolate(
		[
			`progress-source$t
			&& [ by `easing-function$t ]?
			&& `easing-function$t
		] ,
		`input-position$t{1,2} : `calc-sum$t ,
		[
			`easing-function$t? ,
			`input-position$t{1,2} : `calc-sum$t
		]#?
	)

`calc-sum$t 引数たち %計算式たち を成す各~計算式は［ `number$t, `dimension$t, `percentage$t ］いずれにも解決され得るが、 %計算式たち が`一貫した型を有して$いない場合，当の関数は無効になる。 結果の`型$は、 当の`一貫した型$になる。 ◎ The <calc-sum> arguments can resolve to any <number>, <dimension>, or <percentage>, but must have a consistent type or else the function is invalid. The result’s type will be that consistent type.

［ `progress-source$t ／ `input-position$t ］値は、 継承される`計算~文脈$を利用しない — それらがとる百分率は、 `§ 検証と正規化＠#interpolation-normalization$ にて指定されるとおりに解決される。 ◎ The <progress-source> and <input-position> values do not use the inherited calculation context; they resolve percentages as specified in § 7.2 Validation and Normalization.

7.5. 補間された色~値： `color-interpolate^f 記法

`color-interpolate@f `補間~記法$は、 補間された `color$t 値を表現する。 その構文は： ◎ The color-interpolate() interpolation notation represents an interpolated <color> value, with the following syntax:

`color-interpolate()$t
	= color-interpolate(
		[
			`progress-source$t
			&& [ by `easing-function$t ]?
			&& `easing-function$t?
			&& `color-interpolation-method$t?
		],
		`input-position$t{1,2} : `color$t,
		[
			[ `easing-function$t || `color-interpolation-method$t ]?,
			`input-position$t{1,2} : `color$t
		]#?
	)

7.6. 補間された変形~値： `transform-interpolate^f 記法

`transform-interpolate@f `補間~記法$は、 ある補間された `transform-list$t を表現する。 その構文は： ◎ The transform-interpolate() interpolation notation represents an interpolated <transform-list>, with the following syntax:

`transform-interpolate()$t
	= transform-interpolate(
		[
			`progress-source$t
			&& [ by `easing-function$t ]?
			&& `easing-function$t?
		],
		`input-position$t{1,2} : `transform-list$t,
		[
			`easing-function$t?,
			`input-position$t{1,2} : `transform-list$t
		]#?
	)

`transform-interpolate$f 自体も `transform-function$t である。 ◎ transform-interpolate() is, itself, a <transform-function>.

7.7. 補間された~prop値： `interpolate^f 記法

`interpolate@f `補間~記法$は、 ~prop値~全体どうしの補間を表現する — それは、 2 つの代替な構文【！~pattern】を~supportする： ◎ The interpolate() interpolation notation represents the interpolation of entire property values, which supports two alternative syntax patterns:

`interpolate()$t
	= interpolate(
		[
			`progress-source$t
			&& [ by `easing-function$t ]?
			&& `easing-function$t?
		],
		`input-position$t{1,2} : `whole-value$t,
		[
			`easing-function$t? ,
			`input-position$t{1,2} : `whole-value$t
		]#?
	)
	| interpolate(
		`progress-source$t
		&& [ by `easing-function$t ]?
		&& `easing-function$t? of `keyframes-name$t
	)

1 個目の構文~代替は、 他の`補間~記法$と同様に，`補間~停$たちが成す~listから`補間~map$を組立てる。 ◎ The first syntax alternative, like other interpolation notations, assembles an interpolation map from a list of interpolation stops.＼

2 個目の構文~代替は、 ~keyframeたちが成す集合~FN1 から対応している~prop宣言~FN2 たちを利用して，それらの値を この【構文を利用した】~prop用の通常の`~cascade$の中へ組入れる。 ◎ The second uses the corresponding property declarations from a set of keyframes, incorporating those values into the normal cascade for this property.

【~FN1 `keyframes-name$t で識別される `keyframes$at 規則を成す`~keyframe~style規則$たちを指すと思われる。 】【~FN2 この関数を値に利用している~propと同じ名前を伴う~prop宣言を指すと思われる。 】

各 `whole-value$t 引数は、 それが，この【構文を利用した】~propの値であったかのように算出される。 他の引数は、 各自の型に則って算出される。 ◎ Each <whole-value> argument is computed as if it were the value of this property; and all other arguments computed according to their type.

color: interpolate(90%, 0: red, 1: blue);
/* 
は、
単純な補間を介して，次に算出される：
◎
via simple interpolation, computes to:
 */
color: rgb(10% 0 90%);

color: interpolate(90%, 0: currentcolor, 1: black);
/* 
は、
算出d値の時点では全部的に解決できない
— それでも，定義された表現がある：
◎
can't be fully resolved at computed-value time, but still has a defined representation:
 */
color: color-mix(currentcolor 90%, black 10%);

float: interpolate(90%, 0: left, 1: right);
/* 
は、
離散的に~animate可能である：
◎
discretely animatable
 */
float: right;

`interpolate$f 記法は、 `whole-value$t である。 加えて、 いずれかの `whole-value$t 引数が`~animate不可$である場合， 当の記法は無効になる。 ◎ The interpolate() notation is a <whole-value>. Additionally, if any of its <whole-value> arguments are not animatable, the notation is invalid.

/* 
始端~値が妥当でない
◎
Invalid start value
 */
color: interpolate(90%, 0: #invalid, 1: #F00);

/* 
関数が~propの値~全体を成していない
◎
Function is mixed with other values
 */
background: url(/sitelet?url=https%3A%2F%2Ftriple-underscore.github.io%2Focean) interpolate(10%, 0: blue, 1: yellow);

/* 
`animation-*^p は~animate可能でない
◎
'animation-*' is not animatable
 */
animation-delay: interpolate(0%, 0: 0s, 1: 2s);

8.1. ~prop値~全体の表現-法： `whole-value^t 型

この仕様が定義するいくつかの関数は、 所与の~propの “値~全体を成す” 場合にしか利用できない。 例えば、 `background-position:cycle(50px 50px, center)$p は妥当であるが， `background-position:cycle(50px, center) 50px^p は妥当でない。 `whole-value$t 生成規則は、 そのような値を表現する。 ◎ Several functions defined in this specification can only be used as the "whole value" of a property. For example, background-position: cycle(50px 50px, center); is valid, but background-position: cycle(50px, center) 50px; is not. The <whole-value> production represents these values.

すべての~propは、 その値~全体として `whole-value$t を暗黙的に受容する — `~CSS全域~keyword$を値~全体として受容するのと同じく。 ◎ All properties implicitly accept a <whole-value> as their entire value, just as they accept the CSS-wide keywords as their entire value.

`whole-value$t が，ある関数の成分~値【引数】として利用されたときも、［ 当の関数を利用した~propの値~全体を成すものとして，通常は妥当になる~CSS値 ］を表現する （追加的な `whole-value$t 関数 【当の関数の引数として利用された関数のうち `whole-value$t を引数に含むもの？】 も含めて）。 しかしながら、 関数によっては，［ `whole-value$t 引数が含み得るもの ］は制約され得る。 ◎ When used as a component value of a function, <whole-value> also represents any CSS value normally valid as the whole value of the property in which it is used (including additional <whole-value> functions). However, some functions may restrict what a <whole-value> argument can include.

8.2. ~supportされる最初の値の選定-法： `first-valid^f 記法

~CSSは、 前方-互換な構文解析により漸進的な増補を~supportする。 作者は，~style規則~内で同じ~propを複数回 — 各~回に異なる値を利用しながら — 宣言でき、 ~CSS~UAは， それらのうち自身が解する最後のものを自動的に利用して，それ以外を棄てる。 この原則は、 `supports$at 規則との~~併用により，［ 新旧どちらの~UAでも きちんと働く~stylesheetを書く ］ことを作者に許容する。 ◎ CSS supports progressive enhancement with its forward-compatible parsing: authors can declare the same property multiple times in a style rule, using different values each time, and a CSS UA will automatically use the last one that it understands and throw out the rest. This principle, together with the @supports rule, allows authors to write stylesheets that work well in old and new UAs simultaneously.

しかしながら、 `var$f 関数（あるいは、構文解析した後に解決される類似な代入~関数【`任意-代入~関数$】）の利用は， この機能性を~~妨げる — それらを利用する【！such】どの~propも，構文解析-時点では妥当と見做すことが要求されるので。 ◎ However, using var() (or similar substitution functions that resolve after parsing) thwarts this functionality; CSS UAs must assume any such property is valid at parse-time.

`first-valid@f `関数-記法$は、 ~fallback用の挙動を宣言の中に — その構文解析に内在的になるよう — ~inline化する。 ほとんどの記法と違って、 その各~引数は，妥当な構文も妥当でない構文も受容する — それは、 各~引数のうち，次を満たす最初のものを表現する ⇒ この記法を利用した~propの値~全体を成していたとするとき， ~UAにより~supportされる （妥当な値として構文解析される） ◎ The first-valid() functional notation inlines the fallback behavior intrinsic to parsing declarations. Unlike most notations, it can accept any valid or invalid syntax in its arguments, and represents the first value among its arguments that is supported (parsed as valid) by the UA as the whole value of the property it’s used in.

`first-valid()$t
	= first-valid( `declaration-value$t# )

どの引数も当の~prop用の妥当な値を表現しない場合、 当の~propは，`算出d値の時点で無効$になる。 ◎ If none of the arguments represent a valid value for the property, the property is invalid at computed-value time.

`first-valid$f は `whole-value$t である。 ◎ first-valid() is a <whole-value>.

これは異なる名前にするべきか？ — この関数を追加するものと解決されるまで， 【どう命名するか】裁定し切れなかった。 ◎ Should this have a different name? We didn’t quite decide on it during the resolution to add this.

注記： `first-valid$f が［ その引数として実質的には `whole-value$t をとるにもかかわらず， `declaration-value$t をとる ］ものと定義されるのは、 定義により，［ `その値は、それをとる宣言~用には妥当でないかもしれない^em ］事例で利用されることが意図されるので。 `declaration-value$t は、 それが合致するものに対し — `whole-value$t と違って — 文脈に応じた妥当性の拘束を何も課さない。 ◎ Note: Despite effectively taking <whole-value>s as its argument, first-valid() is instead defined to take <declaration-value>s because, by definition, it’s intended to be used in cases where its values might be invalid for the declaration it’s in. <declaration-value> imposes no contextual validity constraints on what it matches, unlike <whole-value>.

8.3. 条件付きな値の選定： `if^f 記法

`if@f 関数は、 条件付きな値たちを表現する`任意-代入~関数$である。 それは、［ ~semicolonで分離された言明たちが成す【！有順序な】~list ］を引数にとる。 各~言明は、 順に［ 条件, 1 個の~colon, 値 ］からなる。 `if$f 関数は、 引数~listを成す条件のうち `真^i に評価されるものは［ 在るならば，それらのうち最初のものに対応する値／ 無いならば，空な~token~stream ］を表現する。 ◎ The if() function is an arbitrary substitution function that represents conditional values. Its argument consists of an ordered semi-colon–separated list of statements, each consisting of a condition followed by a colon followed by a value. An if() function represents the value corresponding to the first condition in its argument list to be true; if no condition matches, then the if() function represents an empty token stream.

`if$f 関数の構文は： ◎ The if() function’s syntax is defined as follows:

`if()$t
	= if( [ `if-branch$t ; ]* `if-branch$t ;? )
`if-branch@t
	= `if-condition$t : `declaration-value$t?
`if-condition@t
	= `boolean-expr[ <if-test> ]$t
	| `else$v
`if-test@t
	= supports( [ `ident$t : `declaration-value$t ] | `supports-condition$t )
	| media( `media-feature$t | `media-condition$t )
	| style( `style-query$t )

~keyword `else@v は、 常に `真^i に評価される条件を表現する。 ◎ The else keyword represents a condition that is always true.

`if$f 関数の`引数~文法$は： ◎ The if() function’s argument grammar is:

`if-args@t
	= if( [ `if-args-branch$t ; ]* `if-args-branch$t ;? )
`if-args-branch@t
	= `declaration-value$t : `declaration-value$t?

`if-args-branch$t 生成規則を成す 1 個目の `declaration-value$t においては、 その`自由~形な生成規則$に対する制約の一部として， ~top-levelの `colon-token$t も除外される （~commaや波括弧の他にも）。 ◎ In the above <if-args-branch> production, the first <declaration-value> excludes top-level <colon-token>s as part of its free-form production restrictions (alongside commas and curly braces).

注記： ［ `media$at ／ `supports$at ／ `container$at ］規則は，その条件が `偽^i に評価されたときには［ その内容は無視されるだけになり， 値として何を適用するかを~cascadeに決定させる ］が、 それとは違って， `if$f を伴う宣言は、 条件が `偽^i に評価されても，~cascadeは巻戻されない — ~fallback値は、 【必要なら， `if$f の他に】 ~inlineに供する必要がある【！must】。 しかしながら、 `~CSS全域~keyword$ `revert-rule$v を見よ。 ◎ Note: Unlike using @media/@supports/@container rules, which just ignore their contents when they’re false and let the cascade determine what values otherwise apply, declarations with if() do not roll back the cascade if the conditions are false; any fallback values must be provided inline. However, see the revert-rule CSS-wide keyword.

8.4. 一連の値の~toggle法： `cycle^f 記法

`cycle@f 式は、 子孫~要素たちが — 同じ値を継承する代わりに — ~listを成す各~値を巡回することを許容する。 ◎ The cycle() expression allows descendant elements to cycle over a list of values instead of inheriting the same value.

em { font-style: cycle(italic, normal); }

ul { list-style-type: cycle(disc, circle, square, box); }

`cycle$f 式の構文は： ◎ The syntax of the cycle() expression is:

`cycle()$t
	= cycle( `whole-value$t# )

`cycle$f 記法は、 `whole-value$t である。 しかしながら、 入子にできないことに加え，［ `attr$f ／ `calc$f ］記法も包含できない — そのような構成子を包含している宣言は無効になる。 ◎ The cycle() notation is a <whole-value>. However, it is not allowed to be nested, nor may it contain attr() or calc() notations; declarations containing such constructs are invalid.

background-position: 10px cycle(50px, 100px);
/* 
`cycle$f は~propの値~全体を成していなければナラナイ。
◎
cycle() must be the sole value of the property
 */

list-style-type: cycle(disc, 50px);
/* 
`50px^v は `list-style-type$p 用の妥当な値でない。
◎
''50px'' isn't a valid value of 'list-style-type'
 */

注記： したがって， `cycle$f 内で同じ値が繰返された場合、 ~listは短絡されることになる。 例えば， `cycle(1em, 2em, 1em, 4em)^v は、 `cycle(1em, 2em)^v と等価になる。 ◎ Note: This means that repeating values in a cycle() short-circuits the list. For example cycle(1em, 2em, 1em, 4em) will be equivalent to cycle(1em, 2em).

注記： `cycle$f は，明示的に親の算出d値を調べるので、 継承されない~propであっても働く。 このことは、 継承されない~propに対しても働く `inherit$v ~keywordと類似する。 ◎ Note: That cycle() explicitly looks at the computed value of the parent, so it works even on non-inherited properties. This is similar to the inherit keyword, which works even on non-inherited properties.

注記： ~propの`算出d値$は、 抽象的な［ 値たちが成す集合 ］であり，特定0の直列化ではない `CSS21$r ので、 算出d値どうしの比較は常に一義的になり， 期待される結果になるべきである。 例えば， `CSS21$r における `background-position$p の算出d値は、 各自が［ 絶対~長さ／百分率 ］として表現される 2 個の~offsetだけからなるので、［ 宣言 `background-position^p: `top center^v ］と［ 宣言 `background-position^p: `50% 0%^v ］が生産する算出d値は，一致する。 ~prop定義の “算出d値” の欄が何かを［ 多義的／厳密~過ぎ ］に定義すると見受けられる場合は、 修正できるよう`~feedback＠#sotd$を供されたし。 ◎ Note: The computed value of a property is an abstract set of values, not a particular serialization [CSS21], so comparison between computed values should always be unambiguous and have the expected result. For example, a Level 2 background-position computed value is just two offsets, each represented as an absolute length or a percentage, so the declarations background-position: top center and background-position: 50% 0% produce identical computed values. If the "Computed Value" line of a property definition seems to define something ambiguous or overly strict, please provide feedback so we can fix it.

`cycle$f が`略式~prop$に利用された場合、 その各`下位prop$の値も `cycle$f 値になるが、 その各~引数は，元の `cycle$f 式の各~引数に対し［ それが当の略式~propの値~全体を成していたとするとき，下位propが受取ることになる値 ］に設定される。 ◎ If cycle() is used on a shorthand property, it sets each of its longhands to a cycle() value with arguments corresponding to what the longhand would have received had each of the original cycle() arguments been the sole value of the shorthand.

margin: cycle(1px 2px, 4px, 1px 5px 4px);

margin-top:    cycle(1px, 4px, 1px);
margin-right:  cycle(2px, 4px, 5px);
margin-bottom: cycle(1px, 4px, 4px);
margin-left:   cycle(2px, 4px, 5px);

margin-top:    cycle(1px, 4px);
margin-right:  cycle(2px, 4px, 5px);
margin-bottom: cycle(1px, 4px);
margin-left:   cycle(2px, 4px, 5px);

8.5. ~custom~prop 参照： `var^f 記法

`var$f 記法は、 `~custom~prop$の値が`代入-$される — `CSS-VARIABLES-1$r `§ ~cascade変数の利用-法＠~CSSVAR#using-variables$を見よ。 ◎ The var() notation substitutes the value of a custom property, see the CSS Custom Properties for Cascading Variables Module. [CSS-VARIABLES]

8.6. 継承d値~参照： `inherit^f 記法

`inherit@f `関数-記法$は、 `inherit$v ~keywordと同様に，親の~prop — 1 個目の引数に指定された名前を伴う~prop — の`算出d値$を表現している［ `成分~値$たちが成す連列 ］に解決される — 算出d値そのものではなく。 2 個目の引数は、 在るならば，［ 1 個目の引数が【`代入-$時に】`無効が保証される値$に解決される事例 ］で~fallbackとして利用される。 ◎ Like the inherit keyword, the inherit() functional notation resolves to the computed value of a property on the parent. Rather than resolving to the value of the same property, however, it resolves to a sequence of component values representing the computed value of the property specified as its first argument. Its second argument, if present, is used as a fallback in case the first argument resolves to the guaranteed-invalid value.

`inherit$f は`任意-代入~関数$である。 その構文は： ◎ inherit() is an arbitrary substitution function whose syntax is defined as:

`inherit()$t
	= inherit( `custom-property-name$t, `declaration-value$t? )

`inherit$f 関数の`引数~文法$は： ◎ The inherit() function’s argument grammar is:

`inherit-args@t
	= inherit( `declaration-value$t, `declaration-value$t? )

`var$f と同様に， 何も後続しない~commaを利用できる — それは、 2 個目の `declaration-value$t として空な連列が渡されたことを指示する。 ◎ Like var(), a bare comma can be used with nothing following it, indicating that the second <declaration-value> was passed, just as an empty sequence.

注記： すなわち ⇒＃ `inherit(--foo)^v は~fallback値を渡さない。 `inherit(--foo,)^v は~fallbackとして空な値を渡す。 ◎ Note: That is, inherit(--foo) does not pass a fallback value, but inherit(--foo,) does (the fallback is just empty).

注記： 将来の~levelでは、［ `inherit$f に標準な~CSS~propを指定する ］ことも許容し得る。 しかしながら，それらの~propには［ `算出d値$の~token化が標準~化されていないもの ］もあるので、 その特能は，この~level 5 から先送りされる。 `算出d値$は、 `使用~値$とは相違することに注意 — それは、 `getComputedStyle()$c が返す`解決d値$になるとは限らない。 したがって， `inherit(width)^v が許容されたとしても、 `length$t （ `width$p の使用~値）を返すとは限らない — `width^p を指定する先祖が無いならば， ~keyword `~autoS$v （ `width^p の初期~値）を返すことになる。 ◎ Note: Future levels of CSS may allow specifying standard CSS properties in inherit(); however because the tokenization of computed values is not fully standardized for all CSS properties, this feature is deferred from Level 5. Note that the computed value differs from the used value, and is not always the resolved value returned by getComputedStyle(); thus even if inherit(width) were allowed, it would frequently return the keyword auto, not the used <length>.

8.7. 属性~参照： `attr^f 記法

`attr@f 関数は、［ それを利用している~propが適用される`要素$の ある`属性$ ］を参照し，当の`属性$の値が`代入-$される （ `var$f 関数に`~custom~prop$の値が代入されるのと類似に）。 ◎ The attr() function substitutes the value of an attribute on an element into a property, similar to how the var() function substitutes a custom property value into a function.

`attr()$t
	= attr( `attr-name$t `attr-type$t? , `declaration-value$t? )
`attr-name@t
	= [ `ident-token$t? '|' ]? `ident-token$t
`attr-type@t
	= `type()$t
	| `raw-string$v
	| `number$v
	| `attr-unit$t
`attr-unit@t
	= `custom-ident$t
	| '%'
`type()@t
	= type( `syntax$t )

【 `attr-unit$t の文法における `%^v は、 この訳による追加。 原文は、 `%^v も `custom-ident$t に合致するかのように記されているが，誤りであろう。 】

`attr$f 関数の`引数~文法$は： ◎ The attr() function’s argument grammar is:

`attr-args@t
	= attr( `declaration-value$t, `declaration-value$t? )

`var$f と同様に， 何も後続しない~commaを利用できる — それは、 2 個目の `declaration-value$t として空な連列が渡されたことを指示する。 ◎ Like var(), a bare comma can be used with nothing following it, indicating that the second <declaration-value> was passed, just as an empty sequence.

注記： すなわち ⇒＃ `attr(--foo)^v は~fallback値を渡さない。 `attr(--foo,)^v は~fallbackとして空な値を渡す。 ◎ Note: That is, attr(foo) does not pass a fallback value, but attr(foo,) does (the fallback is just empty).

`attr-unit$t は、 次に挙げるいずれかを表現することが意図される： ◎ <attr-unit> is intended to represents＼

• 次を満たす`~CSS識別子$ ⇒ ある~CSS次元~単位の名前（例： `px$u ）に`~ASCII大小無視$で合致する ◎ an identifier that is an ASCII case-insensitive match for the name of a CSS dimension unit, such as px,＼
• 次を満たす `delim-token$t ⇒ `%^v を .値にとる ◎ or the <delim-token> %.＼

単位たちが成す集合は，時と伴に拡がり続けるので、 実際には， `custom-ident$t として指定される — 既知な単位に合致しないときは、 （当の関数~無効にすることなく）~fallbackの挙動が誘発される。 ◎ As this set expands regularly, it is actually specified as a <custom-ident>, and triggers fallback behavior when it doesn’t match a known unit (rather than making the function invalid).

`attr$f を成す各~引数は： ◎ The arguments of attr() are:

`attr-name$t

参照している属性の名前を与える — それは、 `wq-name$t `SELECTORS-3$r に類似するが、 それを成す最初の成分【名前空間~接頭辞】は，~wildcard【任意の名前空間を表現する `*^v 】をとり得ない。 ◎ Gives the name of the attribute being referenced, similar to <wq-name> (from [SELECTORS-3]) but without the possibility of a wildcard prefix.

名前空間が指定されなかった場合 （ `attr(foo)^v の様に，識別子だけが与えられた場合） ~NULL名前空間が含意される。 （名前空間を伴う属性は稀なので、 通例的には，これが欲されるものになる。 特に、［ ~HTML／~SVG ］には，名前空間を伴う属性は無い。） ◎ If no namespace is specified (just an identifier is given, like attr(foo)), the null namespace is implied. (This is usually what’s desired, as namespaced attributes are rare. In particular, HTML and SVG do not contain namespaced attributes.)＼

他が指定されない限り、 `attr-name$t が文字大小区別か否かや, それに対する照合~規則 は，`属性~選択子$に対するときと一致する （したがって、 ~host言語に依存するかもしれない）。 ◎ Unless otherwise specified, the case-sensitivity/matching rules of <attr-name> are identical to attribute selectors (and thus might depend on the host language).

`attr-name$t を成す各~成分の合間【すなわち `|^v の前後】には、 空白は許容されない。 ◎ Whitespace is not allowed between any of the components of <attr-name>.

ある［ 要素／`疑似要素$ ］に適用される~propにて利用された `attr$f は、［ 当の要素／当の疑似要素の`最終的な出自の要素$【！`出自の要素$】 ］の［ 所与の名前を伴う属性 ］を参照する。 ◎ If attr() is used in a property applied to an element, it references the attribute of the given name on that element; if applied to a pseudo-element, the attribute is looked up on the pseudo-element’s originating element.

`attr-type$t

当の属性の値を［ この引数に与えた`文法に則って構文解析-$する ］よう指定する。 ◎ Specifies how the attribute value is parsed into a CSS value.

`type$f 関数として与えられた場合、 当の属性の値【！the value】は，その `syntax$t 引数に則って構文解析され、 結果の~token列が代入される。 この目的においては、 `<url>^v は， `syntax-single-component$t として妥当でない。 構文解析に失敗した場合、 ~fallbackが誘発される。 ◎ If given as a type() function, the value is parsed according to the <syntax> argument, and substitutes as the resulting tokens. For this purpose, <url> is invalid as a <syntax-single-component>. Values that fail to parse according to the syntax trigger fallback.

注記： `<url>^v が禁じられるのは、 ~securityの懸念に因り，~URLには `attr$f を利用できないからである — 今の所は。 ◎ Note: <url> is banned because, for now, attr() values can’t be used in URLs at all due to security concerns.

`number@v ~keywordとして与えられた場合、 当の属性の値【！~literal値】は， `前後の~ASCII空白~列を剥いだ＠~INFRA#strip-leading-and-trailing-ascii-whitespace$後に `number-token$t の`文法に則って構文解析-$される。 構文解析に失敗した場合、 ~fallbackが誘発される。 ◎ If given as the number keyword, it causes the attribute’s literal value, after stripping leading and trailing whitespace, to be parsed as a <number-token>. Values that fail to parse trigger fallback.

`attr-unit$t 値として与えられた場合、 当の属性の値【！the value】は， まず `number^v ~keywordが指定された場合と同じく `number$t として構文解析される — それに失敗した場合、 ~fallbackが誘発される。 結果の実数は、 `attr-unit$t 値が［ `%^v ならば 百分率／ 既知な~CSS単位~名に合致するならば その単位を伴う次元 ］へ転換され， 他の場合は~fallbackが誘発される。 ◎ If given as an <attr-unit> value, the value is first parsed as if number keyword was specified; if this fails to parse, it triggers fallback. Then, if the <attr-unit> value matches a known CSS unit name or is %, the number is turned into a dimension or percentage with that value and the given unit. If the <attr-unit> does not match a known CSS unit, it triggers fallback.

［ `raw-string@v ~keywordとして与えられた／ 省略された ］場合、 当の属性の値は，そのまま~CSS文字列として扱われるようになる — ~CSS構文解析は（［ ~CSS~escape, 空白, ~comment, 等々 ］の除去も含めて），まったく遂行されずに。 ~fallbackが誘発されるのは、 当の属性が欠落ったときに限られる。 ◎ If given as the raw-string keyword, or omitted entirely, it causes the attribute’s literal value to be treated as the value of a CSS string, with no CSS parsing performed at all (including CSS escapes, whitespace removal, comments, etc). No value triggers fallback; only the lack of the attribute entirely does.

注記： これは、 構文に `type(*)^v を指定することとは異なる。 `type(*)^v は、 ~CSS構文解析を誘発して （それは、 当の値が妥当に構文解析されることを超える要件を何も課さないが）， その結果を［ `string$t 値ではなく，~token列 ］として直に代入する。 ◎ Note: This is different from specifying a syntax of type(*), which still triggers CSS parsing (but with no requirements placed on it beyond that it parse validly), and which substitutes the result of that parsing directly as tokens, rather than as a <string> value.

`declaration-value$t

~fallback値を指定する — ［ 当の属性が欠落った場合／ 当の属性の値を指定された型として構文解析することに失敗した場合 ］、 当の`attr$f には，この~fallback値が代入されることになる。 ◎ Specifies a fallback value for the attr(), which will be substituted instead of the attribute’s value if the attribute is missing or fails to parse as the specified type.

省略された場合の既定の~fallback値は、［ `attr-type$t 引数が省略された場合~FN は 空~文字列／ ~ELSE_ `無効が保証される値$ ］になる。

【~FN 前項と違って， `attr-type^t に `raw-string$v が指定された場合とは挙動が異なることになる （本当か？）。 】

◎ If the <attr-type> argument is omitted, the fallback defaults to the empty string if omitted; otherwise, it defaults to the guaranteed-invalid value if omitted.

~propが包含している各 `attr$f 関数が，どれも構文上は妥当な場合、 ~prop全体の文法は，構文解析-時点では妥当であると見做すモノトスル。 構文は、 `attr^f 関数に`代入-$された後の算出d値の時点に限り，検査される。 ◎ If a property contains one or more attr() 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-value time, after attr() functions have been substituted.

8.8. `custom-ident^t 値の構築-法： `ident^f 関数

`ident@f 関数は、1 個以上の別々な［ `~ident$／文字列／整数 ］から築かれる任意な `ident$t を表現する。 それは、 `任意-代入~関数$である。 ◎ The ident() function represents an arbitrary <ident>, built from one or more separate idents, strings, and integers. It is an arbitrary substitution function.

`ident()@t
	= ident( `ident-arg$t+ )
`ident-arg@t
	= `string$t
	| `integer$t
	| `ident$t

`ident$f 関数の`引数~文法$は： ◎ The ident() function’s argument grammar is:

`ident-args@t
	= ident( `declaration-value$t )

`ident$f は、 `~CSS識別子$が期待される所なら どこでも利用できるが，［ `custom-ident$t ／ `dashed-ident$t ］値を構築するときに最も有用になる。 ◎ ident() can be used anywhere that an identifier is expected, but it’s most useful to construct <custom-ident> or <dashed-ident> values.

.item {
  /* vtl-1, vtl-2, vtl-3, … */
  view-timeline-name: ident("vtl-" sibling-index());
}

.card[id] {
  /* 
例： `card1^v, `card2^v, `card3^v, … 
◎
E.g. card1, card2, card3, … 
 */
  --id: attr(id);

  view-transition-name: ident(var(--id));
  view-transition-class: card;

  h1 {
    /* 
例： `card1-title^v, `card2-title^v, `card3-title^v, … 
◎
E.g. card1-title, card2-title, card3-title, …
 */
    view-transition-name: ident(var(--id) "-title");
    view-transition-class: card-title;
  }
}

.element {
  anchor-name: ident(-- attr(id));
}

9.1. ~randomな数量-値の生成-法： `random^f 関数

`random@f 関数は、 `~math関数$であり， ある範囲内で一様に分布する~randomな値を表現する~FN。 それはまた、 任意選択で，アリな値を［ 最小~値からの差が，ある段差の整数倍になる ］よう制限できる。 その構文は： ◎ The random() function is a math function that represents a random value between a minimum and maximum value, drawn from a uniform distribution, optionally limiting the possible values to a step between those limits:

【~FN 以下、 この節に現れる~randomは， 常に一様に分布する（すべての値は、同じ~~確率で選ばれる）ものと見做される。 】

`random()^t
	= random(
		`random-key$t?,
		`calc-sum$t,
		`calc-sum$t,
		`calc-sum$t? )

.box {
  width: random(???, 100px, 200px);
  height: random(???, 100px, 200px);
  border: thin solid;
}

この関数が どう評価されるかについての詳細は、［ `§ ~random値の評価-法$, `§ ~random値の共有-／非~共有-法$ ］を見よ。 ◎ See § 9.3 Evaluating Random Values and § 9.4 Sharing (Or Not) Random Values: the <random-key> value for details on how the function is evaluated.＼

各~引数は、 順に： ◎ Its arguments are:

`random-key$t

文書~内の`~random関数$のうち［ どれとどれが同じ`~random基底~値$を共有し， どれが別個な`~random基底~値$を取得することになるか ］を制御する。 ◎ The optional <random-key> controls which random functions in the document will share a random base value and which will get distinct values.＼

省略可能であり、 省略された場合は `auto$v として挙動する。 ◎ If <random-key> is omitted, it behaves as auto.

この値を成す全部的な詳細は、 `§ ~random値の共有-／非~共有-法$ を見よ。 ◎ See § 9.4 Sharing (Or Not) Random Values: the <random-key> value for a full description of this value.

`calc-sum$t, `calc-sum^t

これらの引数（`計算式$）は、 順に，当の関数を解決した結果がとり得る範囲の［ 最小~値, 最大~値 ］を指定する。 ◎ The two required calculations specify the minimum and maximum value the function can resolve to. Both limits are inclusive (the result can be the min or the max).

［ 最大~値 ~LTE 最小~値 ］の場合、 最大~値は最小~値と等しいものとして挙動する。 【この場合、結果は最小~値に限られ，~randomにならなくなる。】 ◎ If the maximum value is less than the minimum value, it behaves as if it’s equal to the minimum value.

例えば， `random(100px, 300px)^v は、 `100px^v 以上 `300px^v 以下の~randomな `length$t に解決されることになる。 ◎ For example, random(100px, 300px) will resolve to a random <length> between 100px and 300px: it might be 100px, 300px, or any value between them like 234.5px.

`calc-sum$t

省略可能な最後の引数は、 段差~値を指定する。 指定された場合 ⇒ 当の関数を解決した結果は、 最小~値からの差が段差の整数倍になるよう制約され， そこから~randomに選ばれる。 【省略された場合、そのように制約されない。】 ◎ The final optional argument specifies a step value: the values the function can resolve to are further restricted to the form min + (N * step), where N is a non-negative integer chosen uniformly randomly from the possible values that result in an in-range value.

例えば、 `random(100px, 300px, 50px)^v を解決した結果は，［ `100px^v, `150px^v, `200px^v, `250px^v, `300px^v ］いずれかに限られ、 `120px^v 様な値を返すことは決してない。 ◎ For example, random(100px, 300px, 50px) can only resolve to 100px, 150px, 200px, 250px, or 300px; it will never return a value like 120px.

最大~値は、 実際にアリな値として~~現れないこともあることに注意。 例えば， `random(100px, 200px, 30px)^v におけるアリな値は ⇒ `100px^v, `130px^v, `160px^v, `190px^v ◎ Note that the max value might not actually show up as a possible value; for example, in random(100px, 200px, 30px), the possible values are 100px, 130px, 160px, and 190px.

注記： 最小から最大までが正確に段差の整数~倍になるよう意図されたとしても、 数量-精度の課題により，そうならくなることもある。 これらの課題を避けるため、 結果が［ アリな最~大な~random値をとる ］かつ［ それは最大~値に`ごく近い^em ］場合には，代わりに最大~値が利用される。 精確な詳細は、 `§ ~random値の評価-法$ を見よ。 ◎ Note: Even if it’s intended that min and max are exactly some integer multiple of step apart, numeric precision issues can prevent that from being true. To avoid these issues, if the max value is very close to equalling a stepped value (above or below it), the max value is used as the final stepped value instead. See § 9.3 Evaluating Random Values for precise details.

`round$f の定義にて説明したとおり，~CSSの値には “生来な” 精度は無いが、 段差~値を利用すれば，精度をアテガえる — 例えば：

• `random(100px, 500px, 1px)^v は、 解決した結果を `1px^v の整数倍に限るよう制約する。
• `random(1, 10, 1)^v は、 解決した結果を整数に限るよう制約する。

◎ As explained in the definition of round(), CSS has no "natural" precision for values, but the step value can be used to assign one. ◎ For example, random(100px, 500px, 1px) restricts it to resolving only to whole px values; random(1, 10, 1) is restricted to resolving only to integers; etc.

注記： 段差~値を供することは、 ~random値を生成してから丸めることとは等価でない。 例えば， `random(100px, 200px, 50px)^v は、 3 通りのアリな値 — `100px^v, `150px^v, `200px^v — を同じ［ 3 回に 1 回の~~確率 ］で生成することになる。 一方で， `round(random(100px, 200px), 50px)^v は、 同じ 3 通りのアリな値を生成するが，［ `100px^v は 4 回に 1 回／ `150px^v は 2 回に 1 回／ `200px^v は 4 回に 1 回 ］生じることになる。 ◎ Note: Providing a step value is not equivalent to generating a random value and then rounding it; random(100px, 200px, 50px) will generate three possible values (100px, 150px, 200px) all with a 1/3 chance, while round(random(100px, 200px), 50px) will generate the same three possible values, but 150px will occur 1/2 the time, while 100px and 200px will only occur 1/4 of the time each.

入力を成す`計算式$たち %計算式たち を成す各~計算式は，どの値にも解決され得るが、 %計算式たち が`一貫した型を有して$いない場合，当の関数は無効になる。 当の関数の結果の`型$は、 当の計算式たちの`一貫した型$になる。 ◎ All of the calculation arguments can resolve to any value, but must have a consistent type or else the function is invalid; the result’s type will be the consistent type.

9.1.1. 引数の範囲

`random(A, B)^f においては： ◎ In random(A, B),＼

• %A は無限ならば ⇒ 結果は無限になる。

  【 無限とは［ 正な無限大, 負な無限大 ］の総称を表す。 明示的には指定されていないが、 入力と結果における その正負は，一致するべきであろう。 】

  ◎ if A is infinite, the result is infinite.
• 他の場合、 %A と %B の差は無限または［ ~UAが無限として扱うことになるほど十分に巨大である ］ならば ⇒ 結果は ~NaN になる。 ◎ If A is finite, but the difference between A and B is either infinite or large enough to be treated as infinite in the user agent, the result is NaN.

`random(A, B, C)^f においては、 上で %A, %B 用に定義した挙動が適用され，それらに該当しない場合： ◎ In random(A, B, C), the same behavior for A and B as defined above applies.＼

• %C は無限ならば ⇒ 結果は %A になる。 ◎ If C is infinite, the result is A.
• 他の場合【！negative, zero, or positive】、 引数 %C （段差）が［ その定義にて言及した “整数倍” がとり得る範囲 （ `§ ~random値の評価-法$ に言及される %N ）が， ~UAにおいて無限になる ］ほどに 0 に十分~近いならば ⇒ %C を`無視する^emモノトスル。 ◎ If C is negative, zero, or positive but close enough to zero that the range for the step multiplier (the N mentioned in § 9.3 Evaluating Random Values) would be infinite in the user agent, the step must be ignored. (The function is treated as if only A and B were provided.)

注記： 通例の`~math関数$と同じく、 いずれかの計算式~引数が ~NaN になる場合， 結果は~NaNになる。 ◎ Note: As usual for math functions, if any argument calculation is NaN, the result is NaN.

9.2. ~listから~randomな~itemを~~選ぶ： `random-item^f 関数

`random-item@f 関数は、 2 個目以降の引数たちが成す~listから~randomに選ばれる~itemに解決される。 ◎ The random-item() function resolves to a random item from among its list of items.

`random-item()$t
	= random-item( `random-key$t , [ `declaration-value$t? ]# )

`random-item$f 関数の`引数~文法$は： ◎ The random-item() function’s argument grammar is:

`random-item-args@t
	= random-item( `declaration-value$t, [ `declaration-value$t? ]# )

この関数が どう評価されるかについての詳細は、［ `§ ~random値の評価-法$, `§ ~random値の共有-／非~共有-法$ ］を見よ。 ◎ See § 9.3 Evaluating Random Values and § 9.4 Sharing (Or Not) Random Values: the <random-key> value for details on how the function is evaluated.＼

この関数においては、 `random-key$t は`要求される^em。 それは、 `random$f のときと同じに解釈される （詳細は、 `§ ~random値の共有-／非~共有-法$ を見よ）。 ◎ The required <random-key> is interpreted identically to random(). (See § 9.4 Sharing (Or Not) Random Values: the <random-key> value for details.)

注記： `random-key$t 引数が `random$f においては省略可能な一方， `random-item$f においては要求される理由は、 構文解析にある （ `random-item(--foo, --bar, --baz)^v がとる 1 個目の引数が［ `declaration-value$t, `random-cache-key$t ］どちらなのかを伝えることはアリでない）。 ◎ Note: The <random-key> argument is required in random-item(), but optional in random(), for parsing reasons (it’s impossible to tell whether random-item(--foo, --bar, --baz) has three <declaration-value> arguments or two and a <random-cache-key>).

残りの引数は、 ~CSS値たちが成す任意な連列である。 `random-item$f 関数には、 この連列から~randomに選ばれる一つが代入される。 ◎ The remaining arguments are arbitrary sequences of CSS values. The random-item() function is substituted with one of these sequences, chosen uniformly at random.

`random-item$f 関数は、 `var$f の様な`任意-代入~関数$である。 ◎ The random-item() function is an arbitrary substitution function, like var().

9.3. ~random値の評価-法

9.4. ~random値の共有-／非~共有-法： `random-key$t 値

~CSSは宣言的な言語なので、 関数が “いつ評価されるか” に関して，特定の “時刻” は無い — ~UAは、 関数たちを何回でも, どの順序でも，自身が求めるだけ “実行して” かまわない — どの実行も同じ値を返すことになるので。 ~randomな値を返す関数は、 これと両立することが困難である — それらは、 内来的に`有状態^emであり，［ いつ, 何回, どの順序で ］実行されるかについて~careする。 ◎ CSS is a declarative language, so functions don’t have a specific “time” when they’re evaluated; the user agent is free to “execute” functions in any order, as many times as they want, as every execution will return the same value. This is difficult to square with random-value functions, which are inherently stateful and care about when, how often, and in what order they’re executed.

これを解消するため、 `~random関数$には，ある`~random~cache名$が結付けられる — それは、 他と［ 同じ／異なる ］~cache~keyを伴う`~random関数$が評価されるときは，［ いつでも同じ／（偶然~同じにならない限り）`異なる^em ］`~random基底~値$を返すようになることを確保する。 ◎ To solve this, the random functions are associated with a random cache name, ensuring that any time the random function is evaluated with the same cache key, it will return the same random base value; and also that random functions with different caching keys will return different random base value from each other (unless they are, randomly, the same).

`random-key$t 値は、 この挙動を制御する。 省略されたときの既定は、 `auto$v になる。 その構文は： ◎ The <random-key> value controls this behavior, and defaults to auto when omitted. It’s syntax is as follows,＼ and interpreted as described below:

`random-key@t
	= `auto$v
	| `random-cache-key$t
	| `fixed$v `number [0,1]$t
`random-cache-key@t
	= `dashed-ident$t
	|| `element-scoped$v
	|| [ `property-scoped$v | `property-index-scoped$v | `random-ua-ident$t ]
`random-ua-ident@t
	= `custom-ident$t

値は、 以下に述べるとおりに解釈される： ◎ ↑

`auto@v

当の`~random関数$は、 概ね “アリな限り~random” になる： `~random~cache名$は（したがって結果は）、［ 複-成分からなる値を成す各 `random$f ~instance, 異なる~prop, 異なる要素 ］にまたがって変わる。 ◎ The random function is roughly “as random as possible”: the random cache name, and thus the result, varies across every random() instance in a multi-component value, across different properties, and across different elements.

これは、［ `random-cache-key$t として `element-scoped property-index-scoped^v を指定すること ］と等価になり， その場合と正確に同じ仕方で`単純~化＠#random-simplify$される。 ◎ This is equivalent to specifying element-scoped property-index-scoped, and simplifies in exactly the same way.

`random-cache-key$t

`~random~cache名$を指定することにより、 当の~random値を`命名して^em，それが［ `~random関数$の他の利用 ］と明示的に共有されるように［ なる／ならない ］ことを許容する。 ［ 同じ／異なる ］`~random~cache名$を利用している`~random関数$どうしは、［ 同じ／無関係な ］~random値を取得することになる。 ◎ The <random-cache-key> specifies the random cache name, allowing it to be explicitly shared (or not) with other uses of random functions. Every random function using the same random cache name will get the same random value; every one using a different random cache name will get unrelated random values.

`dashed-ident$t ◎ The <dashed-ident>,＼

`~random~cache名$の`名前$rCを明示的に与える。 省略された場合、 当の`名前$rCは ~NULL になる。 ◎ gives the value an explicit name. If omitted, this part of the name is null.

`element-scoped@v ◎ element-scoped＼

`~random~cache名$に当の要素に特有な識別子を追加する — なので、 要素ごとに異なる~random値を取得することになる。 ◎ adds an element-specific identifier to the random cache name, so different elements will get different random values.

当の`~random関数$が ある`~custom関数$の内側で評価されている場合、 この識別子は，当の関数の~style群を評価した際の “`仮の要素$” 用のそれになる。 なので、 `element-scoped$v は，関数の呼出nごとに異なる~random値を与えることになる。 ◎ If the random function is being evaluated inside of a custom function, the element-specific identifier is for the "hypothetical element" that the function’s styles are evaluated on, so element-scoped will give you different random values on every function invocation.

`property-scoped@v

`property-index-scoped@v

`property-scoped$v と `property-index-scoped$v は、 `~random~cache名$に当の`~random関数$を利用している~propの名前を追加する — なので、 ~prop名ごとに異なる~random値を取得することになる。 `略式~prop$においても、 【下位propではなく】当の略式~propの名前を適用することに注意。 ◎ property-scoped adds the property name the random function is being used on to the random cache name, so different properties will get different random values. Note that shorthand declarations will apply the shorthand property’s name.

`property-index-scoped$v は、 それに加え，［ 当の`~random関数$は、 当の~propの値に利用された~random関数のうち何個目の~instanceか ］を指示する~indexも追加する。 なので、 同じ宣言~内に利用された複数個の`~random関数$は，それぞれ異なる`~random~cache名$を取得するようになる。 ~indexは、 略式~propが【下位propたちへ】展開される前にアテガわれることに注意。 ◎ property-index-scoped adds the property name and the index of the random function among all the random functions used in the same property value to the random cache name, so multiple instances of a random function in the same declaration will each get different random cache names. Note this index is assigned before shorthand expansion.

これらの値がどう解決されるかは、 `§ 単純~化＠#random-simplify$ を見よ。 ◎ See § 9.4.1 Simplification of <random-key> for how these values resolve.

`random-ua-ident$t ◎ The <random-ua-ident> value,＼

この値は、 `fixed$v と同様に，作者が指定することが意図されるものではないが、 【自動的に生成される場合でも，】`算出d値$内に~~現れ得る。 ◎ like fixed below, isn’t intended to be specified by authors, but can show up in computed values.＼

この値は、 接頭辞 `ua-^v から開始する `custom-ident$t でなければナラナイ — さもなければ、 無効になる。 ◎ It is a <custom-ident> that must start with the prefix ua-, or else it is invalid.＼

この値が，~UAにより自動的に生成されるときには、 ある種の特定な~patternに従う — 詳細は `§ 単純~化＠#random-simplify$ を見よ。 ◎ When generated automatically by the user agent, it follows certain specific patterns; see § 9.4.1 Simplification of <random-key> for details.

`fixed@v `number [0,1]$t

指定された場合、 当の`~random関数$は`~random~cache名$をまるごと素通りして， その`~random基底~値$として所与の `number^t を直に利用するようになる。 ◎ If fixed <number> is specified, the random function bypasses the random cache name entirely, and just uses the <number> as its random base value directly.

`1^v は、 形上では妥当な値として許容されるが （~CSS文法は閉な範囲しか表出できないので），［ `1^v 未満かつ【実装が】表現-可能な `1^v に最も近い値 ］としてふるまう。 なので、 どの`~random基底~値$も 0 以上 1 未満になる。 ◎ While 1 is technically allowed as a valid value (because CSS grammars can only express closed ranges), the random base value is clamped to the highest representable value less than 1, so random base values remain in the half-open range `[0, 1)`.

注記： 作者にとっては、 この値は，~pageを~testしている間は予測-可能な値を取得するためとして有用になる`かもしれない^em。 が、 それが存在する理由は， `継承$における ある際どい事例 — 作者の期待に反して，要素たちが`~random基底~値$を`共有しなく^emなる事例 — を修正するためにある 【 `fixed$v 以外の `random-key$t を算出d値の時点で当の関数の`~random基底~値$を伴う `fixed$v に`置換する＠#_replaced-with-fixed$ことにより】。 それは、 ある稀な`算出d値$において観測-可能になるが， それ以外では要素の~style内には決して~~現れない。 k◎ Note: While this value might be useful for authors to get predictable values while testing a page, the reason it exists is to fix some corner cases in inheritance that would otherwise cause elements to not share random base values when authors would expect them to. It is observable in some rare computed values, but otherwise will never show up in an element’s styles.

.foo {
  width: random(--foo, 100px, 200px);
  animation: --pulse linear random(--foo, 1s, 2s);
}

.foo {
  animation: flicker linear random(1s, 2s);
}
.foo:hover {
  animation: glow linear random(4s, 6s);
}

より特定的には、 ~style内の各`~random関数$【！the random() and random-item() functions】は， 次に挙げる［ ~cache法の意味論 ］の下で~random値を生成するものと定義される： ◎ More specifically, the random() and random-item() functions are defined to generate random values under the following caching semantics:

• 当の関数の各~instance【各~利用】には， `~random基底~値@ が結付けられる — それは： ◎ Each instance of a random function in styles has an associated random base value.

  • 当の関数の `random-key$t に `fixed$v と伴に `number$t が指定された場合、 それになる。 ◎ If the random function’s <random-key> is fixed <number>, the random base value is that number.
  • 他の場合、 0 以上 1 未満の範囲に一様に分布する~randomな実数になる。 ◎ Otherwise, the random base value is a pseudo-random real number in the range `[0, 1)` (greater than or equal to 0 and less than 1), generated from a uniform distribution,＼ ↓ and influenced by the function’s random cache name.

• 各`~random関数$【の各~利用】は、 `~random~cache名@ も指定する。 2 つの`~random関数$の`~random基底~値$は、 【 `number^t として明示的に与えられた場合（前項）を除いて】 互いの`~random~cache名$が同じならば同じになり， 異なるならば別個になる （すなわち，ある新規な~random演算により生成される） モノトスル （もちろん、 ~randomなので，実際に生産する値は同じになるかもしれないが）。 ◎ Each random function also specifies a random cache name. Two random functions with the same random cache name must also have the same random base value; two functions with different random cache names must have distinct random base values. (That is, generated by a fresh random operation; randomness might of course produce the same actual value.)

  これを達成するために`~random~cache名$を`どう利用する^emかは、 意図的に未指定である。 生成された~random値を そのまま~cacheすることも， 疑似-~random生成器~用の~seedとして利用すること, 等々もできる。 ◎ It is intentionally unspecified how the random cache name is used to achieve this. It can literally cache a generated random value, or be used as a seed for a PRNG, etc.

  【 したがって、 `random$f と `random-item$f であっても， `~random~cache名$が一致するならば同じ`~random基底~値$を取得することになる （本当か？）。 】

• 各`~random~cache名$は、 順に，次に挙げるものが成す`~tuple$である： ◎ A random cache name is a tuple of:

  1. `名前@rC ⇒ ~NULL ／ある`文字列$

     • `dashed-ident$t が指定された場合、 その値になる
     • 他の場合、 ~NULL になる
     ◎ A nullable string name: the value of the <dashed-ident>, if specified; otherwise null.

  2. `~prop名（と~index）@rC ⇒ ~NULL ／ある`文字列$

     • `random-ua-ident$t が［ 指定された／計算される【自動的に生成される】 ］場合には，その値になる。
     • 他の場合、 ~NULL になる
     ◎ A nullable string property/index value: the value of the <random-ua-ident>, if specified/calculated; otherwise null.

  3. `要素~識別子@rC ⇒ ~NULL ／ある識別子

     • `element-scoped$v が指定された場合、 当の~styleが適用されている~obj （`要素$／`疑似要素$／`~custom関数$を評価する際に利用される “`仮の要素$” ） を一意に識別する識別子になる。

       【~FN `仮の要素@ （ `hypothetical element^en ） とは、 たぶん， `関数~style群を解決する＠~CSSMIXIN#resolve-function-styles$ `CSS-MIXINS-1$r ~algoの中で作成されるそれを指す。 】

     • 他の場合、 ~NULL になる
     ◎ A nullable /element identifier/ uniquely identifying the object the style is being applied to (the Element, pseudo-element, or custom function evaluation’s "hypothetical element"), if element-scoped is specified; otherwise null.
  4. `文書~識別子@rC ⇒ ある識別子 ⇒ 当の~styleが属する`文書$を識別する ◎ A /document identifier/ identifying the Document the styles are from.

  `要素~識別子$rCと`文書~識別子$rCの存続期間は、 同じになるモノトスル。 ［ `要素~識別子$rCどうし／`文書~識別子$rCどうし ］の等価性の意味論は、［ `要素$／`文書$ ］への~JS参照と同じになるモノトスル。 ◎ The /element identifier/ and /document identifier/ must have the same lifetimes and equivalence semantics as a JavaScript reference to the Element or Document.

  【 したがって、 当の要素が別の文書へ移動され，再び元の文書へ戻された場合でも、 `要素~識別子$rCは，変化しないことになる。 】

  疑似要素~用の挙動を明確化する必要がある。 ◎ The behavior for pseudo-elements needs to be clarified.

• `~random~cache名$と`~random基底~値$は、［ `算出d値$の時点まで, `継承＠~CASCADE#css-inheritance$よりも前 ］に決定するモノトスル — ［ ある要素, その子 ］に利用された【同じ引数をとる】~random関数が［ 前者は継承の時点までは（例えば，~layoutに敏感な百分率を包含していることに因り）解決されないが， 後者は即時に解決される ］場合でも，両者の挙動が同じになるよう。 ◎ The random cache name and random base value must be determined by computed value time, before inheritance, so that a random function that is unresolved by inheritance time (due to containing, for example, a layout-sensitive percentage) does not have a different behavior on children than one that resolves immediately.

.same-tb-same-rl {
  margin: random(0px, 10px) random(0px, 10px);
}

.different-tb-same-rl {
  margin: random(0px, 10px) random(0px, 10px);
  margin-bottom: random(0px, 10px);
}

.square-or-rect {
  --size: random(100px, 500px);
  width: var(--size);
  height: var(--size);
}

11.1. `calc-size^f の解決-法

`calc-size$f 関数は、 `使用~値$の時点より前に解決される【！or simplified】ことはない （`§ ~calc-size_fの補間-法＠#interpolate-calc-size$ を見よ）。 ◎ Before used value time, calc-size() functions are not resolved or simplified. (But see § 11.2 Interpolating calc-size().)

`calc-size$f 関数の`計算式$cSは、 `calc$f 式の値と同様に， `使用~値$の時点で解決される — 当の計算式~内の `size$v ~keywordへ当の関数の`基底s$cSの使用~値を代入して， 各~百分率を ［ それが`確定的$であるならば 通常に／ 他の場合は `0px^v を~~基準に ］評価することにより。 ◎ At used value time, the calc-size calculation is resolved just like the value of a calc() expression, by substituting in the used value of the calc-size basis for the size keyword in the calc-size calculation, and evaluating any percentages normally (if they are definite) or against 0px (if they are not).

11.2. `calc-size^f の補間-法

`calc-size$f 関数は、［ `length-percentage$t ／ `size-keyword$t ］ %値 とも補間し得る。 ［ これらの値を補間できるかどうか, できる場合の補間の挙動 ］を決定するときは、 %値 を次に与える `calc-size^f として扱う下で，上の~algo【！規則】を適用する： ◎ Some calc-size() values can also be interpolated with a <length-percentage> or an <size-keyword>. To determine whether the values can interpolate and what the interpolation behavior is, treat the non-calc-size() value as＼

• %値 は `calc-sum$t として与えられた場合 ⇒ calc-size(`any$v, %値 ) ◎ calc-size(any, value ) if the value is a <calc-sum>＼
• 他の場合 ⇒ calc-size( %値, `size$v) ◎ or as calc-size( value , size) otherwise, and apply the rules above.

details {
  transition: height 1s;
}
details::details-content {
  display: block;
}
details[open]::details-content {
  height: auto;
}
details:not([open])::details-content {
  height: calc-size(any, 0px);
}

注記： これらの規則は、 calc-size(any, ある`確定的$な長さ ) と他の何かとの補間が — 他の何かがどう指定されたかに関わらず — `常に^em滑らかになることを許容する。 ◎ Note: These rules allow calc-size(any, definite length) to always interpolate smoothly, regardless of how the other side of the transition is specified.

注記： 上述した “素な %値 を `calc-size$f へ昇格する” 挙動は、 昇格された `calc-size^f の`計算式$cSの中へ %値【！`length-percentage$t】 を置く。 このことは、 %値 が百分率を伴う場合でも，［ %値 と内在的~size~keywordを補間すること ］を許容するが、［ 百分率が`確定的$でないときには、 当の百分率は 0 へ解決されるようになる ］ことを意味する。 作者は，［ 百分率が当の要素の実際の~sizeを~~基準に解決されるようになる ］ことを求めるなら、 `基底s$cSとして %値 を伴う `calc-size^f を明示的に与えること — `calc-size(50%, size)^v の様に。 ◎ Note: This "upgrade a plain value into a calc-size()" behavior puts <length-percentage> values into the calc-size calculation. This allows values with percentages to interpolate with intrinsic size keywords, but does mean that when a percentage isn’t definite, it’ll resolve to zero. If you want to resolve to the actual size the percentage would make the element, explicitly write a calc-size() with the value in its calc-size basis, like calc-size(50%, size).

11.3. 自動的に ~sizing~keywordの補間-法： `interpolate-size^sp ~prop

この~propは、 `~sizing~prop$に対し， ~keyword値を `length-percentage$t 値と滑らかに結合することを許容する — そのような事例~用に`離散的$な~animation【！ (See Web Animations § 5.2 Animating properties.)】を利用することなく。 ◎ This property allows keywords on the sizing properties to smoothly combine with <length-percentage> values rather than using discrete animation for this case. (See Web Animations § 5.2 Animating properties.)

`numeric-only@v

`size-keyword$t と結合できるものは、 それと互換な `calc-size$f に限られる。 ◎ A <size-keyword> can only be combined with a compatible <calc-size()>.

`allow-keywords@v

`~sizing~prop$用の値どうしは、［ 一方が `size-keyword$t, 他方が `length-percentage$t ］である場合には，結合できる。 これは、 所与の `size-keyword$t %~keyword に対し，［ %~keyword は calc-size(%~keyword, size) であった ］かのように扱う下で［ `calc-size$f の`補間-法＠#interpolate-calc-size$を適用する ］ことにより行われる。 他の事例においては、 `size-keyword$t は，依然として補間できない。 ◎ Sizing values can also be combined if one of them is an <size-keyword> and the other is a <length-percentage>. This is done by treating the <size-keyword> keyword as though it is calc-size(keyword, size) and applying the rules in § 11.2 Interpolating calc-size(). In other cases, a <size-keyword> still cannot be interpolated.

注記： `allow-keywords$v に設定することは， `ほとんどの^em ~size値が補間されるようになることを許容するが、 すべてではない — 異なる~keywordどうしは、 依然として，補間-可能にならない。 ~layout~algoは、［ 子孫が精確に どの~sizing~keywordを利用しているか ］に基づいて， それらの挙動を［ 補間の間には表現し得ない仕方 ］で変更し得るので。 ◎ Note: Setting allow-keywords allows most size values to be interpolated, but not all; different keywords are still not interpolable with each other, as layout algorithms can change their behavior based on precisely which sizing keyword a descendant is using, in a way that can’t be represented during interpolation.

注記： `allow-keywords$v を設定することは， `calc-size$f を手動で利用する必要を `ほとんど^em 除去するが、 それでも，それを利用することに便益がある事例はある。 例えば，`包含塊$の~sizeが`不定$である場合、 `width$p を `100%^v から `0px^v へ素朴に補間しても， 期待されるとおりには働かない （中間的な値は，`~autoとして挙動する$かもしれず、 その場合，それらの値は `100%^v と同じ~sizeになるので）。 一方で， `width^p に手動で［ `calc-size(100%, size)^v ／ `calc-size(any, 0px)^v ］を書いたなら、 これらの値の合間で滑らかに補間されるようになる。 ◎ Note: Setting allow-keywords mostly removes the need to use calc-size() manually, but there are still some cases that can benefit from using it. For example, if the containing block size is indefinite, naively interpolating width: 100% to width: 0px won’t work as expected (since the intermediate values might behave as auto, making them the same size as 100%), but manually writing width: calc-size(100%, size); and/or width: calc-size(any, 0px); will, causing the element to smoothly interpolate between the two values.

注記： 過去へ戻れたなら、 この~propは存在しなかった。 `allow-keywords$v の挙動は、 既定では どう働くかを変えるだけである。 これが存在するのは、 既存の多くの~stylesheetが［ ~sizing~keyword（ `~autoS$v, `min-content$v, 等々）をまったく補間し得ない ］ものと見做すからであり，［ それらを補間することにした場合，非互換化された挙動を生産することになる ］からである。 この前提との互換性を得るため、 この補間を許容することには，~opt-inが要求される。 この~propは継承されるので、 根~要素に `interpolate-size: allow-keywords^p を指定すれば， 新たな挙動を~page全体に許容する。 互換性が課題にならない所では、 そうすることが示唆される。 ◎ Note: If we had a time machine, this property wouldn’t exist; the allow-keywords behavior would just be how things worked by default. It exists because many existing style sheets assume that the sizing keywords (auto, min-content, etc.) cannot interpolate at all, and would produce broken behavior if they started interpolating. For compatibility with this assumption, allowing this interpolation requires an opt-in. Because the property inherits, specifying :root { interpolate-size: allow-keywords; } allows the new behavior for the entire page. We suggest doing this wherever compatibility isn’t an issue.

`interpolate-size$p の値が問われる時点, それを問うものは、 当の要素の【他の~propの】~animationが開始するかもしれない時点における， その`算出d値$である。 ~CSS遷移~用には、 これは，`変化-後~style$における値を意味する。 ~animationは、 その後に `interpolate-size^p が変化しても［ 停止される／開始される ］ことはない。 ◎ The value of interpolate-size that matters is the computed value on the element at the time the animation might start. For CSS transitions, this means the value in the after-change style. An animation is not stopped or started later because interpolate-size changes.

代入

各種 `任意-代入~関数$は、 `任意-代入~関数の置換~algo@ — 当の関数を置換する値を決定する方法 — を［ 所与の ( 引数たちが成す~list, `代入~文脈$たちが成す`~stack$ ) に対し，［ `成分~値$たちが成す連列【／`無効が保証される値$】 ］を返す~algo ］として定義しなければナラナイ。 それは、 更なる`代入$を孕む見込みが高い （【それにより，入子な`任意-代入~関数$は】全部的に解決されるので、 結果の連列~内には`任意-代入~関数$は存在しない）。 当の関数は、 その結果により置換されることになる。 ◎ Each arbitrary substitution function must define how to replace an arbitrary substitution function for itself, given a list of arguments and a stack of substitution contexts, and likely involving further substitution. It must return a sequence of component values (fully resolved, so no further arbitrary substitution functions exist in the sequence), which it will be replaced by.

【 これは、 暗黙的な文脈として［ 当の関数を値に利用した~styleが適用される要素 ］も入力にとる — 利用されない関数もあるが。 したがって、 この~algoを呼出す~algoも，同様にそれを入力にとる。 】

`任意-代入~関数$は、 解決されるに伴い，`代入~文脈$たちを【~stackに】累積する — それは、 `入子な^em `任意-代入~関数$をどう解決するかに影響する。 ◎ As arbitrary substitution functions are resolved they accumulate substitution contexts which affect how nested arbitrary substitution functions resolve.

`代入~文脈$の ( 種別, 値たち… ) は、 現時点では，次に挙げるものに限られる： ◎ The types of substitution contexts are currently:

• ( `~prop^i, ある~prop名 ) ◎ ↓
• ( `~prop^i, ある~prop名, ある`~custom関数$ ) ◎ "property", followed by a property name, and optionally a custom function.
• ( `属性^i, ある属性~名 ) ◎ "attribute", followed by an attribute name
• ( `関数^i, ある`~custom関数$ ) ◎ "function", followed by a custom function.

`代入$は，入子な`任意-代入~関数$が`置換される＠#replace-an-arbitrary-substitution-function$ときに再帰的に呼出されるので、 【！guards】 各~呼出nに渡される`代入~文脈$は “積み上げられて” いく。 ◎ As substitution is recursively invoked by nested arbitrary substitution functions being replaced, guards "stack up" the substitution contexts passed to each invocation.

【 これらの文脈が，どう “積み上げられる” かは、 各種~代入~algoの中では，それらが成す~stackに対する演算（いつ, 何が~pushされるか）としては明示的に述べられていない — 少なくとも，各 `任意-代入~関数の置換~algo$の中で適切な`代入~文脈$が暗黙的に~stackに~pushされると思われるが。 】

.foo {
  --one: var(--two);
  --two: var(--one);
}

.foo {
  --one: var(--two);
  --two: var(--three, baz);
  --three: var(--one);
}

引数~文法と~spread構文

各`任意-代入~関数$は、 標準な文法に加えて， `引数~文法@ も定義しなければナラナイ — それは、 通常の文法よりも ずっと［ 何かに特有でない, かつ制約的でない ］~versionであり，もっぱら［ 関数の内容を別個な引数たちへ分離するもの ］として~serveする。 ◎ Each arbitrary substitution function, in addition to its standard grammar, must define an argument grammar: a much less specific and less restrictive version of its normal grammar, which serves solely to separate the function’s contents into distinct arguments.

注記： `引数~文法$は、 概して，［ 何らかの約物（通例的には~comma）と生成規則 `declaration-value$t ］のみからなる。 例えば， `if$f 関数を見よ。 ◎ Note: Typically, an argument grammar will only consist of some punctuation (usually commas) and the <declaration-value> production. See the if() function for an example.

各~関数~用の`任意-代入~関数の置換~algo$においては、［ 各~引数たちに`代入$を適用した結果 ］を［ 標準な文法を成す適切な各部の`文法に則って構文解析-$する ］ことになる。 しかしながら，それは、 この処理nの制御~下にあるので，一部の引数は［ 解決されず，構文解析されないまま残される ］こともある。 ◎ Each function, in its replacement algorithm, will apply substitution to its arguments and then parse them according to the appropriate parts of its standard grammar. As it is in control of this process, however, some arguments can be left unresolved and unparsed.

.foo {
  --color: if(media(width >= 600px): blue; else: var(--color));
}

このことは、 関数の`引数~文法$に則った構文解析は， 入子にされた`任意-代入~関数$の結果【それ用の`任意-代入~関数の置換~algo$の結果】を普通は【すなわち，それが`~spread構文$を利用していない限り】`見ない^emことも意味する。 関数の内容は、［ 関数の内側に~literalに在る値たち ］のみに基づいて，引数たちへ分割0される。 ◎ This also means that, ordinarily, parsing according to a function’s argument grammar does not see the results of any nested arbitrary substitution functions; the contents are divided into arguments based only on the values literally present inside the function.

.random-fonts {
  --foo: Courier, monospace;
  --bar: Arial, serif;
  font-family: random-item(auto, var(--foo), var(--bar));
  /* 
は、
次と等価になる：
◎
equivalent to:
 */
  font-family: random-item(auto, {Courier, monospace}, {Arial, serif});

  /* 
したがって、
次のいずれかに~randomに等価になる
◎
and thus, randomly, equivalent to either
 */
  font-family: Courier, monospace;
  /* 
あるいは
◎
or
 */
  font-family: Arial, serif;
}

--colors: red, blue, green;
background: linear-gradient(var(--colors));

この挙動は、 `~spread構文@ — 【引数として入子にされた】`任意-代入~関数$の直前に `...^g を伴わせること — により回避できる。 それは、 次を指示する ⇒ 当の関数を “早期” に — 【それを入子にしている`任意-代入~関数$の中で】引数たちへ分割0する前に — 解決するモノトスル。 ◎ This behavior can be worked around by immediately preceding an arbitrary substitution function with the spread syntax ..., indicating that it must be resolved "early", before division into arguments.

.invalid-if {
  --if-clause: media(width >= 600px): blue;
  color: if(var(--if-clause); else: green;);
}

.valid-if {
  --if-clause: media(width >= 600px): blue;
  color: if(...var(--if-clause); else: green;);
}

`~spread構文$は、 3 個の［ .値 `.^l を伴う `delim-token$t ］からなる — ［ それら各~tokenの合間／ それらと後続な`任意-代入~関数$の合間 ］に空白を包含してはナラナイ。 ◎ The spread syntax is three distinct <delim-token>s with the value `"."`, all of which must not contain any whitespace between them, or between the group and the subsequent arbitrary substitution function.

注記： `~spread構文$は、 `任意-代入~関数$の`中でしか^em利用されない — `代入$~algoにより`任意-代入~関数$を構文解析するときにしか参照されないので。 外側で利用した場合 — `width: ...var(--sidebar-width)$p など — 早期~呼出nとして認識されない。 代わりに， `...^g は、 `var$f 関数とは無関係な［ ~propの値を成す一部 ］になり， この事例では `width^p ~propを無効にする。 （このことは、 ~JSに類似する — そこでは、 `[1, ...arr, 5]^c は妥当であるが， `var x = ...arr;^c は妥当でない。 この構文は、 そこから借用された。） ◎ Note: The spread syntax is only used within an arbitrary substitution function’s value, as it’s only referenced by the substitution algorithm when parsing an arbitrary substitution function. Using it outside of that, such as in width: ...var(--sidebar-width);, is not recognized as an early invocation; instead, the periods are just part of the property’s value, unrelated to the var() function, and would in this case make the width property invalid. (This is similar to JavaScript, where this syntax was borrowed from, where `[1, ...arr, 5]` is valid, but `var x = ...arr;` is not.)

~propにおける解決-法

他が指定されない限り，`任意-代入~関数$は、 どの~propの どの値においても， それを成す どの場所にも（他の`関数-記法$の中も含めて）利用できる — 他の文脈においては妥当でない。 ◎ Unless otherwise specified, arbitrary substitution functions can be used in place of any part of any property’s value (including within other functional notations); and are not valid in any other context.

これらの関数のうち，~propの外側の文脈においても妥当になるべきものはあるか？ ◎ Should any of these functions be valid in contexts outside of properties?

.foo {
  --side: margin-top;
  var(--side): 20px;
}

ある~propの値が`任意-代入~関数$たちを包含していて， いずれも各自の`引数~文法$に則って妥当である場合、 当の値~全体の文法は，構文解析-時には妥当であると見做すモノトスル。 ◎ If a property value contains one or more arbitrary substitution functions, and all of those functions are themselves syntactically valid according to their argument grammars, the entire value’s grammar must be assumed to be valid at parse time.

`任意-代入~関数$は、 値に対する他の［ 変形n／自己検分 ］が生じ得る前に， ~styleの`算出d値$を得る間に`代入-$される。 ある~prop【の値】が`~prop置換$の後において， それの【当の~prop用に】宣言された文法に合致しない場合、 当の宣言は，`算出d値の時点で無効$になる。 ◎ Arbitrary substitution functions are substituted during style computation, before any other value transformations or introspection can occur. If a property, after property replacement, does not match its declared grammar, the declaration is invalid at computed-value time.

注記： `任意-代入~関数$は，`算出d値$の時点で解決されるので、 代入された結果の値が無効になる場合， 当の~propは（本質的に） `unset$v の挙動へ~fall-backする — ~prop宣言が構文解析-時に無効になったときには， `~cascade$において より早い値【より優先度が低い宣言】へ~fall-backするが、 そうではなく。 `無効な代入＠#invalid-substitution$を見よ。 ◎ Note: Since arbitrary substitution functions resolve at computed value time, if the resulting value after substitution is invalid, the property falls back (essentially) to unset behavior, rather than falling back to an earlier value in the cascade the way declarations invalid at parse time do. See Invalid Substitution.

ある~propの値が，`~prop置換$の後において 1 個の`~CSS全域~keyword$（および，場合によっては空白）しか包含しない場合、 その値【`算出d値$】は，［ その`指定d値$は初めから当の~keywordであった ］かのように決定される。 ◎ If a property value, after property replacement, contains only a single CSS-wide keyword (and possibly whitespace/comments), its value is determined as if that keyword were its specified value all along.

:root { --looks-valid: 20px; }
p { background-color: var(--looks-valid); }

p { color: var(--does-not-exist, initial); }

.foo {
  --gap: 20;
  margin-top: var(--gap)px;
}

.foo {
  --gap: 20;
  margin-top: calc(var(--gap) * 1px);
}

.foo {
  --gap: 20;
  --not-px-length: var(--gap)px;
}

無効な代入

所与の~prop %~prop に対する`~prop置換$の結果が`無効が保証される値$を包含するときは、 当の宣言は `算出d値の時点で無効@ になる。 これが起きた場合、 %~prop の`算出d値$は： ◎ When property replacement results in a property’s value containing the guaranteed-invalid value, this makes the declaration invalid at computed-value time. When this happens, the computed value is one of the following depending on the property’s type:

%~prop は登録-済みでない`~custom~prop$である場合 ◎ The property is a non-registered custom property

%~prop は`全称~構文~定義$を伴う`登録-済み~custom~prop$である場合 ◎ The property is a registered custom property with universal syntax

`無効が保証される値$になる。 ◎ The computed value is the guaranteed-invalid value.

他の場合 ◎ Otherwise

［ %~prop は`継承d~prop$であるならば %~prop の`継承d値$／ ~ELSE_ %~prop の`初期~値$ ］になる — %~prop の値として `unset$v ~keywordが指定されていたかのように。 ◎ Either the property’s inherited value or its initial value depending on whether the property is inherited or not, respectively, as if the property’s value had been specified as the unset keyword.

:root { --not-a-color: 20px; }
p { background-color: red; }
p { background-color: var(--not-a-color); }

注記： `算出d値の時点で無効$の概念は、 `任意-代入~関数$が他の構文~errorと異なり， “早期に失敗させ” 得ないがためにある。 ~prop値が無効であることが~UAに判明した時点では、 【より優先度が低い】 他の`~cascaded値$は，すでに棄てられている。 ◎ Note: The invalid at computed-value time concept exists because arbitrary substitution functions can’t "fail early" like other syntax errors can, so by the time the user agent realizes a property value is invalid, it’s already thrown away the other cascaded values.

略式~propにおける代入

`任意-代入~関数$は、 次に挙げる所で，ある複雑化をもたらす ⇒＃ `略式~prop$の値を その`下位prop$用の成分たちに構文解析するとき／ それら各~成分から`下位prop$を直列化するとき ◎ Arbitrary substitution functions produce some complications when parsing shorthand properties into their component longhands, and when serializing shorthand properties from their component longhands.

所与の`略式~prop$の値が，その ある`下位prop$用の成分として`任意-代入~関数$を包含する場合、 当の`下位prop$には，代わりに `代入待ちの値@ をあてがうモノトスル — この値は： ◎ If a shorthand property contains an arbitrary substitution function in its value, the longhand properties it’s associated with must instead be filled in with＼

• 作者からは観測-不能な特別な値であり，［ 略式~propは`任意-代入~関数$を包含するので、 当の`下位prop$の値は，関数が`代入-$されるまで決定し得ない ］ことを指示する。 ◎ a special, unobservable-to-authors pending-substitution value that indicates the shorthand contains an arbitrary substitution function, and thus the longhand’s value can’t be determined until after substituted.
• 通常通り~cascadeするモノトスル。 ◎ This value must then be cascaded as normal,＼
• 算出d値の時点で`代入-$された後に、 `略式~prop$の値を構文解析して，`下位prop$に適切な値をあてがうモノトスル。 ◎ and at computed-value time, after substitution, the shorthand must be parsed and the longhands must be given their appropriate values at that point.

【 該当する下位propは、 1 個の`任意-代入~関数$に対し複数個あり得る — 当の関数が成す略式~propの成分~値が，複数個の下位prop用の値を与えるものと定義されている場合や、 当の関数~自体が複数個の下位prop用の値を まとめて与えている場合など。 】

注記： ある`略式~prop$が`任意-代入~関数$を伴わずに記された場合、 その値は，構文解析-時点で`下位prop$用の成分たちに分離されるよう構文解析される。 各`下位prop$は、 その後に`~cascade$に関与する — それに伴い，当の`略式~prop$は概ね破棄される。 しかしながら，これは、 当の略式~propが`任意-代入~関数$【！ `var$f 】を包含するときには行えない — それらの関数には、 何でも代入され得るので。 ◎ Note: When a shorthand is written without an arbitrary substitution function, it is parsed and separated out into its component longhand properties at parse time; the longhands then participate in the cascade, with the shorthand property more or less discarded. When the shorthand contains a var(), however, this can’t be done, as the var() could be substituted with anything.

`代入待ちの値$は、 それを観測することが~APIにより許容される所では， 空~文字列に直列化するモノトスル。 ◎ Pending-substitution values must be serialized as the empty string, if an API allows them to be observed.

`略式~prop$は、 その各`下位prop$用の成分の値を集めることにより直列化され， 同じ値~集合に構文解析されることになる値を合成することになる。 所与の`略式~prop$に対し： ◎ Shorthand properties are serialized by gathering the values of their component longhand properties, and synthesizing a value that will parse into the same set of values.

• すべての`下位prop$が`代入待ちの値$になる場合、 当の`略式~prop$は，その元の（`任意-代入~関数$を包含している）値に直列化するモノトスル。 ◎ If all of the component longhand properties for a given shorthand are pending-substitution values from the same original shorthand value, the shorthand property must serialize to that original (arbitrary substitution function-containing) value.
• 他の場合，いずれかの`下位prop$が［ `代入待ちの値$になる場合 ／ まだ`代入-$されていない自前の`任意-代入~関数$を包含する場合 ］、 当の`略式~prop$は，空~文字列に直列化するモノトスル。 ◎ Otherwise, if any of the component longhand properties for a given shorthand are pending-substitution values, or contain arbitrary substitution functions of their own that have not yet been substituted, the shorthand property must serialize to the empty string.

長過ぎな代入に対する安全な取扱い

素朴に実装された`任意-代入~関数$（ `var$f など）は、 “`billion laughs^en 攻撃” 【十億の笑い】の一種に利用され得る： ◎ Naively implemented, some arbitrary substitution functions (such as var()) can be used in a variation of the "billion laughs attack":

.foo {
  --prop1: lol; /* 笑 */
  --prop2: var(--prop1) var(--prop1);
  --prop3: var(--prop2) var(--prop2);
  --prop4: var(--prop3) var(--prop3);
  /* etc */
}

この類の攻撃を避けるため、 ~UAは，［ `任意-代入~関数$を展開した結果の~token~streamに許容される長さ ］に自身が定義する上限を課すモノトスル。 `任意-代入~関数$がこの上限より長い~token~streamに展開される場合、 代わりに，それを`無効が保証される値$に置換するとする。 ◎ To avoid this sort of attack, UAs must impose a UA-defined limit on the allowed length of the token stream that an arbitrary substitution function expands into. If an arbitrary substitution function would expand into a longer token stream than this limit, it instead is replaced with the guaranteed-invalid value.

この仕様は、 課すベキ上限~sizeは定義しない。 しかしながら， 1000 ~byte以上の~textを包含するような~custom~prop用の妥当な利用事例もあるので、 上限は多少高めに設定することが推奨される。 ◎ This specification does not define what size limit should be imposed. However, since there are valid use-cases for custom properties that contain a kilobyte or more of text, it’s recommended that the limit be set relatively high.

注記： ［ ~UAには、 資源の拘束に因り標準に違反することが許容される ］とする一般~原則は、 ここにも一般に該当する。 ~UAは、 自身が~supportできる［ ~custom~propの~~長さ, 識別子の~~長さ ］に別々な上限を課すこともあろう。 この節が，この攻撃を特定的にとり挙げるのは、 それには長い歴史があり，初回の検分では巨大~過ぎな~~片は`無さそうに見える^emものでも行える事実があることによる。 ◎ Note: The general principle that UAs are allowed to violate standards due to resource constraints is still generally true here; a UA might, separately, have limits on how long of a custom property they can support, or how large of an identifier they can support. This section calls out this attack specifically because of its long history, and the fact that it can be done without any of the pieces seeming to be too large on first inspection.