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-value-sharing$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
    = `crossorigin-modifier$t
	| `integrity-modifier$t
	| `referrerpolicy-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]

5.1. 計算された進捗-値： `progress^f 記法

`progress@f `関数-記法$は、 次を表現している `number$t 値を返す ⇒ 入力を成す 2 個の`計算式$ %計算式たち （`進捗~始端~値$, `進捗~終端~値$） の合間における`計算式$（`進捗~値$）の位置 ◎ The progress() functional notation returns a <number> value representing the position of one calculation (the progress value) between two other calculations (the progress start value and progress end value).＼

`progress$f は`~math関数$である。 ◎ progress() is a math function.

`progress$f の構文は： ◎ The syntax of progress() is defined as follows:

`progress()@t
	= progress(`calc-sum$t, `calc-sum$t, `calc-sum$t)

各 `calc-sum$t 値は、 順に［ `進捗~値$, `進捗~始端~値$, `進捗~終端~値$ ］を表現する。 ◎ where the first, second, and third <calc-sum> values represent the progress value, progress start value, and progress end value, respectively.

%計算式たち を成す各~計算式は、［ `number$t, `dimension$t, `percentage$t ］いずれにも解決され得るが， %計算式たち は`一貫した型を有して$いなければナラナイ — さもなければ、 当の関数は無効になる。 ◎ The argument calculations can resolve to any <number>, <dimension>, or <percentage>, but must have a consistent type or else the function is invalid.

`progress$f の値は、 数量-値としては`進捗~関数を計算する$ことにより決定される `number$t になり， その`型$は次の結果になる ⇒ `型を入力と一貫させる$( `型を作成する$( `number^l ) , %計算式たち の`一貫した型$ ) ◎ The value of progress() is a <number>, determined by calculating a progress function, then made consistent with the consistent type of its arguments.

`percent-progress^f 記法は必要か？ あるいは、 必要yでないほど十分な箇所で【百分率から】自動-変換されているのか？ ◎ Do we need a percent-progress() notation, or do enough places auto-convert that it’s not necessary?

注記： `progress$f 関数は、 本質的には `calc$f 記法が成す特定0の~pattern用の構文-糖衣なので，`~math関数$である。 ◎ Note: The progress() function is essentially syntactic sugar for a particular pattern of calc() notations, so it’s a math function.

5.2. 媒体~query進捗-値： `media-progress^f 記法

`media-progress@f `関数-記法$は、 `progress$f 記法と類似に，［ 指定された`媒体~query$ `MEDIAQUERIES-4$r の現在の値【`実~値$】 ］を［ 当の`媒体~query$用の 2 個の明示的な値 （`進捗~始端~値$, `進捗~終端~値$） の合間における`進捗~値$ ］として表現している `number$t 値 を返す。 ◎ Similar to the progress() notation, the media-progress() functional notation returns a <number> value representing current value of the specified media query [MEDIAQUERIES-4] as a progress value between two explicit values of the media query (as the progress start value and progress end value).

`media-progress$f の構文は： ◎ The syntax of media-progress() is defined as follows:

`media-progress()@t
	= media-progress(`mf-name$t, `calc-sum$t, `calc-sum$t)

［ %始端~値, %終端~値 ］における単位は、 %特能 に指定されたとおりに解釈される （当の関数を利用している文脈により指定されたとおりではなく）。 ◎ The progress start value and progress end value calculations are interpreted as specified for the media feature (rather than as specified by the context the function is used in).

`media-progress$f の値は、 `進捗~関数を計算する$ことにより決定される `number$t になる。 ◎ The value of media-progress() is a <number>, determined by calculating a progress function.

注記： `media-progress$f は、 `number$t に評価される関数に過ぎず，`~math関数$`ではない^em。 ◎ Note: media-progress() is not a math function; it’s just a function that evaluates to a <number>.

5.3. 容器~query進捗-値： `container-progress^f 記法

`container-progress@f `関数-記法$は、 `媒体~特能$に代えて`容器~特能$ `CSS-CONTAIN-3$r を受容することを除いて， `media-progress$f 関数-記法と一致する。 ◎ The container-progress() functional notation is identical to the media-progress() functional notation, except that it accepts container features [CSS-CONTAIN-3] in place of media features.

`container-progress$f の構文は： ◎ The syntax of container-progress() is defined as follows:

`container-progress()@t
	= container-progress(`mf-name$t [ of `container-name$t ]?, `calc-sum$t, `calc-sum$t)

`container-progress$f は、 ~prop値の文脈~内に限り，妥当になる — 他（例：`媒体~query$）では、 利用できない。 ◎ container-progress() is only valid in a property value context; it cannot be used in, for example, a media query.

［ %始端~値, %終端~値 ］は、 %特能 に指定されたとおりに解釈される （当の関数を利用している文脈により指定されたとおりではなく）。 適切な容器が見出されなかった場合、 %特能 の値【！ `size-feature$t ~query】は，`小さい表示域~size$を~~基準に解決される。 ◎ The progress start value and progress end value calculations are interpreted as specified for the size feature (rather than as specified by the context the function is used in). If no appropriate containers are found, container-progress() resolves its <size-feature> query against the small viewport size.

`container-progress$f 【！media-progress()】の値は、 `進捗~関数を計算する$ことにより決定される `number$t になる。 ◎ The value of media-progress() is a <number>, determined by calculating a progress function.

注記： `container-progress$f は、 `number$t に評価される関数に過ぎず，`~math関数$`ではない^em。 ◎ Note: container-progress() is not a math function; it’s just a function that evaluates to a <number>.

6.1. 補間~進捗の表現-法： `progress^t 型

