CSS Color Module Level 5

3.1. 混合-用の色~空間

色~補間~methodが指定されなかった場合、 混合-用の色~空間は，~Oklabと見做される — 他の場合、 指定された色~空間を利用する。 ◎ If no color interpolation method is specified, assume Oklab. Otherwise, use the specified colorspace for mixing.

【 すなわち、 `color-mix$f において `color-interpolation-method$t が省略された場合の結果は， `oklab$v が指定された場合と同じになる。 】

3.2. 百分率の正規化

百分率は、 0% 以上 100% 以下の範囲に入ることが要求される — 特定的に，負な百分率は許容されない。 百分率たちは、 `混合-百分率たちを正規化する$ことにより正規化される。 ◎ Percentages are required to be in the range 0% to 100%. Negative percentages are specifically disallowed. Percentages are normalized by normalizing mix percentages.

color-mix(in lch, purple 50%, plum 50%)
color-mix(in lch, purple 50%, plum)
color-mix(in lch, purple, plum 50%)
color-mix(in lch, purple, plum)
color-mix(in lch, plum, purple)
color-mix(in lch, purple 80%, plum 80%)

color-mix(in lch, purple 30%, plum 30%)

3.3. `color-mix^f の結果の計算-法

color-mix(in lch, peru 40%, palegoldenrod)

color-mix(in lch, teal 65%, olive);

3.4. `color-mix^f に対する混合用の色~空間による効果

混合用の色~空間としてどれを選ぶかは、 結果の効果を大きく左右する。 ◎ The choice of mixing color space can have a large effect on the end result.

color-mix(in lch, white, black);
color-mix(in xyz, white, black);
color-mix(in srgb, white, black);

color-mix(in xyz, rgb(82.02% 30.21% 35.02%) 75.23%, rgb(5.64% 55.94% 85.31%));

color-mix(in lch, white, blue);
color-mix(in oklch, white, blue);
color-mix(in srgb, white, blue);

color-mix(in hsl, color(display-p3 0 1 0) 80%, yellow);

3.5. `color-mix^f に対する全~不透明でない~alphaによる効果

これまでの `color-mix$f 例は、 どれも全~不透明な色を利用していた — ［ `乗算済み$化する段／`非乗算済み$化する段 ］は、 各例を単純~化するため省略されていた — これらは、単純に［ 1 を乗算する／ 1 で除算する ］だけであり，結果は変化しないので。 ◎ So far, all the color-mix() examples have used fully opaque colors. To simplify the examples, the premultilication and unpremultiplication steps were omitted because these would simply multiply by 1, and divide by 1, so the result would be unchanged.

一般~事例では、 色の~alpha成分は，全~不透明でないこともある。 したがって［ 乗算済みにする, 補間する, 非乗算済みにする ］段を省略しないモノトスル。 ◎ In the general case, colors may have non-unity alpha components and thus the premultiply, interpolate, unpremultiply steps must not be omitted.

color-mix(in srgb, rgb(100% 0% 0% / 0.7) 25%, rgb(0% 100% 0% / 0.2));

百分率の正規化が`~alpha乗算子$を生成するときの計算は、 追加的な最後の段があることを除いて，同じになる。 ◎ When the percentage normalization generates an alpha multiplier, the calculation is the same except for an additional last step.

color-mix(in srgb, rgb(100% 0% 0% / 0.7) 20%, rgb(0% 100% 0% / 0.2) 60%);

注記： 非乗算済み化するときには、［ 補間した~alphaを`~alpha乗算子$で乗算した結果 ］を利用しないこと。 そうするのは、混合-百分率を［ 総和が 100% になるよう拡縮しなかった場合 ］には正しくなるが， `, but they are, ^en【？】 なので、この仕方は，混合した色を`重ねて^em調整することになる。 ◎ Note: do not multiply the interpolated alpha by the alpha multiplier and then use that to undo premultiplication. That would be correct if the mix percentages were not scaled to sum to 100%, but they are, so doing it this way would adjust the mixed color twice.

4.1. 相対~色~用の処理~model

`~level 4$ までは、 `色~関数$は，［ すべての色~成分を直に指定する，絶対的な方式 ］でしか色を指定できなかった。 ◎ In previous levels of this specification, the color functions could only specify colors in an absolute manner, by directly specifying all of the color components.

新たな `相対~色~構文@ （ `relative color syntax^en, 略称 RCS †）は、 `現代の色~構文$を拡張して， 既存の色を`色~関数$を利用して改変することを許容する。 それは、 `起点~色@ （ `origin color^en ）を指定する — その場合，各~色~成分は （および、~alpha成分が指定された場合はそれも）、［ 直に指定する ］ことも［ 起点~色からとる （場合によっては，`~math関数$で改変した上で） ］こともできる。 ◎ The new relative color syntax extends modern color syntax to allow existing colors to be modified using the color functions: if an origin color is specified, then each color component (and the alpha component, if specified) can either be directly specified, or taken from the origin color (and possibly modified with math functions).

【 そのような構文を利用している`色~関数$は、 “相対~色~関数” と総称される。 そのような構文を利用して生産される色は、 “相対~色” と総称される。 “相対~色の色~空間” は、 当の`色~関数$用の色~空間を指す。 】【† この略称 RCS は、 この訳では利用しない （原文における この略称は、 実際には，文脈に応じて［ 相対~色~関数／相対~色 ］を意味することもある）。 】

`起点~色$と`相対~色$に同じ色~関数を利用する必要はない。 ◎ The origin color and the relative color need not use the same color function.

【！Required conversion:】 すべての演算は、 `相対~色~関数$の`色~空間$の下で行われる。 `起点~色$用に `元々指定された色~空間@ が当の`色~関数$用の色~空間と異なる場合、 各~成分から値をとれるようにするため， `起点~色$は，まず後者の色~空間へ変換される。 `変換-済みな起点~色@ は、［ この変換が要求される場合は，変換した結果／ 他の場合は，そのまま`起点~色$ ］を参照rする。 `成分~keyword$は、 `起点~色$`ではなく^em，相対~色の色~空間を参照rする。 ◎ Required conversion: All operations take part in the color space of the relative color function; if the originally specified color space for the origin color used a different color function, it’s first converted into the chosen color function, so it has meaningful values for the components, and component keywords refer to the color space of the relative color, not the origin color.

相対~色の~alpha値が省略された場合の既定は、 `起点~色$からとられる （絶対的な構文のときのように， `100%^v が既定にはならない）。 ◎ If the alpha value of the relative color is omitted, it defaults to that of the origin color (rather than defaulting to 100%, as it does in the absolute syntax).

相対~色~構文が利用されたときは、 各~成分の値は，［ 直に指定されたもの, 色~空間の変換から発生したもの ］どちらであろうが： ◎ ↓

• 色~成分の値は、 基準~範囲へは`切詰められず^em，そのままに維持される。 これは、 色域~外にある値を — 行先~色~空間に それを表現する能力があるならば — 保全する。 ◎ When relative color syntax is used, color component values, whether directly specified or arising from color space conversion, are not clamped to the reference ranges but are retained as-is. This preserves out of gamut values, if the destination color space is capable of representing them.
• ~alpha成分の値は、 基準~範囲へ`切詰められる^em。 ◎ However, when relative color syntax is used, alpha component values whether directly specified or arising from color space conversion, are clamped to the reference range.

`欠落~成分$は、 `~level 4$ の `§ 欠落~成分との補間-法＠~CSSCOLOR#interpolation-missing$ と同じ仕方で取扱われる。 `起点~色$の`欠落~成分$は、 `相対~色~関数$の色~空間のある成分と`相似的な成分$であるならば，`先へ運ばれ$ることになる。 ◎ Missing components are handled the same way as with CSS Color 4 § 12.2 Interpolating with Missing Components: the origin colorspace and the relative function colorspace are checked for analogous components which are then carried forward as missing.

`成分~keyword$は — ほとんどの`相対~色~構文$の利用では、 対応する引数にて利用することになろうが — どの位置でも利用できる。 ◎ While most uses of relative color syntax will use the component keywords in their corresponding argument, you can use them in any position.

ある成分【`成分~keyword$】を通常とは異なる位置で利用しているとき、 百分率を実数に解決する際にその位置を織り込むような “魔法の拡縮-法” は，無いことに注意。 【！if those numbers are used in a different place】 ◎ Beware when using components outside their normal position; when percentages are resolved to numbers, there is no "magic scaling" to account for the changed position if those numbers are used in a different place.

`device-cmyk$f には`相対~色~構文$は無い。 ◎ There is no relative device-cmyk() syntax.

4.2. 相対~色~構文

各種 `色~関数$にて相対~色を収容するための構文上の変更点を成す精確な詳細は，以下に挙げられるが、 それらすべては共通な構造に従う： ◎ The precise details of each function’s syntactic changes to accommodate relative colors are listed below, but they all follow a common structure:

• 最初の引数として，`起点~色$を次の~~形で指定できる ⇒ from `color$t ◎ An origin color can be specified with a from <color> value at the start of the function.＼

  省略可能な~alpha成分が指定された場合、 これには，それも含まれる。 ◎ This includes the optional alpha component, if specified.

