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-caching-options$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 生成規則が，この~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 【を成す `syntax-string$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.

注記： `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-axis|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$v, `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() notation 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() notation represents the value corresponding to the first condition in its argument list to be true; if no condition matches, then the if() notation represents an empty token stream.

`if$f 記法の構文は： ◎ The if() notation syntax is defined as follows:

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

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

注記： ［ `media$at ／ `supports$at ／ `container$at ］規則は，その条件が `偽^i に評価されたときには［ その内容は無視されるだけになり， 値として何を適用するかを~cascadeに決定させる ］が、 それとは違って， `if$f を伴う宣言は、 条件が `偽^i に評価されても，~cascadeは巻戻されない — ~fallback値は、 【必要なら， `if$f の他に】 ~inlineに供する必要がある【！must】。 ◎ 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.

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: That 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値$そのものではなく，それを更に~token化した結果に解決される。 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 the tokenized 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? )

注記： 将来の~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()
	= attr( `attr-name$t `attr-type$t? , `declaration-value$t?)

`attr-name@t
	= [ `ident-token$t? '|' ]? `ident-token$t
`attr-type@t
	= type( `syntax$t )
	| string
	| `attr-unit$t

`attr-unit@t 生成規則は、［ ~CSS次元~単位の名前（例： `px$u ）に`~ASCII大小無視$で合致する`~CSS識別子$／ `%^v を .値にとる `delim-token$t ］に合致する。 単位たちが成す集合は時間~越しに拡がるので、 この生成規則は，ここでは~literalには展開されない。 ◎ The <attr-unit> production matches any identifier that is an ASCII case-insensitive match for the name of a CSS dimension unit, such as px, or the <delim-token> %. 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.

ある［ 要素／疑似要素 ］に適用される~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 関数【！誤：~CSSIMAGE4#funcdef-image-set-type】として与えられた場合、 当の属性の値【！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.

［ `string^v ~keywordとして与えられた／ 省略された ］場合、 当の属性の値は，そのまま~CSS文字列として扱われるようになる — ~CSS構文解析は（［ ~CSS~escape, 空白, ~comment, 等々 ］の除去も含めて），まったく遂行されずに。 ~fallbackが誘発されるのは、 当の属性が欠落ったときに限られる。 ◎ If given as the 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値は：

• `syntax$t 引数が省略された場合†、 空~文字列になる。

  【† `syntax$t 引数は `attr-type$t 引数に更新されたが、 この記述は，それを反映していない。 これは、 `attr-type^t 引数が［ 省略された場合／ `string^v ~keywordをとる場合 ］と解釈するべきに思われる。 】

• 他の場合、 `無効が保証される値$になる。

◎ If the <syntax> 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 関数に`代入-$【！#substitute-an-attr】された後の算出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.1. ~randomな数量-値の生成-法： `random^f 関数

`random@f 関数は、 `~math関数$であり， ある範囲内で一様に分布する~randomな値を表現する。 【以下、この節に現れる~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()^t
	= random(
		`random-caching-options$t? ,
		`calc-sum$t,
		`calc-sum$t,
		[by `calc-sum$t]? )

`random-caching-options@t
	= `dashed-ident$t || per-element

その引数たちは： ◎ Its arguments are:

`random-caching-options$t

省略可能な この引数は、 当の `random$f 関数が［ ~page上の他の `random^f 関数と類似に解決されるか否か ］に対する，いくぶんの制御を供する。 詳細は、 `§ ~randomな値の生成-法／~cache法＠#random-caching$ を見よ。 ◎ The optional <random-caching-options> provides some control over whether a given random() function resolves similarly or differently to other random()s on the page. See § 8.3 Generating/Caching Random Values: the <random-caching-options> value for details.