`progress@t 型の値は、 `混合-記法$を成す`混合-進捗~値$を表現する。 それは、最終的に百分率に解決されるが， 媒体~queryや~animation時列線などの~sourceから取り出した百分率~値を — 補間~用に利用する前に — `~easing関数$を通して変換できる。 ◎ The <progress> value type represents the mix progress value in a mix notation, and ultimately resolves to a percentage. It can, however, draw that percentage value from sources such as media queries and animation timelines, and can also convert it through an easing function before using it for interpolation.

その構文は： ◎ Its syntax is defined as follows:

`progress$t
	= [ `percentage-token$t | `number$t | `animation-timeline$tp ] && [ by `easing-function$t ]?

ここで： ◎ where:

`percentage-token$t

等価な `number$t に算出される — `0%^v は `0^v になり, `100%^v は `1^v になる, 等々。 ◎ Computes to the equivalent <number>: 0% becomes 0, 100% becomes 1, etc.

注記： これは、 `15%^v の様な~literalな百分率しか許容しない。 `calc(100% / 7)^v の様な計算式は、 働かないことになる — それは、 代わりに，［ 百分率を別の型（ `width$p における `length$t など）を~~基準に解決するための通常の規則 ］を利用するよう試みるので。 代わりに `calc(1 / 7)^v の様な式を利用すること。 ◎ Note: This only allows literal percentages, like 15%; calculations like calc(100% / 7) will not work, as they will instead attempt to use the normal rules for resolving a percentage against another type (such as <length>, in width). Use expressions like calc(1 / 7) instead.

`number$t

`混合-進捗~値$を表現する。 ◎ Represents the mix progress value.

注記： これは、［ `progress$f／ `media-progress$f／ `container-progress$f ］記法の利用を許容することに注意。 ◎ Note: This allows the use of the progress(), media-progress(), and container-progress() notations.

`animation-timeline$tp

指定された`~animation時列線＠~WANIM#timelines$の進捗†として`混合-進捗~値$を表現する。 ただし，値［ `none＠~CSSANIM2#valdef-animation-timeline-none$v, `auto＠~CSSANIM2#valdef-animation-timeline-auto$v ］は妥当でない。 `CSS-ANIMATIONS-2$r `WEB-ANIMATIONS-2$r ◎ Represents the mix progress value as the progress of the specified animation timeline. The values none and auto, however, are invalid. [CSS-ANIMATIONS-2] [WEB-ANIMATIONS-2]

【† `開始-時刻$から`終止-時刻$までにおける`現-時刻$の進捗~率を表すように思われるが、 はっきりしない。 】

`easing-function$t

指定された`~easing関数$ `CSS-EASING-1$r を利用して， 指定された入力`混合-進捗~値$を出力`混合-進捗~値$へ変換する。 ◎ Converts the specified input mix progress value into an output mix progress value using the specified easing function. [CSS-EASING-1]

注記： ［ `0^v 以上 `1^v 以下 ］でない進捗~値も妥当であり、［ 始端~値, 終端~値 ］により定義される範囲を超える補間を表現することを許容する。 ◎ Note: Progress values below 0 and above 1 are valid; they allow representing interpolation beyond the range defined by the start and end values.

注記： `progress$t 自体は， `percentage$t であり得るが、［ `progress$f の様な `number$t へ`解決され^emる関数を等価な `number$t へ直に対応付ける ］ときは， `percentage$t を当の文脈~用の通常の規則を利用して解決する。 例えば、 `width$p においては，ある長さを~~基準に解決されることになる。 ◎ Note: While <progress> itself can be a <percentage>, mapping directly to the equivalent <number>, a function that resolves to a <number>, like progress(), resolves <percentage>s using the normal rules for the context; for example, in width, they would be resolved against a length.

`progress$t 値の`算出d値$は、［ `percentage$t ／ `number$t ］を伴って指定された場合は `number^t の算出d値になり， `animation-timeline$tp を伴って指定された場合には `animation-timeline$tp の算出d値になる — いずれも、 `easing-function$t が与えられた場合は，それを通して変換される。 ◎ The computed value of a <progress> value specified with <percentage> or <number> is the computed <number> converted through the <easing-function> (if any). The computed value of a <progress> value specified with <'animation-timeline'> is the computed <'animation-timeline'> and <easing-function> (if any).

6.2. 補間された数量-値： `calc-mix^f 記法

`calc-mix@f `混合-記法$ は、 補間された数量-値（次元を伴い得る数）を表現する。 【！Like `calc$f 】 それは、 次の構文-形を伴う`~math関数$である： ◎ The calc-mix() mix notation represents an interpolated numeric or dimensional value. Like calc(), it is a math function, with the following syntactic form:

`calc-mix()@t
	= calc-mix( `progress$t, `calc-sum$t, `calc-sum$t )

入力を成す 2 つの`計算式$ %計算式たち は、 それを成す各~計算式は［ `number$t, `dimension$t, `percentage$t ］いずれにも解決され得るが， %計算式たち は`一貫した型を有して$いなければナラナイ — さもなければ、 当の関数は無効になる。 当の関数の`型$は、 次の結果になる ⇒ `型を入力と一貫させる$( %計算式たち の`一貫した型$, 入力を成す `progress$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 <progress> value.

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

• `使用~値$は、 所与の 2 個の `calc-sum$t 値を所与の `progress$t による進捗へ補間した結果になる。 ◎ The used value of a valid calc-mix() is the result of interpolating these two values to the progress given by <progress>.＼

• `算出d値$は：

  • 所与の `progress^t が ある `number$t 値 %進捗 に算出できる場合、 所与の 2 個の `calc-sum$t の算出d値 ( %A, %B ) を %進捗 へ補間した結果になる （言い換えれば、 %A ~PLUS ( %B ~MINUS %A ) ~MUL %進捗 になる）。
  • 他の場合、 そのまま `calc-mix^f 記法になるが， その各~引数は各自の型に則って算出される。
  ◎ If the <progress> value can be computed to a <number>, then the computed value is likewise the result of interpolating the two computed values to that <progress> value (in other words, A * (1-progress) + B * progress) it is otherwise the calc-mix() notation itself with its arguments each computed according to their type.

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

この仕様は、 `color-mix$f `関数-記法$を［ 次の構文【を成す 1 個目の `color-mix^f 】を受容する`混合-記法$ ］で拡張する： ◎ This specification extends the color-mix() functional notation as a mix notation accepting the following syntaxes:

`color-mix$f
	= color-mix( [ `progress$t && `color-interpolation-method$t? ], `color$t, `color$t )
	| color-mix( `color-interpolation-method$t, [`color$t && `percentage [0,100]$t?]#{2} )

1 個目の `color-mix^f 記法の使用~値は、［ 所与の `progress$t 値を `percentage$t で表す値 %進捗 ］を［ 2 個目の `color-mix^f 内の 2 個目の `color$t 引数に伴われる `percentage$t ］にアテガうことと等価になる。 すなわち、 color-mix( %進捗, %色, %もう一つの色 ) は， color-mix(…†, %色, %もう一つの色 %進捗 ) と等価になる。 2 個目の `color-mix^f 用の規範的な定義は、 `CSS-COLOR-5$r `§ 色の混合-法＠~CSSCOLOR5#color-mix$ を見よ。 ◎ The used value of the first mix notation variant is equivalent to assigning the <progress> value, as a <percentage>, to the <percentage> of the second <color> argument in the second variant. That is, color-mix(progress, color1, color2) is equivalent to color-mix(color1, color2 progress). See CSS Color 5 § 3 Mixing Colors: the color-mix() Function for the normative definition of the second variant.

【† `color-interpolation-method$t を省略した場合の挙動が不明 （本当は省略可能でない？）。 】

`progress$t は［ 0% 以上 100% 以下 ］の外側にある百分率を返すことを許容するが、 【 2 個目の】 `color-mix$f は そのような値を許容しないので， それをどう処理するか定義する必要がある。 ◎ <progress> allows returning percentages outside 0-100%, but color-mix() doesn’t allows such values, so need to define how that gets processed.

6.4. 補間された 画像~値： `cross-fade^f 記法

この仕様は `cross-fade$f `関数-記法$を［ 次の構文【を成す 1 個目の `cross-fade^f 】を受容する`混合-記法$ ］で拡張する： ◎ This specification extends the cross-fade() functional notation as a mix notation accepting the following syntaxes:

`cross-fade$f
	= cross-fade( `progress$t, [ `image$t | `color$t ], [ `image$t | `color$t ] )
	| cross-fade( `cf-image$t# )

1 個目の `cross-fade^f の`使用~値$は、［ 所与の `progress$t 値を `percentage$t で表す値 %進捗 ］を［ 2 個目の `cross-fade^f 内の 2 個目の `cf-image$t 【！`color^t】引数を成す `percentage$t ］にアテガうことと等価になる。 すなわち、 cross-fade( %進捗, %画像, %もう一つの画像 ) は， cross-fade( %画像, %もう一つの画像 %進捗 ) と等価になる。 2 個目の `cross-fade^f 用の規範的な定義は、 `CSS-IMAGES-4$r `§ 画像の組合n＠~CSSIMAGE4#cross-fade-function$ を見よ。 ◎ The used value of the first mix notation variant is equivalent to assigning the <progress> value as the <percentage> of the second <color> argument in the second variant. That is, cross-fade(progress, image1, image2) is equivalent to cross-fade(image1, image2 progress). See CSS Images 4 § 2.6 Combining images: the cross-fade() notation for the normative definition of the second variant.

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

`transform-mix@f `混合-記法$は、 `補間-＠~TRANSFORM#interpolation-of-transforms$された `transform-list$t を表現する。 それは、 次の構文-形を伴う： ◎ The transform-mix() mix notation represents an interpolated <transform-list>, with the following syntactic form:

`transform-mix()@t
	= transform-mix( `progress$t, `transform-list$t, `transform-list$t )

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

• `使用~値$は、 所与の 2 個の `transform-list$t 値を所与の `progress$t による進捗へ補間した結果になる。 ◎ The used value of a valid transform-mix() is the result of interpolating these two values to the progress given by <progress>.＼

• `算出d値$は：

  • ［ 所与の `progress^t が `percentage$t に【！can be】算出される ］かつ［ 所与の 2 個の `transform-list$t を使用~値の時点での情報なしに補間できる ］場合、 所与の 2 個の `transform-list$t の算出d値を所与の `progress^t 値へ補間した結果になる。
  • 他の場合、 そのまま `transform-mix^f 記法になるが， その各~引数は各自の型に則って算出される。
  ◎ If the <progress> value can be computed to a <percentage>, and the <transform-list>s can be interpolated without used-value-time information, then the computed value is likewise the result of interpolating the two computed values to that <progress> value; 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>.

【 `transform-list^t どうしを補間した結果は， 一般に変形~関数たちが成す~listになるので、 これは不正確に見えるが、 ~listを成す変形~関数をすべて累積した結果を成す 1 個の `transform-function^t として解釈されるのかもしれない。 】

6.6. 補間された~prop値： `mix^f 記法

所与の~prop用の 2 個の値の`補間$は、 `mix@f `混合-記法$により表現できる — それは、 2 つの代替な構文~patternを~supportする： ◎ Interpolation of any two property values can be represented by the mix() mix notation, which supports two alternative syntax patterns:

`mix()@t
	= mix( `progress$t , `whole-value$t? , `whole-value$t? )
	| mix( `progress$t && of `keyframes-name$t )

1 個目の構文~代替は、 他の`混合-記法$と同様に，［ `混合-始端~値$を与える 1 個目の `whole-value$t, `混合-終端~値$を与える 2 個目の `whole-value$t ］の合間において補間する。 2 個目の構文~代替は、 より複階的な補間~曲線を許容するため†， ~keyframeたちが成す集合††から対応している~prop宣言†††たちを`混合-進捗~値$を利用して補間する。 ◎ The first syntax alternative, like other mix notations, interpolates between the first <whole-value> (its mix start value) and the second <whole-value> (its mix end value). The second uses the mix progress value to interpolate the corresponding property declarations from a set of keyframes, allowing for more complex interpolation curves.

【†† `keyframes-name$t で識別される `keyframes$at 規則を成す`~keyframe~style規則$たちを指すと思われる。 】【††† この関数を値に利用している~propと同じ名前を伴う~prop宣言を指すと思われる。 】【† 各~keyframeにて指定された［ `~keyframe選択子$／`~easing関数$ ］も織り込まれることを意図していると思われる。 】

`mix$f の`算出d値$は、 次に従う： ◎ ↓

• 1 個目の “標準な” `mix^f 記法で指定されていて，［ 2 個の `whole-value$t が，それを指定した~prop用の値として補間-可能である ］かつ［ 補間した結果は `mix$f を伴わずに表現できる ］場合 ⇒ それら 2 個の値を［ `progress$t により与えられた進捗 ］へ補間した結果になる。 ◎ For the standard mix notation variant, if the two <whole-value>s being interpolated by mix() are interpolable as values for the property in which it is specified, and the interpolated value can be represented without mix(), the computed value of mix() is the result of interpolating these two values to the progress given by <progress>.＼

• 他の場合 ⇒ そのまま `mix^f `関数-記法$になるが、 その引数のうち `progress$t 値は算出され， `whole-value$t は（供されたなら）［ 当の~prop用の値 ］として算出される。

  【 2 個目の `mix^f 記法で指定された場合も，この場合に含まれるように思われる。 】

  ◎ Otherwise, the computed value of mix() is the mix() functional notation itself with its <progress> value computed and its <whole-value>s (if provided) computed as values for this property.

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

color: mix(90%, currentcolor, 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: mix(90%, left, right);
/* 
離散的に~animate可能
◎
discretely animatable
 */
float: right;

transform: mix(90%, translate(calc(1em + 50%)), rotate(30deg));
/* 
2 つの関数は合致しないので，
`matrix^f を介して補間されることになるが、
`translate^f は百分率を伴うので，
`matrix^f に転換するためには~layout情報が必要になる。
なので、
補間した値を実際には表現し得ない。
その結果、
次【の様な形】に算出される：
◎
because functions don’t match, it will interpolate via matrix(). But translate(%) needs layout information to turn into a matrix(), so the interpolated value can’t actually be represented. Computes to:
 */
transform: mix(90%, translate(calc(16px + 50%)), rotate(30deg));
transform: mix(90% of ripple);

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

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

/* 
`mix^f 関数が~propの値~全体を成していない
◎
Function is mixed with other values
 */
background: url(ocean) mix(10%, blue, yellow);

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

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

この仕様が定義するいくつかの関数は、 所与の~propの “値~全体を成す” 場合にしか利用できない。 例えば、 `background-position:toggle(50px 50px, center)$p は妥当であるが， `background-position:toggle(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: toggle(50px 50px, center); is valid, but background-position: toggle(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.

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

~CSSは、 前方-互換な構文解析により漸進的な増補を~supportする。 作者は，~style規則~内で同じ~propを複数回 — 各~回に異なる値を利用しながら — 宣言でき、 ~CSS~UAは， それらのうち自身が解する最後のものを自動的に利用して，それ以外を棄てる。 この原則は、 `supports$at 規則との~~併用により，［ 旧い~UA, 新たな~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>.

7.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( [ `args-branch$t ; ]* `args-branch$t ;? )
`args-branch@t
	= `declaration-value$t : `declaration-value$t?

注記： ［ `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.

【† `revert-rule^v がどこで定義されるのか不明： `revert＠~CASCADE#valdef-all-revert$v や `revert-layer＠~CASCADE#valdef-all-revert-layer$v の誤記？ これらの総称？ 本当は “`revert^v 用の規則” を意味する？ 今後~定義される予定にある未知な値？ 】

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

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

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

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

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

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

`toggle$f 記法は、 `whole-value$t である。 しかしながら、 入子にできないことに加え，［ `attr$f ／ `calc$f ］記法も包含できない — そのような構成子を包含している宣言は無効になる。 ◎ The toggle() 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 toggle(50px, 100px);
/* 
`toggle$f は~propの値~全体を成していなければナラナイ。
◎
toggle() must be the sole value of the property
 */

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

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

注記： `toggle$f は，明示的に親の算出d値を調べるので、 継承されない~propであっても働く。 このことは、 継承されない~propに対しても働く `inherit$v ~keywordと類似する。 ◎ Note: That toggle() 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.

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

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

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

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

7.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]

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

7.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
	| `attr-unit$t
`type()@t
	= type( `syntax$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 生成規則は、 ~OR↓ を満たすものに合致する： ◎ The <attr-unit> production matches＼

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

単位たちが成す集合は時間~越しに拡がるので、 この生成規則は，ここでは~literalに【各~単位を列挙するように】は展開されない。 ◎ It is not expanded literally here, as the set of units expands over time.

`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 が文字大小区別かどうかは，文書~言語に依存する。 ◎ As with attribute selectors, the case-sensitivity of <attr-name> depends on the document 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列が代入される。 構文解析に失敗した場合、 ~fallbackが誘発される。 ◎ If given as a type() function, the value is parsed according to the <syntax> argument, and substitutes as the resulting tokens. Values that fail to parse according to the syntax trigger fallback.

`attr-unit$t 値として与えられた場合、 当の属性の値【！the value】は，まず［ `type(<number>)^v が指定された ］かのように `number$t として構文解析される。 結果の数量-値は、 所与の単位を伴う次元 — あるいは `%^v が与えられた場合は百分率 — へ転換される。 構文解析に失敗した場合、 ~fallbackが誘発される。 ◎ If given as an <attr-unit> value, the value is first parsed as if type(<number>) was specified, then the resulting numeric value is turned into a dimension with the corresponding unit, or a percentage if % was given. Values that fail to parse as a <number> trigger 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 引数が省略された場合†は 空~文字列／ ~ELSE_ `無効が保証される値$ ］になる。

【† 前項と違って， `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.

div {
  width: attr(data-foo type(*));
}

<div data-foo="attr(data-foo type(*))"></div>

div {
  --x: var(--y);
  --y: attr(data-foo type(*));
}

<div data-foo="var(--x)"></div>

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

`ident@f 関数は、 `ident$t を表現する — それは、 いくつかの部分から `custom-ident$t 値を手動で構築するために利用できる。 ◎ The ident() function represents an <ident>, and can be used to manually construct <custom-ident> values from several parts.

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

~fallback値を許容するべきか？ [`11424$issue] ◎ Should we allow a fallback value? [w3c/csswg-drafts Issue #11424]

`ident$f 関数は、 `custom-ident$t を受容する どの［ ~prop／関数~引数 ］用の値としても利用できる。 ◎ The ident() function can be used as a value for any property or function argument that accepts a <custom-ident>.

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

多くの事例では，［ `attr-type$t が type(`custom-ident$t) に設定された `attr$f ］で用を成すが、 `ident$f を利用すれば，他の要素から来る値を利用して `custom-ident$t を構築できる。 ◎ While in many cases attr() with the <attr-type> set to type(<custom-ident>) will do, ident() can be used to construct a <custom-ident> using values that come from other elements.

.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));
}

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

`random@f 関数は、 `~math関数$であり， ある範囲内で一様に分布する~randomな値を表現する†。 それはまた、 任意選択で，アリな値を［ 最小~値からの差が，ある段差の整数倍になる ］よう制限できる。 その構文は： ◎ 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:

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

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

`random-value-sharing@t
	= [ [ `auto$v | `dashed-ident$tv ] || `match-element$v ]
	| `fixed$v `number [0,1]$t

この関数が どう評価されるかについての詳細は、［ `§ ~random値の評価-法$, `§ ~random値の~cache法$ ］を見よ。 ◎ See § 8.3 Evaluating Random Values and § 8.4 Caching Random Values: the <random-value-sharing> value for details on how the function is evaluated.＼

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

`random-value-sharing$t

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

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

`random-value-sharing$t を成す各~optionの詳細は、 下を見よ。 それらの挙動の精確な記述は、 `§ ~random値の~cache法$ を見よ。 ◎ See below for details on the <random-value-sharing> options, and see § 8.4 Caching Random Values: the <random-value-sharing> value for a precise description of their behavior.

`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 § 8.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.

`random-value-sharing$t 値は、 2 通りの共有-法を制御する： ◎ The <random-value-sharing> value controls sharing along two axises:

• 同じ要素に適用される~style内の異なるもの用に利用される`~random関数$どうし — ［ `auto$v ／ `dashed-ident$tv ］値を介して。 ◎ between random functions used for different things in the style for a single element, via the auto or <dashed-ident> values
• いくつかの要素に適用される~style内の同じもの用に利用される`~random関数$どうし — `match-element$v 値（または，その不在）を介して。 ◎ between random functions used for the same thing in the styles across several elements, via the match-element value (or its absence)

`auto@v

同じ要素に適用される各~style内の各`~random関数$は、 別個な`~random基底~値$を利用することになる。 （が、 これについての `small wrinkle^en は， `下の注記＠#auto-naming-details$を見よ。） ◎ Each random function in an element’s styles will use a distinct random base value. (But see the note below for a small wrinkle about this.)

［ `auto$v, `dashed-ident$tv ］どちらも指定されなかった場合、 `auto$v として挙動する。 ◎ If neither auto nor <dashed-ident> are specified, it behaves as auto.

`dashed-ident$t

同じ要素に適用される各~style内の各`~random関数$のうち ⇒＃ 同じ `dashed-ident$tv を伴うものどうしは，同じ`~random基底~値$を共有することになる。 異なる `dashed-ident$tv を伴うものは，別個な`~random基底~値$を利用することになる。 ◎ Each random function in an element’s styles with the same <dashed-ident> will share the same random base value; ones with different <dashed-ident>s will use distinct random base values.

`match-element@v

省略された場合、 `~random関数$は，要素ごとに別個な`~random基底~値$を利用することになる。 ◎ If match-element is omitted, random functions on different elements will use distinct random base values.

指定された場合、 `~random関数$のうち：

• 同じ `dashed-ident$tv が指定されたものどうしは、 要素たちにわたって同じ`~random基底~値$を共有することになる。
• `dashed-ident$tv が指定されなかったものどうしは、 同じ~style内で同じ仕方【？】で利用されたならば， 要素たちにわたって同じ`~random基底~値$を共有することになる。 （が、 これについての `small wrinkle^en は， `下の注記＠#auto-naming-details$を見よ。）

◎ If specified, random functions on different elements will share the same random base value if they have the same <dashed-ident> (if specified) or if they’re used in the same style in the same way (if not). (Again, see the note below for a small wrinkle about this.)

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

指定された場合、 所与の `number^t 値は，当の`~random関数$の`~random基底~値$として利用される — ［ `~random基底~値$を生成すること, それがどう共有されるか制御すること ］を~UAに許容することなく。 ◎ If fixed <number> is specified, the <number> is used as the random function’s random base value, rather than allowing the UA to generate a random base value and controlling how it’s shared.

`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。 が、 それ【~UAが生成する`~random基底~値$】が存在する理由は， `継承＠~CASCADE#inheritance$における，ある際どい事例 — 作者の期待に反して，要素たちが`~random基底~値$を`共有しなく^emなるような事例 — を修正するためにある。 それは、 ある稀な`算出d値$においては観測-可能になるが， それ以外では要素の~style内には決して~~現れない。 ◎ Note: While this 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(match-element, 100px, 200px);
}
.bar {
  width: random(match-element, 200px, 300px);
}

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

入力を成す`計算式$たちは、［ 各~計算式は、 どの値にも解決され得る ］が，`一貫した型を有して$いなければナラナイ — さもなければ、 当の関数は無効になる。 当の関数の`型$は、 当の計算式たちの`一貫した型$になる。 ◎ 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.

`random$f 関数は、 引数として与えた`計算式$たちを数量-値に`単純~化＠~CSSVAL#simplify-a-calculation-tree$できるようになり次第，単純~化できる。 それがどう解決されるについての詳細は、 `§ ~random値の~cache法$ を見よ。 ◎ A random() function can be simplified as soon as its argument calculations can be simplified to numeric values. See § 8.4 Caching Random Values: the <random-value-sharing> value for details on how it’s resolved.

`random$f 関数を`算出d値$の時点では`単純~化＠~CSSVAL#simplify-a-calculation-tree$できない場合、［ 当の関数の `random-value-sharing$t が，その`~random基底~値$へ設定される ］ことを除いて，最大限に単純~化された形へ算出される。 ◎ If a random() function can’t be simplified by computed value time, then it computes to its maximally-simplified form, but with its <random-value-sharing> set to its random base value.

少なくとも理論~上は、 ~prop以外の文脈で `random$f を利用しても，大丈夫なはずである — その`~random~cache用~key$の`要素~ID$rCは ~NULL に設定されるだけであり、 必要yなら，適切な記述子~等に基づいて`名前$rCを算出することになる。 `media^at (max-width: random(100px, 500px)) {...} の様なものに対しては、 ~cache用~keyの`名前$rCを "@media max-width 1" の様な何かにすることで，きちんと定義できる。 とは言え、 それを許容することが求まれるのかどうかは，疑わしい。 ◎ At least in theory it should be fine to use random() in non-property contexts, it would just set the "element id" of the caching key to null, and, if necessary, compute an appropriate descriptor/etc-based caching key. Like, @media (max-width: random(100px, 500px)) {...} could be well-defined; the caching key is just "@media max-width 1" or something. I suspect we want to disallow it, tho?

8.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 § 8.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.

8.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-value-sharing$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値の~cache法$ ］を見よ。 ◎ See § 8.3 Evaluating Random Values and § 8.4 Caching Random Values: the <random-value-sharing> value for details on how the function is evaluated.＼

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

注記： `random-value-sharing$t 引数が `random$f においては省略可能な一方， `random-item$f においては要求される理由は、 構文解析にある （ `random-item(--foo, --bar, --baz)^v が［ 3 個の `declaration-value$t 引数をとる ］のか［ 2 個のそれと `random-value-sharing$t 引数をとる ］のか伝えることはアリでない）。 ◎ Note: The <random-value-sharing> 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-value-sharing> argument).

残りの引数は、 ~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().

8.3. ~random値の評価-法

8.4. ~random値の~cache法： `random-value-sharing$t 値

~JSの様な~programming言語においては， ~code内に明瞭な時間的~順序付けが在るので、 `Math.random()^c に対する~callの様なものが`いつ評価されるか^emを正確に伝えれる。 結果は変数~内に格納できるので、 複数の箇所で［ 単独の~random値を再利用しているのか，別個な~random値を利用しているのか ］は，明瞭になる。 ◎ In a programming language like JavaScript, there’s a clear temporal ordering to code, so you can tell exactly when something like a call to Math.random() is evaluated. You can also store the results in a variable, making it clear when you’re reusing a single random value in multiple places, versus using a distinct random value in each location.

他方，~CSSは宣言的な言語なので （~codeは、 特定0の順序で “実行される” ことはなく， 何かが何回 “実行されるか” に対する制御も無い）、 同じ~styleを複数の要素に適用することは，ごく容易であるが： ◎ CSS, on the other hand, is a declarative language (code is not "executed" in any particular order, nor is there any control over how many times something is "executed");＼ it makes it very easy to apply identical styles to multiple elements but＼

• 各~要素に別個な値を指定することは困難である （ `random$f が［ それを値に利用している~propが適用される各~要素 ］に対し［ 同じ値, 別個な値 ］どちらに解決するよう意味されるかは、 不明瞭である）。 ◎ difficult to specify distinct values for each of them (making it unclear whether a property using random() is meant to resolve to the same value on each element it’s applied to or to distinct values on each);＼
• “変数” の機能性は，ごく制限される （特定0の［ ~randomに生成された値 ］を何箇所かで意図的に再利用することは、 困難である）。 ◎ and it has very limited "variable" functionality (making it difficult to intentionally reuse a particular randomly-generated value in several places).

これらの課題を解決するため、 `~random関数$【！the random() and random-item() functions】は， 次に挙げる［ ~cache法の意味論 ］の下で~random値を生成するものと定義される： ◎ To resolve these issues, the random() and random-item() functions are defined to generate random values under the following caching semantics:

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

  • %関数 の `random-value-sharing$t に `fixed$v と伴に `number$t が指定された場合、 それ ◎ If the random function’s <random-value-sharing> 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 caching key.

• 各`~random関数$【の各~利用】は、 `~random~cache用~key@ も指定する。 2 つの`~random関数$の`~random基底~値$は、 【 `number^t として明示的に与えられた場合（前項）を除いて】 互いの`~random~cache用~key$が同じならば同じになり， 異なるならば別個になる （すなわち，ある新規な~random演算により生成される） モノトスル （もちろん、 ~randomなので，実際に生産する値は同じになるかもしれないが）。 ◎ Each random function also specifies a random caching key. Two random functions with the same random caching key must also have the same random base value; two functions with different random caching keys 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用~key$を`どう利用する^emかは、 意図的に未指定である。 生成された~random値を そのまま~cacheすることも， 疑似-~random生成器~用の~seedとして利用すること, 等々もできる。 ◎ It is intentionally unspecified how the random caching key 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用~key$が同じならば同じ`~random基底~値$を取得することになる （本当か？）。 】

• 各 `~random~cache用~key$は、 ( `名前$rC, `要素~ID$rC, `文書~ID$rC ) が成す`~tuple$である： ◎ A random caching key is a tuple of:

  `名前@rC （`文字列$） ◎ A string name:＼

  `random-value-sharing$t 内に `dashed-ident$tv が指定された場合、 その値になる。 ◎ the value of the <dashed-ident>, if specified in <random-value-sharing>;＼

  他の場合、 次を順に連結した結果になる：

  1. 当の`~random関数$を値に利用している~prop %~prop の名前 — 略式~propの展開が関連する場合は，それ`よりも前^emに
  2. 1 個の~space
  3. 当の`~random関数$が，値の中で %n 個目に利用された`~random関数$とするとき、 %n ~MINUS 1【を表現している最短な`~ASCII数字$並び】

  ◎ or else a string of the form "PROPERTY N", where PROPERTY is the name of the property the random function is used in (before shorthand expansion, if relevant), and N is the index of the random function among other random functions in the same property value.

  `要素~ID@rC ◎ An element ID＼

  当の関数の `random-value-sharing$t において `match-element$v が指定された場合、 ~NULL になる。 ◎ ↓

  他の場合、 当の【関数を利用している】~styleが適用される`要素$を識別するもの — 当の`要素$への~JS参照と等価になるもの — になる。 ◎ identifying the element the style is being applied to,＼ or null if match-element is specified in <random-value-sharing>.

  【 当の~styleが疑似要素に適用される場合、 `最終的な出自の要素$が対象になるのか, 本当は “要素または疑似要素を識別するもの” として定義されるべきなのか， はっきりしない。 】

  `文書~ID@rC ◎ A document ID＼

  当の【関数を利用している】~styleが属する`文書$を識別するもの — 当の文書への~JS参照と等価になるもの — になる。 ◎ identifying the Document the styles are from.

  `要素~ID$rCの存続期間は、 `文書~ID$rCと同じになるモノトスル。 ◎ The "element ID" and "document ID" must have the same lifetimes＼ ↑ and equivalence as a JavaScript reference to the Element or Document.

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

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

.random-square {
  width: random(--foo match-element, 100px, 500px);
  height: random(--foo match-element, 100px, 500px);
}

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

.same-tb-and-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);
}

10.1. `calc-size^f の単純~化-法

`~calc-size計算式$は （および、 `~calc-size基底s$が `calc-sum$t である場合は，それも）、［ `指定d値$, `算出d値$ ］どちらの時点でも，アリな限り単純~化される — `~math関数$と類似に， `~level 4$ の `§ 単純~化＠~CSSVAL#calc-simplification$ にて定義されるとおりに。 ◎ Similar to math functions, at both specified value and computed value times the calc-size calculation (and the calc-size basis, if it’s a <calc-sum>) are simplified to the extent possible, as defined in CSS Values 4 § 10.10.1 Simplification.

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

`calc-size$f は — 以下、［ %基底s は その`~calc-size基底s$, %計算式 は その`~calc-size計算式$ ］を指すとする： ◎ ↓

• すべてに関して， %基底s であったかのように扱われる （未指定な`確定的~size$として動作する）。 ◎ A calc-size() is treated, in all respects, as if it were its calc-size basis (with any acting as an unspecified definite size).
• しかしながら，実際に~layout計算を遂行するときには、 %基底s が表現する~sizeは， %計算式 の値へ改変される — %計算式 内の各 `size$vC ~keywordを［ %基底s の元の~size ］に評価する下で。 ◎ When actually performing layout calculations, however, the size represented by its calc-size basis is modified to be the value of its calc-size calculation, with the size keyword evaluating to the calc-size basis’s original size.
• %基底s が `any@vC をとる場合、［ %計算式 に等しい長さ ］を与える`確定的~size$になる。 ◎ (If the calc-size basis is any, the calc-size() is a definite length, equal to its calc-size calculation.)

`~calc-size計算式$を評価するときは、［ 所与の文脈において百分率は確定的でない場合 ］には `0px^v 解決され， 他の場合は通常通り解決される。 ◎ When evaluating the calc-size calculation, if percentages are not definite in the given context, they resolve to 0px. Otherwise, they resolve as normal.

（ `~calc-size基底s$における百分率の扱いは他と異なる： `単純~化＠#simplifying-calc-size$は、 百分率を`~calc-size計算式$の中へ移動すると伴に，それを `size$vC 参照で置換する。 その結果，`~calc-size基底s$は、 `100%^v になる。 それは、［ 何であれ，当の文脈における `100%^v に対する通常の挙動 ］と同じに挙動する — それが［ 場合によっては、 ~propは`~autoとして挙動する$ ］ようになる場合, 等々も含めて。） ◎ (A percentage in the calc-size basis is treated differently; simplification moves the percentage into the calc-size calculation and replaces it with size references. The calc-size basis then becomes 100%, behaving as whatever 100% would normally do in that context, including possibly making a property behave as auto, etc.)

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

`calc-size$f 値には［ `length-percentage$t ／ `intrinsic-size-keyword$t ］値 %値 と補間できるものもある。 ［ これらの値を補間できるかどうか, できる場合の補間の挙動 ］を決定するときは、 %値 を［ %値 は `calc-sum$t として与えられた場合は calc-size(`any$vC, %値 ) ／ ~ELSE_ calc-size( %値, `size$vC) ］として扱う下で，上の規則を適用する。 ◎ Some calc-size() values can also be interpolated with a <length-percentage> or an <intrinsic-size-keyword>. To determine whether the values can interpolate and what the interpolation behavior is, treat the non-calc-size() value as calc-size(any, value ) if the value is a <calc-sum> 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$f は、 calc-size(any, `確定的~size$) と他の何かの間で — “他の何か” がどう指定されたかに関わらず — `常に^em滑らかに遷移することになるよう設計された。 ◎ Note: calc-size() is designed such that transitioning to/from calc-size(any, definite length) will always work smoothly, regardless of how the other side of the transition is specified.

注記： この “素な値【上で述べた %値 】を `calc-size$f へ昇格する” 挙動は、 `~calc-size計算式$の中へ `length-percentage$t 値を置く。 これは，［ 百分率を伴う値と内在的~size~keyword ］を補間することを許容するが、 当の百分率は`確定的~size$でない場合， それは 0 へ解決されるようになることを意味する。 【作者は，】百分率が［ 要素の実際の~sizeを~~基準に解決される ］ようになることを求める場合には、 `calc-size^f の`~calc-size基底s$において，明示的に値を与えること — `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).

10.4. ~sizing~keywordの補間-法： `interpolate-size^p ~prop

注記： 過去に戻れたなら、 この~propは必要なかった。 これが存在するのは、 既存の多くの~stylesheetが［ 内在的~sizing~keyword（ `~autoS$v, `min-content$v, 等々）は~animateし得ない ］ものと見做すからである。 したがって，この~propは、［ ~stylesheetが，期待される挙動を取得するよう選ぶ ］ことを許容するために存在する。 根~要素に `interpolate-size:allow-keywords$p を指定した場合、 ~page全体~用に新たな挙動を選ぶことになる。 互換性が課題にならないときは、 そうすることが示唆される。 ◎ Note: If we had a time machine, this property wouldn’t need to exist. It exists because many existing style sheets assume that intrinsic sizing keywords (such as auto, min-content, etc.) cannot animate. Therefore this property exists to allow style sheets to choose to get the expected behavior. Specifying interpolate-size: allow-keywords on the root element chooses the new behavior for the entire page. We suggest doing this whenever compatibility isn’t an issue.

`numeric-only@v

`intrinsic-size-keyword$t は、 補間できない。 ◎ An <intrinsic-size-keyword> cannot be interpolated.

`allow-keywords@v

`intrinsic-size-keyword$t は、 `length-percentage$t との間でも補間できる。 これは、 所与の `intrinsic-size-keyword$t %~keyword に対し，［ %~keyword は `calc-size(~keyword, size)^v であった ］かのように扱う下で［ `calc-size$f の`補間-法＠#interp-calc-size$を適用する ］ことにより行われる。 `length-percentage^t 以外の値とは，依然として補間できない。 ◎ Two values can also be interpolated if one of them is an <intrinsic-size-keyword> and the other is a <length-percentage>. This is done by treating the <intrinsic-size-keyword> keyword as though it is calc-size(keyword, size) and applying the rules in § 10.3 Interpolating calc-size(). In other cases, an <intrinsic-size-keyword> still cannot be interpolated.

`interpolate-size$p の値が問われるものは、 ~animationが開始するかもしれない時点における当の要素の【他の~propの】算出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.

代入

各種 `任意-代入~関数$は、 `任意-代入~関数を置換する@ 方法を［ 所与の ( 引数たちが成す~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.

注記： 例えば， `if$f 関数~用の`置換する~algo＠#replace-an-if-function$を見よ。 ◎ Note: See, for example, replace an if() function.

`任意-代入~関数$は、 解決されるに伴い，`代入~文脈$たちを累積する — それは、 `入子な^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:

• ( `property^l, ある~prop名のみ ) ◎ "property", followed by a property name
• ( `attribute^l, ある属性~名のみ ) ◎ "attribute", followed by an attribute name

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

`代入~文脈$が `循環な代入~文脈@ であるとは、 各`代入$の呼出nにより確立された［ “~stack内の~higher” にある`代入~文脈$ ］のうちいずれかに合致することをいう。 ◎ A cyclic substitution context is a substitution context which matches one of the substitution contexts established by a substitution invocation "higher in the stack".

.foo {
  --one: var(--two);
  --two: 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.

＊ 各~関数~用の~its＊解決~algoにおいては、 ~will 各~引数たちに`代入$を適用した結果を標準な文法を成す適切な各部の`文法に則って構文解析-$することになる。 しかしながら、 それは，この処理nの制御-下にあるので、 一部の引数は［ 解決されない, かつ構文解析されない ］まま残されることもある。 ◎ Each function, in its resolution 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(--foo));
}

このことは、 関数の`引数~文法$に則った構文解析は， 入子な`任意-代入~関数$の結果【当の関数を置換することになる値】を普通は`見ない^emことも意味する。 関数の内容は、 関数の内側に そのままに在る引数たちへ~divideされた値にしか基づかない。 ◎ 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 を伴わせることにより＊対処できる それは、 次を指示する ⇒ 当の関数を “早期” に — 【それを入子にしている関数の】引数たちへの~divisionより前に — 解決するモノトスル。 ◎ 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として認識されない — ~the~periodsは， 代わりに，`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 those functions are themselves syntactically valid, 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.