• `起点~色$が指定されなかった場合、 当の関数は，`相対~色$ではない。 ◎ If no origin color is specified, the function is not a relative color.
• `起点~色$が指定された場合、 残りの各~引数は — 通常通り直に指定する他にも — ［ `起点~色$を相対~色の`色~空間$へ変換した結果 ］を成す ある成分を参照rしている `成分~keyword@ としても指定できる。 これらの~keywordは、 `~math関数$内でも利用でき，`起点~色$の各~成分を動的に改変する。 ◎ If an origin color is specified, the remaining arguments can either be specified directly, as normal, or be specified as a component keyword referring to one of the components of the origin color converted to the color space of the relative color. Math functions can also use these keywords to do dynamic modifications of the origin color’s components.
• `相対~色~構文$においても、 引数が省略可能かどうかは，【元の構文から】変化しない。 ◎ Relative color syntax doesn’t change whether an argument is required or optional.
• `相対~色~構文$が適用されるのは、 `現代の色~構文$に限られ， `旧来の色~構文$と伴には`利用し得ない^em — そうしようと試みるのは~errorである。 ◎ Relative color syntax only applies to the modern color syntax. It cannot be used with legacy color syntax and attempting to do so is an error.
• しかしながら，`起点~色$には、［ `現代の色~構文$, `旧来の色~構文$ ］どちらも利用できる。 ◎ However, the origin color can use either modern or legacy syntax.