注記： `random$f 関数は： ◎ ↓

• この引数が省略された場合、［ それを含んだ~styleを利用している要素~すべて ］から共有される単独の値に解決される。 2 つの `random^f 関数は、 互いの引数たちがすべて一致するならば，同じ~randomな値に解決されることになる。 ◎ By default, random() resolves to a single value, shared by all elements using that style, and two random() functions with identical arguments will resolve to the same random value.
• この引数に `dashed-ident$t が供された場合、［ 他の引数は一致する他の `random$f 関数 ］とは別物にして，別個な値を生成させる。 ◎ Providing a <dashed-ident> does nothing, but can make the argument lists distinct between two or more otherwise-identical random() functions, so they’ll generate distinct values.
• この引数に `per-element^v ~keywordが供された場合、 当の関数が適用される`要素ごと^emに異なる値を生成させる — ~stylesheet内での各利用ごとに単独の値に解決されるのではなく。 ◎ The per-element keyword causes the random() function to generate a different value on each element the function is applied to, rather than resolving to a single value per usage in the stylesheet.

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

これら 2 個の要求される`計算式$は、 順に，当の関数を解決した結果がとり得る範囲の［ 最小~値, 最大~値 ］を指定する。 ◎ 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 最小~値 ］の場合、 最大~値は最小~値と等しいものとして挙動する。 ◎ 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.

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

結果が最小~値になることは，常にアリな一方、 最大~値になることは — 最小~値との差が段差の整数倍である場合を除き — アリでない。 例えば，［ `random(100px, 300px, by 30px)^v を解決した結果 ］としてアリな最~大な値は、 `280px^v （ ~EQ 最小~値 ~PLUS 段差 ~MUL 6 ）になる。 ◎ While the minimum value is always a possible result, the maximum value isn’t always, if it’s not also a multiple of the step from the minimum. For example, in random(100px, 300px, by 30px), the largest possible value it can resolve to is 280px, 6 steps from the minimum value.

これには、 丸ngが影響し得ることに注意： `random(100px, 200px, by 100px / 3)^v にアリな値は， 3 通り — `100px^v, 約 `133.33px^v, 約 `166.67px^v — 以上はあるが、 `200px^v がアリになるかどうかは，丸ngの精度に依存する。 安全になるためには、 最大~値を期待される最~大な値より`少し大きく^emすればよい — `random(100px, 201px, by 100px / 3)^v の様に。 ◎ Note that rounding issues might have an effect here: in random(100px, 200px, by 100px / 3) you’ll definitely get three possible values (100px, and approximately 133.33px and 166.67px), but whether 200px is possible depends on rounding precision. To be safe, you can put the maximum value slightly above where you expect the final step to land, like random(100px, 201px, by 100px / 3).

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

• `random(100px, 500px, by 1px)^v は、 解決した結果を `1px^v の整数倍に限るよう制約する。
• `random(1, 10, by 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, by 1px) restricts it to resolving only to whole px values; random(1, 10, by 1) is restricted to resolving only to integers; etc.

注記： 段差の定義は、 素朴に［ 範囲~内の~randomな値を生成した結果を最も近い段差~値に丸める ］ことを許容するもの`ではない^em — そうすると、 結果の各~値は，同じ~~確率で現れなくなるので。 例えば， `random(100px, 200px, by 50px)^v は、 アリな 3 通りの値を同じ 1/3 の~~確率で生成する必要がある — 素朴な丸ngに基づく手法は、 `150px^v を［ 両端を成す他の値 ］の 2 倍の~~確率で生成するので，不正である。 ◎ Note: The definition of the step does not allow for naively generating a random value in the range and then rounding it to the nearest step value, as that can result in the values not appearing with the same weights. For example, random(100px, 200px, by 50px) has to generate the three possible values each with a 1/3 chance; a naive rounding-based method will instead incorrectly generate 150px twice as often as the boundary values.

入力を成す`計算式$たち %計算式たち は、 それを成す各~計算式は［ `number$t ／ `dimension$t ／ `percentage$t ］いずれにも解決され得るが， %計算式たち は`一貫した型を有して$いなければナラナイ 【！but must have the same type（おそらく更新漏れ）】 — さもなければ、 当の関数は無効になる。 当の関数の`型$は、 %計算式たち の`一貫した型$になる 【！have the same type as（おそらく更新漏れ）】。 ◎ All of the calculation arguments can resolve to any <number>, <dimension>, or <percentage>, but must have the same type, or else the function is invalid; the result will have the same type as the arguments.

`random$f 関数は、 引数として与えた`計算式$を数量-値に単純~化できるようになり次第， `単純~化＠~CSSVAL#simplify-a-calculation-tree$できる。 ◎ A random() function can be simplified as soon as its argument calculations can be simplified to numeric values.

注記： このことは、［ `random$f は、 `通例的には^em `算出d値$の時点で解決されるので，静的な数量-値として継承される ］ことを意味する。 しかしながら， 引数として与えた`計算式$が`使用~値$の時点まで解決されない場合 （ `percentage$t 値を含んでいて，解決するためには~layout情報が要求される場合など）、 `継承$は `random$f 関数~自体を転送することになる （しかしながら，これは、 `percentage$t 自身の挙動と異なるものでない — それは、 `percentage$t として継承されるので， 子~要素~上では異なる値に解決されるかもしれない）。 ◎ Note: This means that random() is usually resolved by computed value time, and thus will inherit as a static numeric value. However, if the argument calculations aren’t resolved until used value time (such as if they include <percentage> values that require layout information to resolve), inheritance will transfer the random() function itself. (This is no different, however, to the behavior of the <percentage>s themselves, which would inherit as <percentage>s and thus might resolve to different values on the child elements.)