`成分~keyword$は、［ `number$t ／ `none$v ］を返す — 元々は［ `percentage$t ／ `angle$t ］（順不同）として指定された場合でも： ◎ The component keywords return a <number>, or none; if they were originally specified as a <percentage> or an <angle>,＼

• `percentage$t として指定された場合、 `number$t に解決される。 ◎ that <percentage> is resolved to a <number>＼

• `angle$t として指定された場合、 単位が度数（`正準-単位$ `deg$u ）でない場合は度数に換算した上で， 範囲 [0, 360] に入る `number$t に解決される†。

  【† すなわち、 360 を法とする剰余（この範囲に切詰めるのではなく） — この範囲だと 360 の倍数が［ 0, 360 ］どちらに解決されるのか多義的になるが、 どちらになるかは，この仕様には述べられていない （文脈に依存して，この範囲から［ 360, 0 ］どちらかが除外されるのかもしれない）。 】

  ◎ and the <angle> is resolved to a <number> of degrees (which is the canonical unit) in the range [0, 360].

html {
  --bluegreen: `teal^swatch oklab(54.3% -22.5% -5%);
}
.overlay {
  background: `4.696% 39.17% 39.38%^rgb oklab(from var(--bluegreen) calc(1.0 - l) calc(a * 0.8) b);
}

html { --base: `sienna^swatch oklch(52.6% 0.115 44.6deg) }
.summary {
  background: `30.09% 47.36% 18.46%^rgb oklch(from var(--base) l c  calc(h + 90));
}

html { --color: green; }
.foo {
  --darker-accent: lch(from var(--color) calc(l / 2) c h);
}

html { --bg-color: blue; }
.overlay {
  background: rgb(from var(--bg-color) r g b / 80%);
}

--vivid-yellow: color(display-p3 1 1 0);
--paler-yellow: `100% 100% 15.37%^rgb color(from var(--vivid-yellow) srgb r g calc(b + 0.5));

--tan: `80.93% 70% 55.27% / 70%^rgb oklch(78% 0.06 75 / 0.7);
--deeper-tan: `80.93% 70% 55.27%^rgb oklch(from var(--tan) l c h / calc(alpha * 2));

--blue-into-gray: rgb(from var(--color)
                    calc(r * .3 + g * .59 + b * .11)
                    calc(r * .3 + g * .59 + b * .11)
                    calc(r * .3 + g * .59 + b * .11));

html { --bg: `51.5% 48.5% 48.5%^rgb hsl(none 3% 50%); }
.foo {
  --darker-bg: `37.86% 35.24% 35.91%^rgb oklch(from var(--bg) calc(l * 0.8) c h);
}
.bar {
  background: linear-gradient(in Oklab to right, `37.86% 35.24% 35.91%^rgb var(--darker-bg), `#4C3^vc);
}

しかしながら，欠落~値に対し計算が行われた場合、 `none$v は 0 として扱われる。 ◎ However, if calculations are done on missing values, none is treated as 0.

4.3. 相対~sRGB色

`現代の色~構文$による［ `rgb$f ／ `rgba$f ］関数の文法は、 次のように拡張される： ◎ The grammar of the modern color syntax rgb() and rgba() functions are extended as follows:

`modern-rgb-syntax@t
	= rgb(
		[ from `color$t ]?
		[ `number$t | `percentage$t | `none$v]{3}
		[ / [`alpha-value$t | `none$v] ]? )
`modern-rgba-syntax@t
	= rgba(
		[ from `color$t ]?
		[ `number$t | `percentage$t | `none$v]{3}
		[ / [`alpha-value$t | `none$v] ]? )

`相対~色~構文$による［ `rgb$f ／ `rgba$f ］関数の中で許容される`成分~keyword$は： ◎ Within a relative color syntax rgb() or rgba() function, the allowed component keywords are:

• `rgb/r@ck ／ `rgb/g@ck ／ `rgb/b@ck ⇒ ~sRGBに`変換-済みな起点~色$の［ ~red／~green／~blue ］成分に対応する `number$t を与える。 255.0 が 100% と等価。 ◎ r, g, and b are all <number>s that correspond to the origin color’s red, green, and blue components after conversion, if required to sRGB. 255.0 is equivalent to 100%.
• `rgb/alpha@ck ⇒ `起点~色$の~alpha透明度†に対応する `number$t を与える。 1.0 が 100% と等価。 ◎ alpha is a <number> that corresponds to the origin color’s alpha transparency. 1.0 is equivalent to 100%.

【† “~alpha透明度（ `alpha transparency^en ）” は、 その字義に反して，実際には不透明度（ `opacity^en ）を表す （以下も同様）。 】

rgb(from indianred 255 g b)

~sRGB用の`相対~色~構文$は、 ~RGB用の`旧来の色~構文$には適用-可能でない。 ◎ Relative sRGB color syntax is only applicable to the non-legacy RGB syntactic forms.

rgba(from darkblue 16, 32, b, 0.5 )

rgb(from darkblue 16 32 b / 0.5 )

4.4. 相対~HSL色

`現代の色~構文$による［ `hsl$f ／ `hsla$f ］関数の文法は、 次のように拡張される： ◎ The grammar of the modern color syntax hsl() and hsla() functions is extended as follows:

`modern-hsl-syntax@t
	= hsl(
		[from `color$t]?
		[`hue$t | `none$v]
		[`percentage$t | `number$t | `none$v]
		[`percentage$t | `number$t | `none$v]
		[ / [`alpha-value$t | `none$v] ]? )
`modern-hsla-syntax@t
	= hsla(
		[from `color$t]?
		[`hue$t | `none$v]
		[`percentage$t | `number$t | `none$v]
		[`percentage$t | `number$t | `none$v]
		[ / [`alpha-value$t | `none$v] ]? )

`相対~色~構文$による［ `hsl$f ／ `hsla$f ］関数の中で許容される`成分~keyword$は： ◎ Within a relative color syntax hsl() or hsla() function, the allowed component keywords are:

• `hsl/h@ck ⇒ ~sRGBに`変換-済みな起点~色$の~HSL色相に対応する［ 度数による `number$t ］を与える — 値は、 範囲 [0, 360] に正規化される。 90 が 90° と等価。 ◎ h is a <number> that corresponds to the origin color’s HSL hue, in degrees, after conversion, if required to sRGB, normalized to a [0, 360] range. 90 is equivalent to 90deg.
• `hsl/s@ck ／ `hsl/l@ck ⇒ ~sRGBに`変換-済みな起点~色$の~HSL［ 彩度／明度 ］に対応する `number$t を与える。 100 が 100% と等価。 ◎ s and l are <number>s that correspond to the origin color’s HSL saturation and lightness, after conversion, if required to sRGB. 100 is equivalent to 100%.
• `hsl/alpha@ck ⇒ `起点~色$の~alpha透明度に対応する `number$t を与える。 1.0 が 100% と等価。 ◎ alpha is a <number> that corresponds to the origin color’s alpha transparency 1.0 is equivalent to 100%.

--accent: lightseagreen;
--complement: hsl(from var(--accent) calc(h + 180) s l);

~HSL用の`相対~色~構文$は、 ~HSL用の`旧来の色~構文$には適用-可能でない。 ◎ Relative HSL color syntax is only applicable to the non-legacy HSL syntactic forms.

4.5. 相対~HWB色

`hwb$f 関数の文法は、 次のように拡張される： ◎ The grammar of the hwb() function is extended as follows:

`hwb@f
	= hwb(
		[from `color$t]?
		[`hue$t | `none$v]
		[`percentage$t | `number$t | `none$v]
		[`percentage$t | `number$t | `none$v]
		[ / [`alpha-value$t | `none$v] ]? )

`相対~色~構文$による `hwb$f 関数の中で許容される`成分~keyword$は： ◎ Within a relative color syntax hwb() function, the allowed component keywords are:

• `hwb/h@ck ⇒ ~sRGBに`変換-済みな起点~色$の~HWB色相に対応する，［ 度数による `number$t ］を与える — 値は、 範囲 [0, 360] に正規化される。 90 が 90° と等価。 ◎ h is a <number> that corresponds to the origin color’s HWB hue, in degrees, after conversion, if required to sRGB, normalized to a [0, 360] range. 90 is equivalent to 90deg.
• `hwb/w@ck ／ `hwb/b@ck ⇒ ~sRGBに`変換-済みな起点~色$の~HWB［ 白度／黒度 ］に対応する `number$t を与える。 100 が 100% と等価。 ◎ w and b are <number>s that correspond to the origin color’s HWB whiteness and blackness after conversion, if required to sRGB. 100 is equivalent to 100%.
• `hwb/alpha@ck ⇒ `起点~色$の~alpha透明度に対応する `number$t を与える。 1.0 が 100% と等価。 ◎ alpha is a <number> that corresponds to the origin color’s alpha transparency. 1.0 is equivalent to 100%.

4.6. 相対~Lab色

`lab$f 関数の文法は、 次のように拡張される： ◎ The grammar of the lab() function is extended as follows:

`lab@f
	= lab(
		[from `color$t]?
		[`percentage$t | `number$t | `none$v]
		[`percentage$t | `number$t | `none$v]
		[`percentage$t | `number$t | `none$v]
		[ / [`alpha-value$t | `none$v] ]? )

`相対~色~構文$による `lab$f 関数の中で許容される`成分~keyword$は： ◎ Within a relative color syntax lab() function, the allowed component keywords are:

• `lab/l@ck ⇒ ~CIE~Labに`変換-済みな起点~色$の~CIE明度（ L【！Lightness】 ）に対応する `number$t を与える。 100 が 100% と等価。 ◎ l is a <number> that corresponds to the origin color’s CIE Lightness after conversion, if required, to CIE Lab. 100 is equivalent to 100%.
• `lab/a@ck ／ `lab/b@ck ⇒ ~CIE~Labに`変換-済みな起点~色$の~CIE~Lab［ `a^ ／ `b^ ］軸に対応する `number$t を与える。 125 が 100% と等価。 −125 が −100% と等価。 ◎ a and b are <number>s that correspond to the origin color’s CIE Lab a and b axes after conversion, if required, to CIE Lab. 125 is equivalent to 100%, while -125 is equivalent to -100%.
• `lab/alpha@ck ⇒ `起点~色$の~alpha透明度に対応する `number$t を与える。 1.0 が 100% と等価。 ◎ alpha is a <number> that corresponds to the origin color’s alpha transparency. 1.0 is equivalent to 100%.

--mycolor: `orchid^vN;
/* 
`orchid^vc は `lab(62.753 52.460 -34.103)^v
◎
orchid is lab(62.753% 52.460 -34.103)
 */
--mygray: lab(from var(--mycolor) l 0 0);
/* 
`--mygray^p は `lab(62.753 0 0)^v
（ `rgb(59.515% 59.515% 59.515%)^vc ）になる
◎
mygray is lab(62.753% 0 0) which is rgb(59.515% 59.515% 59.515%)
 */

4.7. 相対~Oklab色

`oklab$f 関数の文法は、 次のように拡張される： ◎ The grammar of the oklab() function is extended as follows:

`oklab@f
	= oklab(
		[from `color$t]?
		[`percentage$t | `number$t | `none$v]
		[`percentage$t | `number$t | `none$v]
		[`percentage$t | `number$t | `none$v]
		[ / [`alpha-value$t | `none$v] ]? )

`相対~色~構文$による `oklab$f 関数の中で許容される`成分~keyword$は： ◎ Within a relative color syntax oklab() function, the allowed component keywords are:

• `oklab/l@ck ⇒ ~Oklabに`変換-済みな起点~色$の~Oklab明度（ L【！Lightness】 ）に対応する `number$t を与える。 1.0 が 100% と等価。 ◎ l is a <number> that corresponds to the origin color’s Oklab Lightness after conversion, if required, to Oklab. 1.0 is equivalent to 100%.
• `oklab/a@ck ／ `oklab/b@ck ⇒ ~Oklabに`変換-済みな起点~色$の~Oklab［ `a^ ／ `b^ ］軸に対応する `number$t を与える。 0.4 が 100% と等価。 −0.4 が −100% と等価。 ◎ a and b are <number>s that correspond to the origin color’s Oklab a and b axes after conversion, if required, to Oklab. 0.4 is equivalent to 100%, while -0.4 is equivalent to -100%.
• `oklab/alpha@ck ⇒ `起点~色$の~alpha透明度に対応する `number$t を与える。 1.0 が 100% と等価。 ◎ alpha is a <number> that corresponds to the origin color’s alpha transparency. 1.0 is equivalent to 100%.

4.8. 相対~LCH色

`lch$f 関数の文法は、 次のように拡張される： ◎ The grammar of the lch() function is extended as follows:

`lch@f
	= lch(
		[from `color$t]?
		[`percentage$t | `number$t | `none$v]
		[`percentage$t | `number$t | `none$v]
		[`hue$t | `none$v]
		[ / [`alpha-value$t | `none$v] ]? )

`相対~色~構文$による `lch$f 関数の中で許容される`成分~keyword$は： ◎ Within a relative color syntax lch() function, the allowed component keywords are:

• `lch/l@ck ⇒ ~CIE~LCHに`変換-済みな起点~色$の~CIE明度（ L【！Lightness】 ）に対応する `number$t を与える。 100 が 100% と等価。 ◎ l is a <number> that corresponds to the origin color’s CIE Lightness after conversion, if required, to CIE LCH. 100 is equivalent to 100%.
• `lch/c@ck ⇒ ~CIE~LCHに`変換-済みな起点~色$の~LCH色度（ C ）に対応する `number$t を与える。 150 が 100% と等価。 ◎ c is a <number> that corresponds to the origin color’s LCH chroma after conversion, if required, to CIE LCH. 150 is equivalent to 100%.
• `lch/h@ck ⇒ ~CIE~LCHに`変換-済みな起点~色$の~LCH色相（ H ）に対応する［ 度数による `number$t ］を与える — 値は、 範囲 [0, 360] に正規化される。 90 が 90° と等価。 ◎ h is a <number> that corresponds to the origin color’s LCH hue, in degrees, after conversion, if required, to CIE LCH, normalized to a [0, 360] range. 90 is equivalent to 90deg.
• `lch/alpha@ck ⇒ `起点~色$の~alpha透明度に対応する `number$t を与える。 1.0 が 100% と等価。 ◎ alpha is a <number> that corresponds to the origin color’s alpha transparency. 1.0 is equivalent to 100%.

--accent: lightseagreen;
--complement: lch(from var(--accent) l c calc(h + 180));

--mycolor: `orchid^vN;
/* 
`orchid^vc は `lch(62.753 62.571 326.973)^v
◎
orchid is lch(62.753% 62.571 326.973)
 */
--mygray: lch(from var(--mycolor) l 0 h);
/* 
`--mygray^p は `lch(62.753 0 326.973)^v
（ `rgb(59.515% 59.515% 59.515%)^vc ）になる
◎
mygray is lch(62.753% 0 326.973) which is rgb(59.515% 59.515% 59.515%)
 */

--mymuted: lch(from var(--mygray) l 30 h);
/* 
`--mymuted^p は `lch(62.753 30 326.973)^v
（ `rgb(72.710% 53.293% 71.224%)^vc ）になる
◎
mymuted is lch(62.753% 30 326.973) which is rgb(72.710% 53.293% 71.224%)
 */

しかしながら，~HSLと違って、 操作した結果が色域~内に入ることは保証されない。 ◎ However, unlike HSL, manipulations are not guaranteed to be in-gamut.

--mycolor: `86.1% 33.4% 97.6%^rgb lch(60% 90 320);
lch(from var(--mycolor) l c calc(h - 120));

--mycolor: `86.1% 33.4% 97.6%^rgb lch(60% 90 320);
hsl(from var(--mycolor) calc(h - 120) s l);

4.9. 相対~OkLCh色

`oklch$f 関数の文法は、 次のように拡張される： ◎ The grammar of the oklch() function is extended as follows:

`oklch@f
	= oklch(
		[from `color$t]?
		[`percentage$t | `number$t | `none$v]
		[`percentage$t | `number$t | `none$v]
		[`hue$t | `none$v]
		[ / [`alpha-value$t | `none$v] ]? )

`相対~色~構文$による `oklch$f 関数の中で許容される`成分~keyword$は： ◎ Within a relative color syntax oklch() function, the allowed component keywords are:

• `oklch/l@ck ⇒ ~Oklabに`変換-済みな起点~色$の~Oklab明度（ L【！Lightness】 ）に対応する `number$t を与える。 1.0 が 100% と等価。 ◎ l is a <number> that corresponds to the origin color’s Oklab Lightness after conversion, if required, to OkLCh. 1.0 is equivalent to 100%.
• `oklch/c@ck ⇒ ~Oklabに`変換-済みな起点~色$の~OkLCh色度（ C ）に対応する `number$t を与える。 0.4 が 100% と等価。 ◎ c is a <number> that corresponds to the origin color’s OkLCh chroma after conversion, if required, to OkLCh. 0.4 is equivalent to 100%.
• `oklch/h@ck ⇒ ~Oklabに`変換-済みな起点~色$の~OkLCh色相（ H ）に対応する［ 度数による `number$t ］を与える — 値は、 範囲 [0, 360] に正規化される。 90 が 90° と等価。 ◎ h is a <number> that corresponds to the origin color’s OkLCh hue, in degrees, after conversion, if required, to OkLCh, normalized to a [0, 360] range. 90 is equivalent to 90deg.
• `oklch/alpha@ck ⇒ `起点~色$の~alpha透明度に対応する `number$t を与える。 1.0 が 100% と等価。 ◎ alpha is a <number> that corresponds to the origin color’s alpha transparency. 1.0 is equivalent to 100%.

~OkLChは、［ 知覚的に一様かつ色度を保全する ］ことに加え［ その各~軸は容易に理解される色の属性に対応する ］ので，色~操作に適する。 ◎ Because OkLCh is both perceptually uniform and chroma-preserving, and because the axes correspond to easily understood attributes of a color, OkLCh is a good choice for color manipulation.

--mycolor: `86.1% 33.4% 97.6%^rgb lch(60% 90 320);
oklch(from var(--mycolor) l c calc(h - 120));

4.10. 相対~alpha色

`alpha$f 関数の文法は： ◎ The grammar of the alpha() function is as follows:

`alpha@f
	= alpha([from `color$t] [ / [`alpha-value$t | none] ]? )

【 `alpha$f 関数は、 常に`相対~色~構文$で指定する必要がある。 】

`相対~色~構文$による `alpha$f 関数の中で許容される`成分~keyword$は： ◎ Within a relative color syntax alpha() function, the allowed component keywords are:

• `alpha/alpha@ck ⇒ `起点~色$の~alpha透明度に対応する `number$t を与える。 1.0 が 100% と等価。 ◎ alpha is a <number> that corresponds to the origin color’s alpha transparency. 1.0 is equivalent to 100%.

`起点~色$を成す色~成分たちは変化しないが、 ~alpha成分は，［ 改変される／置換される ］。 この関数の結果は、 `起点~色$と同じ色~空間に属する。 ◎ The color components of the origin color are unchanged, the alpha component is modified or replaced. The result of this function is in the color space of the origin color.

--mycolor: `71.122% 22.105% 89.033% / 0.3^rgb oklch(60% 0.25 315 / 0.3);
`71.122% 22.105% 89.033% / 0.8^rgb alpha(from var(--mycolor) / 80%);

--mycolor: `71.122% 22.105% 89.033% / 0.8^rgb oklch(60% 0.25 315 / 0.8);
`71.122% 22.105% 89.033% / 0.4^rgb alpha(from var(--mycolor) / calc(alpha * 0.5));

5.1. 相対~色~関数による色

`相対~色~構文$による `color$f 関数の中で許容される`成分~keyword$たちは： ◎ ↓

• `custom-params$t を利用している場合： ◎ Within a relative color syntax color() function using <custom-params>, the number and name of the allowed component keywords are:

  • 【 `dashed-ident$t に指定される名前に】 対応する `color-profile$at 規則は在るならば、 その `components$d 記述子により定義される。 他の場合、 当の相対~色~操作は妥当でない。 ◎ defined by the components descriptor on the corresponding @color-profile, if present; otherwise, no relative color manipulation is valid.＼

    いずれの~keywordも，［ 【当の~at-規則の `src$d 記述子に指定された】 `色~profile$の色~空間 ］に`変換-済みな起点~色$の［ 当の~keywordで命名された成分 ］に対応する `number$t を与える。 値 1.0 は 100% に対応する。 ◎ They are <number>s that correspond to the origin color’s components after conversion, if required to the color space of the color profile. The value 1.0 corresponds to 100%.

• `predefined-rgb-params$t を利用している場合： ◎ Within a relative color syntax color() function using <predefined-rgb-params>, the allowed component keywords are:

  • `color/r@ck ／ `color/g@ck ／ `color/b@ck ⇒ ~RGB色~空間 — 【 `predefined-rgb$t が指示する】`定義済み色~空間$ — に`変換-済みな起点~色$の［ ~red／~green／~blue ］成分に対応する `number$t を与える。 値 1.0 は 100% に対応する。 ◎ r, g, and b are all <number>s that correspond to the origin color’s red, green, and blue components after conversion, if required to the predefined RGB color space. The value 1.0 corresponds to 100%.

• `xyz-params$t を利用している場合： ◎ Within a relative color syntax color() function using <xyz-params>, the allowed component keywords are:

  • `color/x@ck ／ `color/y@ck ／ `color/z@ck ⇒ ［ 関連な白色点に順応された，相対~CIE~XYZ色~空間 ］に`変換-済みな起点~色$の［ X ／ Y ／ Z ］成分に対応する `number$t を与える。 値 1.0 は 100% に対応する。 ◎ x, y, z are all <number>s that correspond to the origin color’s X, Y and Z components after conversion, if required to relative CIE XYZ color space adapted to the relevant white point. The value 1.0 corresponds to 100%.

• ［ `predefined-rgb-params$t ／ `xyz-params$t ］を利用している場合： ◎ Within a relative color syntax color() function using either <predefined-rgb-params> or <xyz-params>, an additional allowed component keyword is:

  • `color/alpha@ck ⇒ `起点~色$の~alpha透明度に対応する `number$t を与える。 1.0 が 100% と等価。 ◎ alpha is a <number> that corresponds to the origin color’s alpha transparency. 1.0 is equivalent to 100%.

各~parameterは、 次の形をとる： ◎ The parameters have the following form:

1. `ident$t ／ `dashed-ident$t ⇒＃ 前者（ `predefined-rgb$t ）は `~level 4$ の`定義済み色~空間$（ `display-p3^v など）を表す。 後者は それを名前に伴う `color-profile$at 規則により定義される`~custom色~空間$を表す。 ◎ An <ident> or <dashed-ident> denoting the color space. If this is an <ident> it denotes one of the predefined color spaces CSS Color 4 § 10. Predefined Color Spaces (such as display-p3); if it is a <dashed-ident> it denotes a custom color space, defined by a @color-profile rule.＼

   個々の定義済み色~空間は、 他の成分に［ `number$t, `percentage$t ］のうち どれを利用してヨイかを，さらに制約する。 ◎ Individual predefined color spaces may further restrict whether <number>s or <percentage>s or both, may be used.

   この引数が存在しない色~空間の名前を与えている — すなわち，次に該当する — 場合、 `color^f 関数は`無効な色$を表現する： ◎ ↓

   • `ident$t ⇒ どの`定義済み色~空間$の名前にも合致しないか、 合致するものはあるが，~supportされない ◎ If the <ident> names a non-existent color space (a name that does not match one of the predefined color spaces), or a predefined but unsupported color space, this argument represents an invalid color.
   • `dashed-ident$t ⇒ どの`色~profile$の名前にも合致しないか、 合致するものはあるが，読込まれていないか妥当な~profileを表現していない ◎ If the <dashed-ident> names a non-existent color space ( a name that does not match an color profile’s name, or which matches but the corresponding profile has not loaded, or does not represent a valid profile), this argument represents an invalid color.

2. 1 個~以上の［ `number$t ／ `percentage$t ］値 ⇒ 色~空間がとり得る一連の数量-~parameterを供する。 ◎ One or more <number>s or <percentage>s providing the parameter values that the color space takes.

   これらに対しては、 前項にて指定された色~空間に応じて： ◎ ↓

   `~custom色~空間$の場合： ◎ For custom color spaces,＼

   指定された成分~値が［ 0 以上 1 以下／ 0% 以上 100% 以下 ］の範囲に入らない場合でも無効にはならない。 それらは、 算出d値の時点で妥当な範囲に切詰められる — そうするのは、 ~ICC~profileは，概して［ 範囲~外の入力~値を受容しない ］からである。 ◎ specified component values less than 0 or 0%, or greater than 1 or 100% are not invalid; they are clamped to the valid range at computed value time. This is because ICC profiles typically do not accept out of range input values.

   供された値の個数が必要な~parameterの個数と一致しない場合でも， `無効な色$にはならない： ◎ ↓

   • 当の色~空間がとる値の個数より多過ぎる場合、 末尾側の超過分は無視される。 ◎ For custom color spaces, if more <number>s or <percentage>s are provided than parameters that the color space takes, the excess <number>s at the end are ignored. The color is still a valid color.
   • `components$d 記述子を利用していて， そこに挙げられた成分の個数より多過ぎる場合でも、 末尾側の超過分は妥当であるが，利用されない【！cannot be used in Relative Color Syntax】。 ◎ For custom color spaces, if more <number>s or <percentage>s are provided than components listed in the optional components descriptor, the additional values at the end are still valid, but cannot be used in Relative Color Syntax. The color is still a valid color.
   • 当の色~空間がとる値の個数より少な過ぎる場合、 足りない~parameterは，既定で `0^v にされる （これは特に，複-成分~印刷機において、 追加的な~inkは~spot色か上塗り用で，ほとんどの色には利用されない場合に簡便になる）。 ◎ For custom color spaces, if fewer <number>s or <percentage>s are provided than parameters that the color space takes, the missing parameters default to 0. (This is particularly convenient for multicomponent printers where the additional inks are spot colors or varnishes that most colors on the page won’t use.) The color is still a valid color.

   `定義済み色~空間$の場合： ◎ For predefined color spaces,＼

   指定された成分~値が［ 0 以上 1 以下／ 0% 以上 100% 以下 ］の範囲に入らない場合でも無効にはならない。 そのような`色域~外$にある色は、 算出d値の時点で — `相対~色計量~意図$の下で — 妥当な範囲の色域~内に対応付けられる。 ◎ specified component values less than 0 or 0%, or greater than 1 or 100% are not invalid; these out of gamut colors are gamut mapped to the valid range at computed value time, with a relative colorimetric intent.

3. 省略可能な、 ~slashで分離された `alpha-value$t — 省略-時の既定は `100%^v 。 ◎ An optional slash-separated <alpha-value>.If omitted, it defaults to 100%.

--base: `73.58% 48.92% 10.45%^rgb color(display-p3 0.7 0.5 0.1);
--dark: `53.617% 35.186% 6.4237%^rgb color(from var(--base) xyz-d65 calc(x/2) calc(y/2) calc(z/2));

5.2. ~custom色~空間

~CSSでは、 ある色~profileを基準に`色$を指定することも許容される。 これには例えば、［ 較正-済み~CMYK印刷機 ／ ~RGB色~空間 ／ その他の`有特性$［ 多彩色（ `color^en ）／単彩色（ `monochrome^en ） ］な出力~機器 ］などもあり得る。 ◎ CSS allows colors to be specified by reference to a color profile. This could be for example a calibrated CMYK printer, or an RGB color space, or any other color or monochrome output device which has been characterized.

color: color(--swopc 0.0134 0.8078 0.7451 0.3019);
color: color(--indigo 0.0941 0.6274 0.3372 0.1647 0 0.0706 0.1216);
color: color(prophoto-rgb 0.9137 0.5882 0.4784);
color: color(display-p3 0.3804 0.9921 0.1412);

これらのうち， `dashed-ident$t を利用しているものが、 `~level 4$ の`定義済み色~空間$を利用していない色として判別される — それらには、 当の名前と~profile~dataを接続するため， ~stylesheet内のどこかに合致する `color-profile$at ~at-規則も必要になる： ◎ The colors not using a predefined color space CSS Color 4 § 10. Predefined Color Spaces are distinguished by their use of <dashed-ident> and also need a matching @color-profile at-rule somewhere in the stylesheet, to connect the name with the profile data.

@color-profile --swopc {
  src: url('http://example.org/swop-coated.icc');}
@color-profile --indigo {
  src: url('http://example.org/indigo-seven.icc');}

5.3. 色~profileの指定-法：`color-profile^at ~at-規則

`color-profile@at 規則は、 `色~profile@ を定義し，それに名前を与える。 後で `color$f 関数にて色を指定するときに，その名前を利用できる。 ◎ The @color-profile rule defines and names a color profile which can later be used in the color() function to specify a color.

その構文は、次で定義される： ◎ It’s defined as:

@color-profile
	= @color-profile [`dashed-ident$t | `device-cmyk^v] { `declaration-list$t }

`dashed-ident$t が，~CSS~stylesheet内で利用することになる`色~profile$の名前を与える。 それに代えて， `device-cmyk^v ~keywordを与えた場合、 この色~profileは — 妥当であるならば — ［ `device-cmyk$f 関数【！device-cmyk】にて指定した色を解決する ］ために利用されることになる。 ◎ The <dashed-ident> gives the color profile’s name, by which it will be used in a CSS stylesheet. Alternatively, the device-cmyk keyword means that this color profile will, if valid, be used to resolve colors specified in device-cmyk.

`color-profile$at 規則は、 この仕様に定義される記述子を受容する。 ◎ The @color-profile rule accepts the descriptors defined in this specification.

`src$d 記述子は、 色~profile情報を検索取得するための~URLを指定する。 ◎ The src descriptor specifies the URL to retrieve the color-profile information from.

同じ名前を伴う複数個の `color-profile$at 規則が定義されている場合、 文書~順序で最後のものが優先され，他のものは無視される。 ◎ If multiple @color-profile rules are defined with the same name, the last one in document order wins, and all preceding ones are ignored.

検索取得した~ICC~profileは、 ~AND↓ を満たすならば妥当とされる。 ◎ The retrieved ICC profile is valid if

• ~ICC~profileとして構文解析できる ◎ it can be parsed as an ICC Profile
• ［ `Input^i ／ `Display^i ／ `Output^i ／ `ColorSpace^i【！color space】 ］に~~分類される （［ `Abstract^i ／ `DeviceLink^i ／ `NamedColor^i ］に~~分類される~ICC~profileは、 利用してはナラナイ。） ◎ it is an Input, Display, Output, or color space ICC profile. (Abstract, DeviceLink, and NamedColor ICC Profiles must not be used).

妥当でない~profileを参照している~CSS色は、 どれも`無効な色$になる。 ◎ If the profile is not valid, all CSS colors which reference this profile are invalid colors.

注記： ~ICC~profile用の~MIME型は、 `application/vnd.iccprofile$c である。 ◎ Note: The Internet Media Type ("MIME type") for ICC profiles is application/vnd.iccprofile.

`色~profile$は、 `描画~意図@ を包含する。 それは、 `色域を対応付ける@ （ `gamut-map^en する）方法 — 色を それを定義していた`色域$より狭い色域へ対応付ける方法 — を定義する。 ~profileが包含する描画~意図は，一つだけの場合が多いが、 複数ある場合は， `rendering-intent$d 記述子を利用して いずれかを選べる。 ◎ Color profiles contain “rendering intents”, which define how to gamut-map their color to smaller gamuts than they’re defined over. Often a profile will contain only a single intent, but when there are multiple, the rendering-intent descriptor chooses one of them to use.

【 描画~意図（ `colorimetric rendering intent^en, 略して `rendering intent^en ） — 色域が異なる媒体で，色をどう再現するか（何を重視して再現するか）を表現する情報。 】

アリな描画~意図 `ICC$r には、 次の 4 種がある： ◎ The four possible rendering intents are [ICC]:

`relative-colorimetric@v 【 “相対~色計量” 】

色計量が媒体に相対的になることが要求される — すなわち，変換元の色は、 変換先~媒体の色域においても，双方の媒体の白色点から相対的に変化しない。 変換先~媒体の色域~外になる変換元の色は、 種々の手法を利用して，色域~境界の色に対応付けられる。 ◎ Media-relative colorimetric is required to leave source colors that fall inside the destination medium gamut unchanged relative to the respective media white points. Source colors that are out of the destination medium gamut are mapped to colors on the gamut boundary using a variety of different methods.

この`描画~意図$は、 黒色点~補償 — 黒色点も，変換元~媒体から変換先~媒体に対応付ける — を伴って利用されることが多い。 この手法では、 変換元の白色点は，変換先の白色点に対応付けるモノトスル。 黒色点~補償も利用-中にある場合、 変換元の黒色点も，変換先の黒色点に対応付けるモノトスル。 白色点の変化に対する調整には、 順応~algoを利用するベキである。 変換元の色のうち，変換先の色域~内に入る各~色に対しては、 それらの相対的な関係性を保全するベキである。 変換先の色域~外になる色については、 相対的な関係性は変化し得る。 ◎ The media-relative colorimetric rendering intent is often used with black point compensation, where the source medium black point is mapped to the destination medium black point as well. This method must map the source white point to the destination white point. If black point compensation is in use, the source black point must also be mapped to the destination black point. Adaptation algorithms should be used to adjust for the change in white point. Relative relationships of colors inside both source and destination gamuts should be preserved. Relative relationships of colors outside the destination gamut may be changed.

【 黒色点~補償（ `black point compensation^en ） — 大雑把に言えば、 黒のつぶれも回避するように変換することに思われる。 】

`absolute-colorimetric@v 【 “絶対~色計量” 】

色計量が~ICC色に関して絶対的になることが要求される — すなわち、 変換元の色のうち，変換先~媒体の色域~内に入るものは、 順応された~white（全拡散反射板から反射される色）から相対的に変化しない。 変換元の色のうち，変換先~媒体の色域~外になるものは、 種々の手法を利用して，色域~境界の色に対応付けられる。 この手法は、 色域~内にある色については，最も正確aに合致する色を生産するが、 変換先~媒体の白色点が変換元~媒体の白色点より~~暗い場合， 高明度（ `highlight^en ）付近がつぶれる結果になる。 この理由から、 色を正確に合致させる必要はあるが， 高明度~付近のつぶれは懸念されないような応用に限って利用することが推奨される。 ◎ ICC-absolute colorimetric is required to leave source colors that fall inside the destination medium gamut unchanged relative to the adopted white (a perfect reflecting diffuser). Source colors that are out of the destination medium gamut are mapped to colors on the gamut boundary using a variety of different methods. This method produces the most accurate color matching of in-gamut colors, but will result in highlight clipping if the destination medium white point is lower than the source medium white point. For this reason it is recommended for use only in applications that need exact color matching and where highlight clipping is not a concern.

この手法は、 色を変換する際には，［ 白色点／黒色点 ］の~~対応付けを不能化するモノトスル。 一般に，この~optionは、 ~test用の目的を除き，推奨されない。 ◎ This method MUST disable white point matching and black point matching when converting colors. In general, this option is not recommended except for testing purposes.

`perceptual@v 【 “知覚~重視” 】

この手法は、 画像に選好されることが多い — とりわけ，変換元と変換先の間が相当に異なるときに （反射~印刷-面に再現される，~screen~display用の画像など）。 これは、 ~proprietaryな【言い換えれば，~UAに特有な】手法を利用して， 変換元の画像の色から変換先~媒体~用に画像の外観を最適化し直す。 その結果、 変換元の色は，変換先の色域に入る色でも変化し得る — 知覚的には、 元の基本的な審美的~意図を保守するように変形されて再現されることが想定されているが。 この手法は、 変換元の画像~内の~errorを補正しようと試みることはない 【何の~error？】。 ◎ This method is often the preferred choice for images, especially when there are substantial differences between the source and destination (such as a screen display image reproduced on a reflection print). It takes the colors of the source image and re-optimizes the appearance for the destination medium using proprietary methods. This re-optimization may result in colors within both the source and destination gamuts being changed, although perceptual transforms are supposed to maintain the basic artistic intent of the original in the reproduction. They will not attempt to correct errors in the source image.

注記： v2 ~ICC~profileでは，知覚的な基準~媒体が指定されていないため、 相互運用能の問題が生じ得る。 v2 ~ICC~profileの利用-時には、 `描画~意図$ `perceptual$v に代えて，黒色点~補償を伴う `relative-colorimetric$v を利用する方が安全になり得る — 特定の［ 変換元, 変換先 ］が利用され、 それらの~profileの組合nの下で，欲される結果が生産されるものと検査-済みであれば別だが。 ◎ Note: With v2 ICC profiles there is no specified perceptual reference medium, which can cause interoperability problems. When v2 ICC profiles are used it can be safer to use the media-relative colorimetric rendering intent with black point compensation, instead of the perceptual rendering intent, unless the specific source and destination profiles to be used have been checked to ensure the combination produces the desired result.

この手法は、 ~target機器の色域に対応付ける際に，画素どうしの相対的な色~値を保守するべきである。 この手法は、 色相ずれや不連続性を避けて，風景の全体的な外観をアリな限り保全するため、 ~target機器の色域に元から入っていた画素~値も変更し得る。 ◎ This method should maintain relative color values among the pixels as they are mapped to the target device gamut. This method may change pixel values that were originally within the target device gamut, in order to avoid hue shifts and discontinuities and to preserve as much as possible the overall appearance of the scene.

`saturation@v 【 “彩度~重視” 】

この~optionは、 元の相対的な彩度（色度）を保全して，単色を純に保つために創出された。 しかしながら、 `描画~意図$ `perceptual$v の様な相互運用能の問題があることも判っている。 単色の保全は，基準~媒体に~~帰順させられないので、 v4 ~profileを利用しても，その問題は解消できない。 この描画~意図の利用は推奨されない — 特定の［ 変換元, 変換先 ］が利用され、 それらの~profileの組合nの下で，欲される結果が生産されるものと検査-済みであれば別だが。 この~optionは、 元の画素の相対的な彩度（色度）値を保全する。 色域~外にある色は、 色域~内に入る同じ彩度の色に変換するベキである。 ◎ This option was created to preserve the relative saturation (chroma) of the original, and to keep solid colors pure. However, it experienced interoperability problems like the perceptual intent, and as solid color preservation is not amenable to a reference medium solution using v4 profiles does not solve the problem. Use of this rendering intent is not recommended unless the specific source and destination profiles to be used have been checked to ensure the combination produces the desired result. This option should preserve the relative saturation (chroma) values of the original pixels. Out of gamut colors should be converted to colors that have the same saturation but fall just inside the gamut.

色~profileは、 可変個数の成分を包含する色~空間を定義できる。 例えば： ◎ Color profiles can define color spaces which contain a varying number of components. For example,＼

• ［ ~cyan, ~magenta, ~yellow, ~black ］（~CMYK）~profileは、［ `c^v, `m^v, `y^v, `k^v ］と命名される 4 個の成分を利用するかもしれない。 ◎ a Cyan, Magenta, Yellow and Black (CMYK) profile has four components named c, m, y and k＼
• 4 個の成分からなる加法的な~screen~profileは、［ `r^v, `g^v, `y^v, `b^v ］と命名される 4 個の成分を利用するかもしれない。 ◎ While a four-component additive screen profile might use four components named r, g, y and b.

この記述子の値は、 ~commaで分離された `ident$t ~tokenたちが成す~listである ⇒＃ 各~tokenは、色~profile内で利用される順序で，ある成分を命名する。 ~tokenの総数は、成分の個数を定義する。 ◎ The value of this descriptor is a comma-separated list of <ident> tokens. Each <ident>> names a component, in the order in which they are used in the color profile, while the total number of tokens defines the number of components.

components: cyan, magenta, yellow, black

components: c,m,y,k

components: cyan, magenta, yellow, black, orange, green, violet

ある成分が`~ASCII大小無視$で `none^l に合致する場合、 当の記述子は無効になる — それは、 欠落~値~用の~token【 `none$v 】と衝突することになるので。 ◎ If a component is an ASCII case-insensitive match for none, the descriptor is invalid, because that would clash with the token for missing values.

［ ある成分~用に選ばれた名前 ］が［ `~CSS数量-定数＠~CSSVAL#calc-constants$として定義された名前 ］と衝突する場合 ⇒ 当の成分は依然として妥当ではあるが、 `calc$f 【などの`~math関数$】の内側においては， 当の成分は当の数量-定数により隠蔽され，期待されない結果へ至らす。 ◎ If the name chosen for a component clashes with a CSS numeric constant as defined in CSS Values 4 § 10.7.1 Numeric Constants: e, pi the component is still valid, but inside calc() the component will be shadowed by the numeric constant leading to unexpected results.

@color-profile --unwise {
  src: url(https://example.com/unwise);
  components: mi, pi, ni;
}
--base: color(--unwise 35% 20% 8%);
--accent: color(from var(--base) mi calc(pi * 2) calc(ni / 2));

5.4. ~CSSと印刷： 較正-済み~CMYKその他の，印刷される色~空間の利用-法

`color-profile$at ~at-規則は、 ~RGB色~空間に制約されない。 ~screenは，色を概して~RGBで直に表示するが、 印刷機は色を~CMYKで表現することが多い。 ◎ The @color-profile at-rule is not restricted to RGB color spaces. While screens typically display colors directly in RGB, printers often represent colors with CMYK.

~CMYK（ `Cyan Magenta Yellow Black^en ）による`較正-済み$な 4 色~印刷や， ~CMYKOGV（ `Cyan Magenta Yellow Black Orange Green Violet^en ）などの 追加的な~inkを伴う忠実度が高い広-色域な印刷-法は、 ~CSSにおいても — 利用する［ ~ink, 紙, 総~ink被覆率, 機材 ］の組合nに対応する~ICC~profileを供すれば — 行える。 ◎ Calibrated four color print with Cyan, Magenta, Yellow and Black (CMYK), or high-fidelity wide gamut printing with additional inks such as Cyan Magenta Yellow Black Orange Green Violet (CMYKOGV) can also be done in CSS, provided you have an ICC profile corresponding to the combination of inks, paper, total ink coverage and equipment you will use.

@color-profile --fogra39 {
  src: url('https://example.org/Coated_Fogra39L_VIGC_300.icc');
}
.header {
  background-color: color(--fogra39 0% 70% 20% 0%);
}

所与の~CMYKの組合nから得られた結果の実際の色は既知なので、 印刷された出力の~screen上での視覚-化（ `soft-proof^en ）を為せる。 ◎ Because the actual color resulting from a given CMYK combination is known, an on-screen visualization of the printed output (soft-proof) can be made.

また，色を知ることに依拠する手続- （~anti-aliasing, 組成-法, ~gradient内に色を利用する, 等々） は、通常通り続行できる。 ◎ Also, procedures that rely on knowing the color (anti-aliasing, compositing, using the color in a gradient, etc) can proceed as normal.

@color-profile --swop5c {
  src: url('https://example.org/SWOP2006_Coated5v2.icc');
}
.header {
  background-color: color(--swop5c 0% 70% 20% 0%);
}

~fallback色も — 例えば，媒体~queryを利用して — 指定でき、［ 指定された~CMYK色が~sRGB色域の外側にあることが既知な場合 ］に利用されることになる。 ◎ Fallback colors can be specified, for example using media queries, to be used if the specified CMYK color is known to be outside the sRGB gamut.

@media (color-gamut: srgb) {
  .header {
    background-color: rgb(8.154% 60.9704% 37.184%);
  }
}
@media print, (color-gamut: p3){
  .header {
    background-color: color(--fogra39 90% 0% 90% 0%);
  }
}

色は 4 ~ink（~CMYK）に制約されない。 例えば，広-色域な 7 色~inkも利用できる。 ◎ Colors are not restricted to four inks (CMYK). For example, wide-gamut 7 Color ink sets can be used.

@color-profile --fogra55beta {
  src: url('https://example.org/2020_13.003_FOGRA55beta_CL_Profile.icc');
}
.dark_skin {
  background-color: `45.8702% 32.0071% 26.3813%^rgb
  color(--fogra55beta 0.183596 0.464444 0.461729 0.612490 0.156903 0.000000 0.000000);
}
.light_skin {
  background-color: `78.0170% 58.1957% 50.7737%^rgb
  color(--fogra55beta 0.070804 0.334971 0.321802 0.215606 0.103107 0.000000 0.000000);
}
.blue_sky {
  background-color: `35.8614% 48.0665% 61.6556%^rgb
  color(--fogra55beta 0.572088 0.229346 0.081708 0.282044 0.000000 0.000000 0.168260);
}
.foliage {
  background-color: `34.9582% 42.3446% 25.4209%^rgb
  color(--fogra55beta 0.314566 0.145687 0.661941 0.582879 0.000000 0.234362 0.000000);
}
.blue_flower {
  background-color: `51.2952% 50.4131% 68.9186%^rgb
  color(--fogra55beta 0.375515 0.259934 0.034849 0.107161 0.000000 0.000000 0.308200);
}
.bluish_green {
  background-color: `36.8792% 74.3685% 67.4749%^rgb
  color(--fogra55beta 0.397575 0.010047 0.223682 0.031140 0.000000 0.317066 0.000000);
}

5.5. ~CMYK色から~Lab色への変換-法

`較正-済み$な~CMYK色~空間から~Labへの変換は、 概して，~ICC~profile内で~Lab値を検索することにより行われる。 ◎ Conversion from a calibrated CMYK color space to Lab is typically done by looking up the Lab values in an ICC profile.

5.6. ~Lab色から~CMYK色への変換-法

印刷-用には、 ~Lab色は，印刷機の色~空間へ変換される必要がある。 ◎ For print, Lab colors will need to be converted to the color space of the printer.

これは、 概して，~ICC~profile内で~CMYK値を検索することにより行われる。 ◎ This is typically done by looking up the CMYK values in an ICC profile.

6.1. 未較正な~CMYK色と~RGBに基づく色の間の素朴な変換-法

【 ~RGBA → ~CMYK → ~RGBA の結果は元に戻るが、 ~CMYK → ~RGBA → ~CMYK の結果は（~~次元が一つ減るので）元に戻るとは限らない。 】

9.1. 補間~用の色~空間

`color-interpolation-method$t は、 次のように， `~custom色~空間$の利用を許容するよう拡張される： ◎ The <color-interpolation-method> is extended to allow use of the custom color spaces:

`color-space@t
	= `rectangular-color-space$t
	| `polar-color-space$t
	| `custom-color-space$t
`rectangular-color-space@t
	= `srgb$v
	| `srgb-linear$v
	| `display-p3$v
	| `display-p3-linear$v
	| `a98-rgb$v
	| `prophoto-rgb$v
	| `rec2020$v
	| `lab$v
	| `oklab$v
	| `xyz-space$t
`polar-color-space@t
	= `hsl$v
	| `hwb$v
	| `lch$v
	| `oklch$v
`custom-color-space@t
	= `dashed-ident$t
`hue-interpolation-method@t
	= [ shorter | longer | increasing | decreasing ] hue
`color-interpolation-method@t
	= in [ `rectangular-color-space$t | `polar-color-space$t `hue-interpolation-method$t? | `custom-color-space$t ]

`custom-color-space$t を成す `dashed-ident$t は、 ある妥当な `color-profile$at 規則~内で宣言-済みでなければナラナイ — さもなければ、 `color-interpolation-method$t は無効になる。 ◎ The <dashed-ident> must have been declared in a valid @color-profile rule, otherwise the <color-interpolation-method> is invalid.

10.1. `color-mix^f 値の解決-法

`color-mix$f の`算出d値$は： ◎ ↓

• すべての `color$t ~parameterが各自の色~空間~内の対応する色に解決された場合 ⇒ 指定された混合用の色~空間~内で混合した結果を［ `~level 4$ の `§ ~color_t 値の解決-法$ ］に則って解決した結果になる。 ◎ If all <color> parameters resolve to the corresponding colors in their respective color spaces, the computed value is the mixed color, in the specified mixing color space, resolved according to CSS Color 4 § 14. Resolving <color> Values.＼
• 他の場合（ある~parameterに `currentcolor$v が利用された場合） ⇒ 各 `color$t ~parameterを［ `~level 4$ の `§ ~color_t 値の解決-法$ ］に則って解決した結果になる。 関数はそのままなので、 子~要素の中への継承を保全する。 ◎ Otherwise (if currentColor was used in the function), the computed value is the color-mix() function with each <color> parameter resolved according to CSS Color 4 § 14. Resolving <color> Values, thus preserving inheritance into child elements.

10.2. 相対~色~構文による値の解決-法

`相対~色~関数$の`算出d値$は： ◎ ↓

• すべての `color$t ~parameterが各自の色~空間~内の対応する色に解決された場合 ⇒ ［ `~level 4$ の `§ ~color_t 値の解決-法$ ］に則って［ 関数~名で指示される【！specified RCS】色~空間 ］内の絶対的な `color$t 値に解決した結果になる。 ◎ If all <color> parameters resolve to the corresponding colors in their respective color spaces, the computed value is the absolute <color> value, in the specified RCS color space, resolved according to CSS Color 4 § 14. Resolving <color> Values.
• 他の場合（ある~parameterに `currentcolor$v が利用された場合） ⇒ 各【！the origin？】 `color$t ~parameterを［ `~level 4$ の `§ ~color_t 値の解決-法$ ］に則って解決した結果になる。 関数はそのままなので、 子~要素の中への継承を保全する。 ◎ Otherwise (if currentColor was used in the function), the computed value is the Relative Color Syntax function with the origin <color> parameter resolved according to CSS Color 4 § 14. Resolving <color> Values, thus preserving inheritance into child elements.

10.3. `device-cmyk^f 値の解決-法

`実際の値$は、 当の演算に基づいて変わり得る： ◎ The actual value can vary based on the operation;＼

• ~CMYK能力がある機器へ描画するときには、 ~CMYK色として描画されてヨイ。 ◎ for rendering to a CMYK-capable device, it may be rendered as a CMYK color;＼
• ［ ~CMYKでない色と混色する／~CMYKでない機器へ描画する ］ときには、 § 未較正な~CMYK色： `device-cmyk^f 関数 に指定されるとおりに変換するモノトスル。 ◎ for blending with non-CMYK colors or rendering to a non-CMYK device, it must be converted as specified in § 6 Uncalibrated CMYK Colors: the device-cmyk() Function.

11.1. `color-mix^f の直列化-法

【 `color-mix$f は，任意個数の色をとり得るよう更新されたが、 以下の記述は，それを反映していない。 】

【 色と百分率を分離する~spaceは、 （原文では上で直に記されているが） この訳では，以下に織り込むことにする — 百分率が省略された場合の結果が正確aでなくなるので。 】

`color-mix$f 関数の宣言d値を成す［ 1 個目の百分率 %p1, 2 個目の百分率 %p2 ］の直列化は、 次に従うものと定義される — ［ %p1, %p2 ］いずれも，指定されなかった場合は ε をとるとする： ◎ ↓

• %p1 を直列化する~algoは： ◎ The serialization of the first percentage of a declared value of a color-mix() function is defined as:

  1. ~IF［ %p1 ~NEQ ε ］：

     1. ~IF［ %p1 ~EQ 50% ］~AND［ %p2 ~IN { ε, 50% } ］ ⇒ ~RET 空~文字列
     2. ~RET 次を順に`連結する$ ⇒＃ 1 個の~space, %p1 をそのままに直列化した結果
     ◎ If BOTH the first percentage p1 and second percentage p2 are specified: • if both p1 equals 50% and p2 equals 50%, nothing is serialized. • else, p1 is serialized as is. ◎ else if ONLY the first percentage p1 is specified: • if p1 is equal to 50%, nothing is serialized. • else, p1 is serialized as is.

  2. ~ELSE：

     1. ~IF［ %p2 ~NIN { ε, 50% } ］~AND［ %p2 は `calc$f でない ］ ⇒ ~RET 次を順に`連結する$ ⇒＃ 1 個の~space, 100% ~MINUS %p2 の値を直列化した結果
     2. ~RET 空~文字列
     ◎ else if ONLY the second percentage p2 is specified: • if p2 equals 50%, nothing is serialized. • if p2 is not calc(), the value of 100% - p2 is serialized. • else, nothing is serialized. ◎ else if NEITHER is specified: • nothing is serialized.

• %p2 を直列化する~algoは： ◎ The serialization of the second percentage of a declared value of a color-mix() function is defined as:

  1. ~IF［ %p2 ~EQ ε ］ ⇒ ~RET 空~文字列 ◎ ↓

  2. ~IF［ %p1 ~NEQ ε ］：

     1. ~IF［ %p1 は `calc$f でない ］~AND［ %p2 は `calc$f でない ］~AND［ %p1 ~PLUS %p2 ~EQ 100% ］ ⇒ ~RET 空~文字列
     ◎ If BOTH the first percentage p1 and second percentages p2 are specified: • if neither p1 nor p2 is calc(), and p1 + p2 equals 100%, nothing is serialized. • else, p2 is serialized as is. ◎ else if ONLY the first percentage p1 is specified: • nothing is serialized.

  3. ~ELSE：

     1. ~IF［ %p2 ~EQ 50% ］~OR［ %p2 は `calc$f でない ］ ⇒ ~RET 空~文字列
     ◎ else if ONLY the second percentage p2 is specified: • if p2 equals 50%, nothing is serialized. • if p2 is not calc(), nothing is serialized. • else, p2 is serialized as is. ◎ else if NEITHER is specified: • nothing is serialized.
  4. ~RET 次を順に`連結する$ ⇒＃ 1 個の~space, %p2 をそのままに直列化した結果 ◎ ↑

注記： `calc$f 値は未知であると見なされるので［ 50% に等しくなる／ 他との総和が 100% に等しくなる ］ことは決してない。 ◎ Note: calc() values are consider to be unknown, so are never equal 50%, and never sum with something else to equal 100%.

`color-mix$f 関数の結果【算出d値】の直列化は： ◎ The serialization of the result of a color-mix() function depends on whether the keyword currentColor is used in the mix.＼

• 混合される色として~keyword `currentcolor$v が利用された場合、 `宣言d値$として【すなわち，色が混合される前のまま】直列化される。 これは、 `color$v 【`color$p ？】 ~propが異なる値をとる子~要素に対しても， 正しい値が利用されることを許容する。 ◎ If so, the result is serialized as the declared value. This allows the correct mixture to be used on child elements whose color property has a different value.

• 他の場合、［ `~level 4$ の `§ ~color_t 値の直列化-法$ ］にて定義されるとおりに直列化された `color$t になる — 利用される形は、 引数~内の `in^v に伴って指定された色~空間に依存する： ◎ Otherwise, it is a <color>, as defined in CSS Color 4 § 15. Serializing <color> Values.＼ The form used depends on the color space specified with "in".

  混合用の色~空間	形
  `srgb$v	`color(srgb r g b)^v
  `srgb-linear$v	`color(srgb-linear r g b)^v
  `display-p3$v	`color(display-p3 r g b)^v
  `a98-rgb$v	`color(a98-rgb r g b)^v
  `prophoto-rgb$v	`color(prophoto-rgb r g b)^v
  `rec2020$v	`color(rec2020 r g b) ^v
  `hsl$v	`color(srgb r g b)^v
  `hwb$v	`color(srgb r g b)^v
  `xyz-d65$v	`color(xyz-d65 x y z)^v
  `xyz-d50$v	`color(xyz-d50 x y z)^v
  `xyz$v	`color(xyz-d65 x y z)^v †
  `lab$v	`lab(l a b)^v
  `lch$v	`lch(l c h)^v
  `oklab$v	`oklab(l a b)^v
  `oklch$v	`oklch(l c h)^v

  † `xyz$v は、 単に `xyz-d65$v 用の別名なので。 ◎ ¹ • Because xyz is just an alias for xyz-d65

往復するための`最小^emな精度は、［ `~level 4$ の `§ ~color_t 値の直列化-法$ ］にて指定されたそれと同じとする。 ◎ The minimum precision for round-tripping is the same as that specified in CSS Color 4 § 15. Serializing <color> Values.

11.2. 起点~色の直列化-法

11.3. 相対~色~関数の直列化-法

OkLcH(from peru  l    c  h)

<div id="example"
  style="background-color: rgb(from currentcolor r g calc(b / 2));
  color: blue;">
</div>

`相対~色~関数$の結果【算出d値】の直列化は： ◎ The serialization of the result of a relative color function depends on whether the keyword currentColor is the origin color.＼

• `起点~色$として~keyword `currentcolor$v が利用された場合、 `宣言d値$として直列化される。 これは、 `color$v 【`color$p ？】 ~propが異なる値をとる子~要素に対しても， 正しい値が利用されることを許容する。 ◎ If so, the result is serialized as the declared value. This allows the correct value to be used on child elements whose color property has a different value.＼

• 他の場合、 それが`解決d値$であり，［ `~level 4$ の `§ ~color_t 値の直列化-法$ ］にて定義されるとおりに直列化された `color$t になる — 利用される形は、 `相対~色$の色~空間に依存する： ◎ Otherwise, it is the resolved value, which is a <color>, as defined in CSS Color 4 § 15. Serializing <color> Values. ◎ The form used depends on the color space of the relative color:

  混合用の色~空間	形
  `srgb$v	`color(srgb r g b)^v
  `srgb-linear$v	`color(srgb-linear r g b)^v
  `display-p3$v	`color(display-p3 r g b)^v
  `a98-rgb$v	`color(a98-rgb r g b)^v
  `prophoto-rgb$v	`color(prophoto-rgb r g b)^v
  `rec2020$v	`color(rec2020 r g b) ^v
  `hsl$v	`color(srgb r g b)^v
  `hwb$v	`color(srgb r g b)^v
  `xyz-d65$v	`color(xyz-d65 x y z)^v
  `xyz-d50$v	`color(xyz-d50 x y z)^v
  `xyz$v	`color(xyz-d65 x y z)^v
  `lab$v	`lab(l a b)^v
  `lch$v	`lch(l c h)^v
  `oklab$v	`oklab(l a b)^v
  `oklch$v	`oklch(l c h)^v

往復するための`最小^emな精度は、［ `~level 4$ の § `color^f 関数の直列化-法 ］にて指定されたそれと同じとする。 ◎ The minimum precision for round-tripping is the same as that specified in CSS Color 4 § 15.5 Serializing values of the color() function.

11.4. ~custom色~空間の直列化-法

`color$f の各~成分~値の精度は維持される — したがって、 この仕様では，直列化した結果における有効数字の個数は定義されないが、 ~CMYK色~空間~用には，［ 8 ~bit精度の値が往復するに足る個数 ］以上にするモノトスル。 したがって、 尾部を成す 0 が省略されない限り，結果の小数部は 2 桁以上になる。 ◎ The precision with which color() component values are retained, and thus the number of significant figures in the serialized value, is not defined in this specification, but for CMYK color spaces must at least be sufficient to round-trip values with eight bit precision; this will result in at least two decimal places unless trailing zeroes have been omitted.

@color-profile --swop5c {
  src: url('https://example.org/SWOP2006_Coated5v2.icc');
}

11.5. `device-cmyk^f 値の直列化-法

`device-cmyk$f 値を直列化した形は、 `算出d値$から導出され， `device-cmyk$f 形を利用する — 関数の名前は小文字~化される。 ◎ The serialized form of device-cmyk() values is derived from the computed value and uses the device-cmyk() form, with lowercase letters for the function name.

各~成分~値は、 `number$t として基数 10 で直列化される。 成分~値どうしは、 1 個の `0020^U `SPACE^cn を利用して分離するモノトスル。 ◎ The component values are serialized in base 10, as <number>. A single ASCII space character " " must be used as the separator between the component values.

どの成分~値に対しても、 小数部の尾部を成す 0 は省略するモノトスル。 小数部がすべて 0 からなる場合、 小数点も省略するモノトスル。 ◎ Trailing fractional zeroes in any component values must be omitted; if the fractional part consists of all zeroes, the decimal point must also be omitted.

`device-cmyk$f の各~成分~値の精度は維持される — したがって，この仕様は、 直列化した結果における有効数字の個数は定義しないが、［ 8 ~bit精度の値が往復するに足る個数 ］以上にするモノトスル。 したがって、 尾部を成す 0 が省略されない限り，結果の小数部は 2 桁以上になる。 値は、切捨てるのではなく，`丸める$モノトスル。 ◎ The precision with which device-cmyk() component values are retained, and thus the number of significant figures in the serialized value, is not defined in this specification, but must at least be sufficient to round-trip values with eight bit precision; this will result in at least two decimal places unless trailing zeroes have been omitted. Values must be rounded towards +∞, not truncated.

~alpha値 1 は、 明示的に直列化されない — 他の~alpha値は、 明示的に直列化するモノトスル。 ~~最後の色~成分~値（ ~black【！`k^l】 ）と~alpha値は、 文字列 ` / ^l （ `0020^U `SPACE^cn, `002F^U （ `/^l ）, `0020^U `SPACE^cn ） を利用して分離するモノトスル。 ◎ Unitary alpha values are not explicitly serialized. Non-unitary alpha values must be explicitly serialized, and the string " / " (an ASCII space, then forward slash, then another space) must be used to separate the black ("k") color component value from the alpha value.

12.1. `CSSColorProfileRule^I ~interface

`CSSColorProfileRule$I ~interfaceは、 `color-profile$at 規則を表現する。 ◎ The CSSColorProfileRule interface represents a @color-profile rule.

[`Exposed$=Window]
interface `CSSColorProfileRule@I : `CSSRule$I {
  readonly attribute `CSSOMString$ `name$m;
  readonly attribute `CSSOMString$ `src$m;
  readonly attribute `CSSOMString$ `renderingIntent$m;
  readonly attribute `CSSOMString$ `components$m;
};

`name@m ◎ name, of type CSSOMString, readonly

この属性の取得子は、 コレが表現する規則~用に定義された`色~profile$の名前【！%名前】を直列化した結果を `CSSOMString^I 型の値として返すモノトスル。 ◎ The name attribute on getting must return a CSSOMString object that contains the serialization of the color profile’s name defined for the associated rule.

`src@m ◎ src, of type CSSOMString, readonly

`renderingIntent@m ◎ renderingIntent, of type CSSOMString, readonly

`components@m ◎ components, of type CSSOMString, readonly

これらの属性の取得子は、 コレが表現する規則~用に当の属性に対応する記述子が指定されて［ いるならば，それを直列化した結果／ いないならば，空~文字列 ］を `CSSOMString^I 型の値として返すモノトスル。 ◎ The remaining attributes on getting must return a CSSOMString object that contains the serialization of the associated descriptor defined for the associated rule. If the descriptor was not specified in the associated rule, the attribute must return an empty string.