少なくとも理論~上は、 `per-element^v が指定されない限り， `random$f を~prop以外の文脈で利用しても大丈夫なはずである。 例えば、 `media^at (max-width: random(100px, 500px)) {...} で何が起こるかは，きちんと定義される。 とは言え、 それを許容することが求まれるのかどうかは，疑わしい。 ◎ At least in theory it should be fine to use random() in non-property contexts, so long as per-element isn’t specified; it’s well-defined what happens with @media (max-width: random(100px, 500px)) {...}, for example. I suspect we want to disallow it, tho?

8.1.1. 引数の範囲

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

• %A, %B いずれかが無限である場合， 結果は ~NaN になる。 ◎ if A or B is infinite, the result is NaN.＼

• %C が無限である場合， 結果は %A になる。 ◎ If C is infinite, the result is A.

  （ %C ~LTE 0 の場合、 標準な定義から外れるが，結果は %A になる。） ◎ (If C is zero or negative, the result is A, but that falls out of the standard definition.)

注記： 通例の`~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-caching-options$t , [ `declaration-value$t? ]# )

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

残りの引数は、 ~CSS値たちが成す任意な連列である。 `random-item$f 関数は、 この連列から~randomに選ばれる一つに解決される。 ◎ The remaining arguments are arbitrary sequences of CSS values. The random-item() function resolves to 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な値の生成-法／~cache法： `random-caching-options$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:

• ~stylesheet内の各［ `~random関数$【！`random$f or `random-item$f】の~instance ］は、 `~random~cache用~key@ を指定する。 ［ `random$f たち／ `random-item$f たち ］【！Two instances of either function】は、 `~random~cache用~key$が［ 一致するならば`一致する値^em／ 異なるならば`別個な値^em ］（順不同）に解決するモノトスル。 ◎ Each instance of random() or random-item() in a stylesheet specifies a random-caching key. Two instances of either function must resolve to identical values if their random-caching keys are identical; they must resolve to distinct values if they’re different.

  （ここでの “別個” とは、［ ある新規な~random演算により生成される ］ことを意味する — その結果は、 別の~random演算と偶然~同じ値になるかもしれないが。） ◎ ("Distinct" here means generated by a fresh random operation; this might coincidentally result in the same value as another random operation.)

• `random$f 用の`~random~cache用~key$は、 次に挙げるものからなる`~tuple$である： ◎ For random(), the random-caching key is a tuple of:

  1. 最小を与える`計算式$の`使用~値$。 ◎ The used value of the minimum calculation.
  2. 最大を与える`計算式$の`使用~値$。 ◎ The used value of the maximum calculation.
  3. 段差を与える`計算式$が［ 在るならば その`使用~値$／ 無いならば ~NULL ］。 ◎ The used value of the step calculation, if present, or null otherwise.
  4. `random-caching-options$t を成す `dashed-ident$t は［ 在るならば それ／ 無いならば ~NULL ］。 ◎ The <dashed-ident> part of the <random-caching-options>, if present, or null otherwise.
  5. `random-caching-options$t 内に `per-element^v が指定された場合、 当の関数が現れる［ 要素／疑似要素 ］ごとに一意な値。 ◎ If per-element is specified in the <random-caching-options>, a unique value per element or pseudo-element the function appears in.

• `random-item$f 用の`~random~cache用~key$は、 次に挙げるものからなる`~tuple$である： ◎ For random-item(), the random-caching key is a tuple of:

  1. 当の関数に与えられた引数の個数。 ◎ The number of arguments to the function.
  2. `random-caching-options$t を成す `dashed-ident$t は［ 在るならば それ／ 無いならば ~NULL ］。 ◎ The <dashed-ident> part of the <random-caching-options>, if present, or null otherwise.
  3. `random-caching-options$t 内に `per-element^v が指定されたならば、 当の関数が現れる［ 要素／疑似要素 ］ごとに一意な値。 ◎ If per-element is specified in the <random-caching-options>, a unique value per element or pseudo-element the function appears in.

［ 要素／疑似要素 ］ごとに “一意な値” の存続期間は、［ 当の要素／当の疑似要素の`最終的な出自の要素$【！`出自の要素$】 （および当の疑似要素を一意に識別するために足る追加的な報） ］への~JS参照と同じになるモノトスル。 別々な文書~内の要素どうしは、 別個な一意な値をとる`べきである^em （同じ~pageであっても、 別個な文書を生産する場合 — 例：~pageが~refreshされた前後 — には，別々な文書とされる）。 （このことは，厳密には［ これらの値の疑似-~random生成を許容するために要求されるもの ］ではないが、 一意~性は，作者が［ 要素たちが文書どうしで同じ値をとること ］に依存し得なくするには十分なはずと見込まれる。） ◎ The "unique value per element or pseudo-element" must have the same lifetime as a JavaScript reference to the element (or to the originating element + sufficient additional info to uniquely identify the pseudo-element). Elements in separate documents (including across refreshes of the same page, which produces distinct documents with distinct elements) should have distinct unique values. (This is not strictly required, to allow for pseudo-random generation of these values, but uniqueness should be likely enough that authors cannot depend on elements having the same values across documents.)

加えて，~random生成~methodは、 同じ演算であっても異なる文書（同じ~pageの~refreshも含む）で呼出されたときは，別個な値を生成する`ベキ^emである。 ◎ Additionally, the random generation method should generate distinct values for the same operation when invoked on different documents (including refreshes of the same page).

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

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

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

.random-square-2 {
  font-size: 16px;
  width: random(160px, 320px);
  height: random(10em, 20em);
}

.foo { width: random(100px, 500px); }

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

.random-squares {
  width: random(per-element, 100px, 500px);
  height: random(per-element, 100px, 500px);
}

.foo {
  --size: random(per-element, 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.

無効な代入

所与の~prop %~prop の値に対する`代入$の結果が`無効が保証される値$を包含するときは、 当の宣言は `算出d値の時点で無効@ になる。 これが起きた場合、 %~prop の`算出d値$は： ◎ When substitution 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.