1. 序論
◎非規範的[ ~web開発者/設計~tool/設計~system開発者 ]は、[ 自身の~componentにおける色~関係の設計 ]の大規模適用を支援するために,色~関数を利用することが多い。 ~UIにおける `暗な~mode^i ( `Dark-Mode^en )能力の様な,複数の[ ~platform/利用者-選好 ]を~supportする設計~systemの利用度が増えてきている下では、 これは[ 色を手動で設定する必要なく,単独の~sourceから~schemeを計算するため ]ためにも有用になる。 ◎ Web developers, design tools and design system developers often use color functions to assist in scaling the design of their component color relations. With the increasing usage of design systems that support multiple platforms and multiple user preferences, like the increased capability of Dark Mode in UI, this becomes even more useful to not need to manually set color, and to instead have a single source from which schemes are calculated.
現在では、[ ~Sass/~HSL値に対する `calc^f /~PostCSS ]がこれを行うために利用されている。 しかしながら,前処理器は動的に調整される色には働かないので、 現在の解決策はどれも,~sRGB色域に制約され, ~HSLの知覚的な制限にも制約されている (色は色~環~内に詰め込まれているため、 視覚的な明度が異なる 2 個の色の~HSL明度は, `yellow^vN と `blue^vN の様に同じになり得る)。 ◎ Currently Sass, calc() on HSL values, or PostCSS is used to do this. However, preprocessors are unable to work on dynamically adjusted colors; all current solutions are restricted to the sRGB gamut and to the perceptual limitations of HSL (colors are bunched up in the color wheel, and two colors with visually different lightness, like yellow and blue, can have the same HSL lightness).
この~moduleは: ◎ This module\
- 次に挙げる関数を追加する ⇒# `contrast-color$f, `color-mix$f, `light-dark$f ◎ adds the new functions contrast-color(), color-mix() and light-dark(),\
- 既存の関数を`相対~色の構文@#relative-colors$で拡張する。 ◎ and extends existing ones with relative color syntax.
- `color$f 関数を拡張する — `定義済み色~空間$に限らず、 ~ICC~profileにより定義される~custom色~空間(`較正-済み$~CMYKも含む)も, ~CSSにて利用できるよう。 ◎ It also extends the color() function so that not only predefined color spaces, but also custom color spaces defined by ICC profiles (including calibrated CMYK) can be used in CSS.
- 未較正な~CMYK色の表現として, `device-cmyk^f 関数を追加する。 ◎ It also adds device-cmyk, a representation of uncalibrated cmyk color.
2. `color^t 構文
~CSSにおける色は、 `color$t 型により表現される: ◎ Colors in CSS are represented by the <color> type:
`color@t = `color-base$t | `currentcolor$v | `system-color$t | `contrast-color()$t | `device-cmyk()$t | `light-dark()$t `color-base@t = `hex-color$t | `color-function$t | `named-color$t | `color-mix()$t | `transparent$v `color-function@t = `rgb()$t | `rgba()$t | `hsl()$t | `hsla()$t | `hwb()$t | `lab()$t | `lch()$t | `oklab()$t | `oklch()$t | `color()$t
`絶対的な色@ とは、 `color$t 用の値のうち[ その`算出d値$は,絶対的な色計量で解釈されるもの ]をいう。 これは、 当の値が次に挙げるものでないことを意味する: ◎ An absolute color is a <color> whose computed value has an absolute, colorimetric interpretation. This means that the value is not:
- `currentcolor$v (これは、 `color$p ~propの値に依存する) ◎ currentColor (which depends on the value of the color property)
- `system-color$t (これは、 色~modeに依存する) ◎ a <system-color> (which depends on the color mode)
- `light-dark()$t (これは、 色~modeに依存する) ◎ <light-dark()> (which depends on the color mode)
- `contrast-color()$t (これは、 色~modeに依存する) ◎ <contrast-color()> (which depends on the color mode)
- `device-cmyk()$t (これは、 どの色計量にも基づかない) ◎ <device-cmyk()> (which has no colorimetric basis)
- [ `color-mix()$t /`相対~色~構文$ ]のうち,その内側で[ 上に挙げたいずれかの値 ]を利用しているもの。 ◎ Nor are any of those values used inside <color-mix()> or in relative color syntax.
3. 色の混合-法: `color-mix^f 関数
この関数は、 2 個の色~指定( `color$t )をとり,[ 所与の`色~空間$( `color-interpolation-method$t 内に指定される `color-space$t )内で,指定した量により混合した結果 ]を返す。 ◎ This function takes two <color> specifications and returns the result of mixing them, in a given <color-space>, by a specified amount.
`color-mix@f = color-mix( `color-interpolation-method$t, [ `color$t && `percentage [0,100]$t? ]#{2})
3.1. 百分率の正規化
百分率は、 0% 以上 100% 以下の範囲に入ることが要求される — 特定的に,負な百分率は許容されない†。 ◎ Percentages are required to be in the range 0% to 100%. Negative percentages are specifically disallowed.\
【† したがって、 関数は無効な値を表現することになろう。 構文から, 100% を超える値も同様になろう。 (下の~algoには組入れられていないが。) 】
百分率は、 以下に従って正規化される: ◎ The percentages are normalized as follows:
- %p1 ~LET [ 1 個目の色に百分率も供されたならば それ / ~ELSE_ ε ] ◎ Let p1 be the first percentage\
- %p2 ~LET [ 2 個目の色に百分率も供されたならば それ / ~ELSE_ ε ] ◎ and p2 the second one.
- ~IF[ %p1 ~EQ ε ]~AND[ %p2 ~EQ ε ] ⇒# %p1 ~SET 50%; %p2 ~SET 50% (これは 2 個の色を等しく混合する) ◎ If both percentages are omitted, they each default to 50% (an equal mix of the two colors).
- ~ELIF[ %p2 ~EQ ε ] ⇒ %p2 ~SET 100% ~MINUS %p1 ◎ Otherwise, if p2 is omitted, it becomes 100% - p1
- ~ELIF[ %p1 ~EQ ε ] ⇒ %p1 ~SET 100% ~MINUS %p2 ◎ Otherwise, if p1 is omitted, it becomes 100% - p2
- %総和 ~LET %p1 ~PLUS %p2 ◎ ↓
- ~IF[ %総和 ~EQ 0% ] ⇒ 関数は妥当でない ◎ If the percentages sum to zero, the function is invalid.
-
~ELSE:
- %拡縮率 ~LET 100% ~DIV %総和
- %p1 ~SET %p1 ~MUL %拡縮率
- %p2 ~SET %p2 ~MUL %拡縮率
- ~IF[ %総和 ~LT 100% ] ⇒ %総和 を `~alpha乗算子@ として保存する
したがって,次の各~構文-形は、 互いに等価になる: ◎ These syntactic forms are thus all equivalent:
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%)
これらはどれも,~LCH内で[ `purple^vc, `plum^vc ]を 50% ずつ混合した結果を生産する ⇒ `lch(51.51% 52.21 325.8)^v ( `rgb(68.51% 36.01% 68.29%)^vc ) ◎ All produce a 50-50 mix of purple and plum, in lch: lch(51.51% 52.21 325.8) which is rgb(68.51% 36.01% 68.29%).
しかしながら,次の形は、 その~alphaは 1 未満になるので,`同じでない^em: ◎ However, this form is not the same, as the alpha is less than one:
color-mix(in lch, purple 30%, plum 30%)
これが生産する結果は ⇒ `lch(51.51% 52.21 325.8 / 0.6)^v ( `rgb(68.51% 36.01% 68.29% / 0.6)^vc ) ◎ This produces lch(51.51% 52.21 325.8 / 0.6) which is rgb(68.51% 36.01% 68.29% / 0.6).
3.2. `color-mix^f の結果の計算-法
両~百分率とも正規化したなら、 結果は,次の~algoにより生産される: ◎ After normalizing both percentages, the result is produced via the following algorithm:
- %色~空間 ~LET 引数に与えられた `color-space$t が指示する`色~空間$ ◎ ↓
- `~level 4$ の `§ 色~補間@~CSSCOLOR#interpolation$ にて述べられるとおりに, 両~色とも %色~空間 へ変換する — `相似的な成分$があれば,それらも織り込む下で。 ◎ As described in CSS Color 4 § 12. Color Interpolation, both colors are converted to the specified interpolation <color-space>, taking into account any analogous components.
-
互いの色を %色~空間 内で`補間する@~CSSCOLOR#interpolation$ ◎ Colors are then interpolated in the specified color space, as described in CSS Color 4 § 12. Color Interpolation.\
%色~空間 が`円柱な極-座標$ 【!cylindrical-polar-color space】 【 `polar-color-space$t 】 である場合、 指定された `hue-interpolation-method$t が`色相の補間@~CSSCOLOR#hue-interpolation$を制御する — 指定されてない場合は `shorter hue^v 【!`shorter^v 】が指定されたかのようになる。 ◎ If the specified color space is a cylindrical-polar-color space, then the <hue-interpolation-method> controls the interpolation of hue, as described in CSS Color 4 § 12.4 Hue Interpolation.\ If no <hue-interpolation-method> is specified, it is as if shorter had been specified.
- 百分率を正規化するときに`~alpha乗算子$が生産された場合、 補間した結果の~alpha成分を~alpha乗算子で乗算する。 ◎ If an alpha multiplier was produced during percentage normalization, the alpha component of the interpolated result is multiplied by the alpha multiplier.
混合した結果は、 各~色が,それに指定された百分率を占めるような色になる。 ◎ The result of mixing is the color at the specified percentage along the progression of the second color to the first color.
注記: 特に,[ 0% / 100% ]は[ 他方の色/当の色 ]を指定された色~空間~内に変換した結果を返す。 ◎ Note: As a corollary, a percentage of 0% just returns the other color converted to the specified color space, and a percentage of 100% returns the same color converted to the specified color space.
この例は、 `peru^vc 40%, `palegoldenrod^vc 60% による混合を生産する。 ◎ This example produces a mixture of 40% peru and 60% palegoldenrod.
color-mix(in lch, peru 40%, palegoldenrod)
混合するときは、 `lch$v 色~空間~内で行われる。 中立な L 軸~沿いに見下ろした図は: ◎ The mixing is done in lch color space. Here is a top-down view, looking along the neutral L axis:
計算は、次に従う: ◎ The calculation is as follows:
- `peru^vc = `lch(62.253% 54.011 63.677)^v ◎ peru is lch(62.253% 54.011 63.677)
- `palegoldenrod^vc = `lch(91.374% 31.406 98.834)^v ◎ palegoldenrod is lch(91.374% 31.406 98.834)
- 混合した明度 = 62.253 ~MUL 40 ~DIV 100 ~PLUS 91.374 ~MUL (100 ~MINUS 40) ~DIV 100 = 79.7256 ◎ the mixed lightness is 62.253 * 40/100 + 91.374 * (100-40)/100 = 79.7256
- 混合した色度 = 54.011 ~MUL 40 ~DIV 100 ~PLUS 31.406 ~MUL (100 ~MINUS 40) ~DIV 100 = 40.448 ◎ the mixed chroma is 54.011 * 40/100 + 31.406 * (100-40)/100 = 40.448
- 混合した色相 = 63.677 ~MUL 40 ~DIV 100 ~PLUS 98.834 ~MUL (100 ~MINUS 40) ~DIV 100 = 84.771 ◎ the mixed hue is 63.677 * 40/100 + 98.834 * (100-40)/100 = 84.771
- 混合した結果は ⇒ `87.41% 76.03% 47.64%^rgb `lch(79.7256% 40.448 84.771)^v ◎ the mixed result is lch(79.7256% 40.448 84.771)
この例は、 `lch$v 色~空間~内で `teal^vN と `olive^vN の混合を生産する — ~LCHの各~channelが `teal^vN は値の 65%, `olive^vN は値の 35% になるよう。 ◎ This example produces the mixture of teal and olive, in lch color space, with each lch channel being 65% of the value for teal and 35% of the value for olive.
注記: 色相と色度に対する補間-法は、 中間~色を端点~色と同じ彩度に保つ。 ◎ Note: interpolating on hue and chroma keeps the intermediate colors as saturated as the endpoint colors.
color-mix(in lch, teal 65%, olive);
計算は、次に従う: ◎ The calculation is as follows:
- ~sRGB `teal^vc ( `#008080^v ) = `lch(47.9855% 31.6903 196.4524)^v ◎ sRGB teal (#008080) is lch(47.9855% 31.6903 196.4524)
- ~sRGB `olive^vc ( `#808000^v ) = `lch(52.1496% 56.8124 99.5746)^v ◎ sRGB olive (#808000) is lch(52.1496% 56.8124 99.5746)
- 混合した明度 = 47.9855 ~MUL 0.65 ~PLUS 52.1496 ~MUL 0.35 = 49.4429 ◎ mixed lightness is 47.9855 * 0.65 + 52.1496 * 0.35 = 49.4429
- 混合した色度 = 31.6903 ~MUL 0.65 ~PLUS 56.8124 ~MUL 0.35 = 40.4830 ◎ mixed chroma is 31.6903 * 0.65 + 56.8124 * 0.35 = 40.4830
- 混合した色相 = 196.4524 ~MUL 0.65 ~PLUS 99.5746 ~MUL 0.35 = 162.5452 ◎ mixed hue is 196.4524 * 0.65 + 99.5746 * 0.35 = 162.5452
- 混合した結果は ⇒ `lch(49.4429% 40.4830 162.5452)^v (少し~blueがかった~green `rgb(7.7377% 52.5730% 37.3213%)^vc になる) ◎ mixed result is lch(49.4429% 40.4830 162.5452) ◎ which is a slightly-blueish green: rgb(7.7377% 52.5730% 37.3213%)
3.3. `color-mix^f に対する混合用の色~空間による効果
混合用の色~空間としてどれを選ぶかは、 結果の効果を大きく左右する。 ◎ The choice of mixing color space can have a large effect on the end result.
この例では、 3 種の異なる色~空間~内で `white^vN と `black^vN を 50% ずつ混合する。 ◎ This example is a 50% mix of white and black, in three different color spaces.
color-mix(in lch, white, black); color-mix(in xyz, white, black); color-mix(in srgb, white, black);
計算は、次に従う: ◎ The calculation is as follows:
- ~sRGB `white^vc ( `#FFF^v ) = `lch(100% 0 0)^v ◎ sRGB white (#FFF) is lch(100% 0 0)
- ~sRGB `black^vc ( `#000^v ) = `lch(0% 0 0)^v ◎ sRGB black (#000) is lch(0% 0 0)
- ~LCH内で混合した結果は ⇒ `47% 47% 47%^rgb `lch(50% 0 0)^v ◎ The mix in LCH is lch(50% 0 0)
- ~XYZ内で混合した結果は ⇒ `74% 74% 74%^rgb `lch(76% 0 0)^v ◎ The mix in XYZ is lch(76% 0 0)
- ~sRGB内で混合した結果は ⇒ `50% 50% 50%^rgb `lch(53.4% 0 0)^v ◎ The mix in sRGB is lch(53.4% 0 0)
~LCH内で混合した結果は、 正確に期待されるとおり, L 値 50% — ちょうど~~中間の~gray — になる( ~Lab内で混合しても同じになる — ~LCHと~Labの明度( L )軸は同じなので)。 ◎ The mix in LCH gives an L value of 50%, a perfect mid gray, exactly as expected (mixing in Lab would do the same, as the Lightness axis is the same in LCH and Lab).
~XYZ内で混合した結果は,明になり過ぎる — ~XYZは、 光に線形だが知覚的に一様ではないので。 ~sRGB内で混合した結果は,少し明になり過ぎる — ~sRGBは、 知覚的に一様でも光に線形でもない。 ◎ The mix in XYZ gives a result that is too light; XYZ is linear-light but is not perceptually uniform. The mix in sRGB gives a result that is a bit too light; sRGB is neither perceptually uniform nor linear-light.
この例は、 `xyz$v 色~空間~内で, 2 個の色 ~redと~sky-blue の混合を生産する — その色相が ~redの色相の 75.23% (したがって,~blueの色相の 24.77% )になるよう。 ◎ This example produces the mixture of the a red and a sky blue, in xyz color space, with the mixture being 75.23% of that of the red (and thus, 24.77% of that of the blue).
color-mix(in xyz, rgb(82.02% 30.21% 35.02%) 75.23%, rgb(5.64% 55.94% 85.31%));
計算は、次に従う: ◎ The calculation is as follows:
- ~red `rgb(82.02% 30.21% 35.02%)^vc = `lch(52% 58.1 22.7)^v は ⇒# X = 0.3214, Y = 0.2014, Z = 0.0879 ◎ rgb(82.02% 30.21% 35.02%) is lch(52% 58.1 22.7) which is X=0.3214, Y=0.2014, Z=0.0879.
- ~sky-blue `rgb(5.64% 55.94% 85.31%)^vc = `lch(56% 49.1 257.1)^v は ⇒# X = 0.2070, Y = 0.2391, Z = 0.5249. ◎ rgb(5.64% 55.94% 85.31%) is lch(56% 49.1 257.1) which is X=0.2070, Y=0.2391, Z=0.5249.
- 混合した結果の ⇒# X = (0.3214 ~MUL 0.7523) ~PLUS (0.2070 ~MUL (1 ~MINUS 0.7523)) = 0.29306, Y = (0.2014 ~MUL 0.7523) ~PLUS (0.2391 ~MUL (1 ~MINUS 0.7523)) = 0.21074, Z = (0.0879 ~MUL 0.7523) ~PLUS (0.5249 ~MUL (1 ~MINUS 0.7523)) = 0.19614 ◎ mixed result X=(0.3214 * 0.7523) + (0.2070 * (1 - 0.7523)) = 0.29306. ◎ mixed result Y=(0.2014 * 0.7523) + (0.2391 * (1 - 0.7523)) = 0.21074. ◎ mixed result Z=(0.0879 * 0.7523) + (0.5249 * (1 - 0.7523)) = 0.19614.
- 混合した結果は ⇒ `lch(53.0304% 38.9346 352.8138)^v ( `rgb(72.300% 38.639% 53.557%)^vc ) ◎ mix result is lch(53.0304% 38.9346 352.8138) which is rgb(72.300% 38.639% 53.557%)
この例は、 3 種の異なる色~空間~内で,~whiteと~blueを 50% ずつ混合する: ◎ This example is a 50% mix of white and blue, in three different color spaces.
color-mix(in lch, white, blue); color-mix(in oklch, white, blue); color-mix(in srgb, white, blue);
計算は次に従う: ◎ The calcuation is as follows:
- `white^vc = `rgb(100% 100% 100%)^v = `lch(100% 0 none)^v = `oklch(100% 0 none)^v ◎ white is rgb(100% 100% 100%) which is lch(100% 0 none) which is oklch(100% 0 none)
- `blue^vc = `rgb(0% 0% 100)^v = `lch(29.5683% 131.201 301.364)^v = `oklch(45.201% 0.31321 264.052)^v ◎ blue is rgb(0% 0% 100%) which is lch(29.5683% 131.201 301.364) which is oklch(45.201% 0.31321 264.052)
- `lch$v 内で混合した結果は、 かなり~purpleになる ⇒ `68.594% 53.794% 100%^rgb `lch(64.7841% 65.6008 301.364)^v ◎ mix in lch is lch(64.7841% 65.6008 301.364) which is quite purple
- `oklch$v 内で混合した結果は ⇒ `45.304% 63.808% 100%^rgb `oklch(72.601% 0.15661 264.052)^v ◎ mix in oklch is oklch(72.601% 0.15661 264.052)
- `srgb$v 内で混合した結果は、 少し~purpleになる ⇒ `50% 50% 100%^rgb `rgb(50% 50% 100)^v ◎ mix in srgb is rgb(50% 50% 100%) which is also a bit purple
この例は、 `hsl$v 色~空間において 2 つの色を混合する — うち一方の色は `srgb$v 色域の外側にある。 ◎ This example is a mix of two colors, in hsl color space, where one of the colors to be mixed is outside the sRGB gamut.
color-mix(in hsl, color(display-p3 0 1 0) 80%, yellow);
計算は次に従う: ◎ The calcuation is as follows:
- `color(display-p3 0 1 0)^v は、 ~sRGB色域の外側にある ⇒ `color(srgb -0.5116 1.01827 -0.3107)^v ◎ color(display-p3 0 1 0) is color(srgb -0.5116 1.01827 -0.3107) which is outside the sRGB gamut
- `hsl$v に変換される ⇒ `hsl(127.879 301.946 25.334)^v ◎ Converted to hsl hsl(127.879 301.946 25.334)
- `yellow^vc = `hsl(60 100% 50%)^v ◎ yellow is hsl(60 100% 50%)
- 混合した色相 = 127.879 ~MUL 0.8 ~PLUS 60 ~MUL 0.2 = 114.3032 ◎ the hue is 127.879 × 0.8 + 60 × 0.2 = 114.3032
- 混合した彩度 = 301.946 ~MUL 0.8 ~PLUS 100 ~MUL 0.2 = 261.5568 ◎ the saturation is 301.946 × 0.8 + 100 × 0.2 = 261.5568
- 混合した明度 = 25.334 ~MUL 0.8 ~PLUS 50 ~MUL 0.2 = 30.2672 ◎ the lightness is 25.334 × 0.8 + 50 × 0.2 = 30.2672
- 混合した結果は ⇒ `hsl(114.3032 261.5568 30.2672)^v = `color(srgb -0.3387 1.0943 -0.48899)^v ◎ the mixed result is hsl(114.3032 261.5568 30.2672) which is color(srgb -0.3387 1.0943 -0.48899)
3.4. `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.
この例は、 全~不透明でない[ ~red, ~green ]を[ 25%, 75% ]の割合で~sRGB内で混合する。 以下、[ 正しい(`乗算済み$)作業-法, 不正な(乗算済みでない)作業-法 ]を順に示す。 ◎ This example is 25% semi-opaque red and 75% semi-opaque green. mixed in sRGB. Both the correct (premultiplied) and incorrect (non-premultiplied) workings are shown.
color-mix(in srgb, rgb(100% 0% 0% / 0.7) 25%, rgb(0% 100% 0% / 0.2));
正しい計算は、次に従う: ◎ The calcuation is as follows:
- `rgb(100% 0% 0% / 0.7)^vc を乗算済みにした結果は ⇒ [0.7, 0, 0] ◎ rgb(100% 0% 0% / 0.7) when premultiplied, is [0.7, 0, 0]
- `rgb(0% 100% 0% / 0.2)^vc を乗算済みにした結果は ⇒ [0, 0.2, 0] ◎ rgb(0% 100% 0% / 0.2) when premultiplied, is [0, 0.2, 0]
- これら乗算済みを補間した結果は ⇒# [0.7 ~MUL 0.25 ~PLUS 0 ~MUL (1 ~MINUS 0.25), 0 ~MUL 0.25 ~PLUS 0.2 ~MUL (1 ~MINUS 0.25), 0 ~MUL 0.25 ~PLUS 0 ~MUL (1 ~MINUS 0.25)] = [0.175, 0.150, 0] ◎ the premultiplied, interpolated result is [0.7 * 0.25 + 0 * (1 - 0.25), 0 * 0.25 + 0.2 * (1 - 0.25), 0 * 0.25 + 0 * (1 - 0.25)] which is [0.175, 0.150, 0]
- 補間した~alphaは ⇒# 0.7 ~MUL 0.25 ~PLUS 0.2 ~MUL (1 ~MINUS 0.25) = 0.325 ◎ the interpolated alpha is 0.7 * 0.25 + 0.2 * (1 - 0.25) = 0.325
- 非乗算済みにした結果は ⇒# [0.175 ~DIV 0.325, 0.150 ~DIV 0.325, 0 ~DIV 0.325] = [0.53846, 0.46154, 0] ◎ the un-premultiplied result is [0.175 / 0.325, 0.150 / 0.325, 0 / 0.325] which is [0.53846, 0.46154, 0]
- 混合した結果の色は ⇒ `53.846%, 46.154%, 0%, 0.325^rgb `color(srgb 0.53846 0.46154 0 / 0.325)^v ◎ so the mixed color is color(srgb 0.53846 0.46154 0 / 0.325)
`不正^emな計算: ◎ The incorrect calculation would be:
- 補間した結果は ⇒# [1 ~MUL 0.25 ~PLUS 0 ~MUL (1 ~MINUS 0.25), 0 ~MUL 0.25 ~PLUS 1 ~MUL (1 ~MINUS 0.25), 0 ~MUL 0.25 ~PLUS 0 ~MUL (1 ~MINUS 0.25)] = [0.25, 0.75, 0] ◎ the interpolated result is [1 * 0.25 + 0 * (1 - 0.25), 0 * 0.25 + 1 * (1 - 0.25), 0 * 0.25 + 0 * (1 - 0.25)] which is [0.25, 0.75, 0]
- なので、`不正^emな混合した色は ⇒ `25%, 75%, 0%, 0.325^rgb `color(srgb 0.25 0.75 0 / 0.325)^v ◎ so the incorrect mixed color is color(srgb 0.25 0.75 0 / 0.325)
[ 正しい結果, 不正な結果 ]には、 `かなり^emの相違があり, ~DeltaE 2000 で 30.7 もある。 ◎ This is a huge difference; the ΔE2000 between the correct and incorrect results is 30.7!
百分率の正規化が`~alpha乗算子$を生成するときの計算は、 追加的な最後の段があることを除いて,同じになる。 ◎ When the percentage normalization generates an alpha multiplier, the calculation is the same except for an additional last step.
この例は、前と類似な例であり, 全~不透明でない[ ~red, ~green ]を~sRGB内で[ 25%, 75% ]の~~割合で混合する。 ◎ This example is similar to the previous one, 25% semi-opaque red and 75% semi-opaque green. mixed in sRGB.
しかしながら,この事例では、 混合-百分率が[ 1 個目の色は 20%, 2 個目の色は 60% ]として指定されている。 これらを加算すると 80% になるので、 `~alpha乗算子$は 0.8 になる。 ◎ However in this case the percentages are specified as 20% of the first color and 60% of the second. This adds to 80% so the alpha multiplier is 0.8.
混合-百分率は,係数 [ 1 ~DIV 0.8 = 1.25 ]で拡縮され、 結果の[ 20% ~MUL 1.25 = 25% ], [ 60% ~MUL 1.25 = 75% ]は,前の例と同じ混合-百分率を与える。 ◎ The mix percentages are then scaled by a factor of 100/80: 20% * 100/80 = 25% 60% * 100/80 = 75% giving the same final mix percentages as the previous example.
color-mix(in srgb, rgb(100% 0% 0% / 0.7) 20%, rgb(0% 100% 0% / 0.2) 60%);
計算は、次に従う: ◎ The calcuation is as follows:
- `rgb(100% 0% 0% / 0.7)^vc を乗算済みにした結果は ⇒ [0.7, 0, 0] ◎ rgb(100% 0% 0% / 0.7) when premultiplied, is [0.7, 0, 0]
- `rgb(0% 100% 0% / 0.2)^vc を乗算済みにした結果は ⇒ [0, 0.2, 0] ◎ rgb(0% 100% 0% / 0.2) when premultiplied, is [0, 0.2, 0]
- これら乗算済みを補間した結果は ⇒# [0.7 ~MUL 0.25 ~PLUS 0 ~MUL (1 ~MINUS 0.25), 0 ~MUL 0.25 ~PLUS 0.2 ~MUL (1 ~MINUS 0.25), 0 ~MUL 0.25 ~PLUS 0 ~MUL (1 ~MINUS 0.25)] = [0.175, 0.150, 0] ◎ the premultiplied, interpolated result is [0.7 * 0.25 + 0 * (1 - 0.25), 0 * 0.25 + 0.2 * (1 - 0.25), 0 * 0.25 + 0 * (1 - 0.25)] which is [0.175, 0.150, 0]
- 補間した~alphaは ⇒# 0.7 ~MUL 0.25 ~PLUS 0.2 ~MUL (1 ~MINUS 0.25) = 0.325 ◎ the interpolated alpha is 0.7 * 0.25 + 0.2 * (1 - 0.25) = 0.325
- 非乗算済みにした結果は ⇒# [0.175 ~DIV 0.325, 0.150 ~DIV 0.325, 0 ~DIV 0.325] = [0.53846, 0.46154, 0] ◎ the un-premultiplied result is [0.175 / 0.325, 0.150 / 0.325, 0 / 0.325] which is [0.53846, 0.46154, 0]
- なので、混合した結果の色は ⇒ `53.846%, 46.154%, 0%, 0.325^rgb `color(srgb 0.53846 0.46154 0 / 0.325)^v ◎ so the mixed color would be color(srgb 0.53846 0.46154 0 / 0.325)
- `~alpha乗算子$ 0.8 があるので、 混合した結果の~alphaは,実際には 0.325 ~MUL 0.8 = 0.260 になる。 なので、混合した結果の色は,実際には ⇒ `53.846%, 46.154%, 0%, 0.260^rgb `color(srgb 0.53846 0.46154 0 / 0.260)^v ◎ there is a 0.8 alpha multiplier, so the alpha of the mixed result is actually 0.325 * 0.8 = 0.260 so the mixed color is actually color(srgb 0.53846 0.46154 0 / 0.260)
注記: 非乗算済み化するときには、[ 補間した~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. 相対~色
4.1. 相対~色~用の処理~model
`~level 4$ までは、 `色~関数$は,[ すべての色~channelを直に指定する,絶対的な方式 ]でしか色を指定できなかった。 ◎ In previous levels of this specification, the color functions could only specify colors in an absolute manner, by directly specifying all of the color channels.
新たな `相対~色~構文@ ( `relative color syntax^en )は、 `現代の色~構文$を拡張して, 既存の色を`色~関数$を利用して改変することを許容する。 それは、 `起点~色@ ( `origin color^en )を指定する — その場合,各~色~channelは (および、~alpha~channelが指定された場合はそれも)、[ 直に指定する ]ことも[ 起点~色からとる (場合によっては,`~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 channel (and the alpha channel, 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.
すべての演算は、 `相対~色~関数$の`色~空間$の下で行われる。 `起点~色$用に `元々指定された色~空間@ が当の`色~関数$用の色~空間と異なる場合、 各~channelから値をとれるようにするため, `起点~色$は,まず後者の色~空間へ変換される。 `変換-済みな起点~色@ は、[ この変換が要求される場合は,変換した結果/ 他の場合は,そのまま`起点~色$ ]を参照rする。 `~channel~keyword$は、 `起点~色$`ではなく^em,相対~色の色~空間を参照rする。 ◎ 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 channels and channel 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).
相対~色~構文が利用されたときは、 各~channelの値は,[ 直に指定されたもの, 色~空間の変換から発生したもの ]どちらであろうが: ◎ ↓
- 色~channelの値は、 基準~範囲へは`切詰められず^em,そのままに維持される。 これは、 色域~外にある値を — 行先~色~空間に それを表現する能力があるならば — 保全する。 ◎ When relative color syntax is used, color channel 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~channelの値は、 基準~範囲へ`切詰められる^em。 ◎ However, when relative color syntax is used, alpha channel 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.
`~channel~keyword$は — ほとんどの`相対~色~構文$の利用では、 対応する引数にて利用することになろうが — どの位置でも利用できる。 ◎ While most uses of relative color syntax will use the channel keywords in their corresponding argument, you can use them in any position.
ある成分【`~channel~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.
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~channelが指定された場合、 これには,それも含まれる。 ◎ This includes the optional alpha channel, if specified.
- `起点~色$が指定されなかった場合、 当の関数は,`相対~色$ではない。 ◎ If no origin color is specified, the function is not a relative color.
- `起点~色$が指定された場合、 残りの各~引数は — 通常通り直に指定する他にも — [ `起点~色$を相対~色の`色~空間$へ変換した結果 ]を成す ある~channelを参照rしている `~channel~keyword@ としても指定できる。 これらの~keywordは、 `~math関数$内でも利用でき,`起点~色$の各~channelを動的に改変する。 ◎ If an origin color is specified, the remaining arguments can either be specified directly, as normal, or be specified as a channel keyword referring to one of the channels 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 channels.
- `相対~色~構文$においても、 引数が省略可能かどうかは,【元の構文から】変化しない。 ◎ 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.
`~channel~keyword$は、 元々は[ `percentage$t / `angle$t ]として指定されていた場合でも, `number$t を返す: ◎ The channel keywords return a <number>; 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].
例えば,ある色が `percentage$t を利用して指定された場合、 同じ色~空間~内の`相対~色$には, `number$t 形に解決した結果が利用される: ◎ For example, if a color is specified using <percentage>, then RCS in the same colorspace will use the resolved <number> form:
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); }
この例では、 指定された百分率は `number$t に解決され, 【`変換-済みな起点~色$として】 `oklab(0.543 -0.09 -0.02)^v を与える。 結果の`相対~色$は ⇒# `oklab/l$ck は 1 ~MINUS 0.543 = 0.457 / `oklab/a$ck は −0.09 × 0.8 = −0.072 / `oklab/b$ck は −0.02 (変化しない) ◎終 になるので, `oklab(0.457 -0.072 -0.02)^v になる。 ◎ In this example, the specified percentages are resolved to numbers, giving oklab(0.543 -0.09 -0.02). The resulting RCS color has l = 1 - 0.543 = 0.457, a = -0.09 * 0.8 = -0.072, and b is unchanged at -0.02: oklab(0.457 -0.072 -0.02).
例えば,`起点~色$が色相が度数による `angle$t で指定された場合、 同じ色~空間~内の`相対~色$は, `number$t 形に解決した結果を利用することになる: ◎ For example, if the origin color has a hue <angle> specified in degrees, then RCS in the same colorspace will use the resolved <number> form:
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)); }
この例における結果の`相対~色$は、 `oklch(0.526 0.115 134.6)^v になる。 ◎ In this example the resulting RCS color is oklch(0.526 0.115 134.6).
起点~色の色相を与える `angle$t が `rad$u や `turn$u など,別の単位で指定されていた場合でも、 解決した結果の `number$t は,度数になる。 ◎ Had the origin color hue <angle> been specified in another unit, such as radians or turns, still the resolved <number> would be the number of degrees.
`~math関数$内で`~channel~keyword$を利用すれば、 もっと高度な仕方で`起点~色$を操作できる。 ◎ By using the channel keywords in a math function, an origin color can be manipulated in more advanced ways.
html { --color: green; } .foo { --darker-accent: lch(from var(--color) calc(l / 2) c h); }
この例では、 `起点~色$を その明度を半分に抑えて暗化する — 当の色の他の側面を変更することなく。 ◎ In this example, the origin color is darkened by cutting its lightness in half, without changing any other aspect of the color.
`起点~色$は色~keywordである(したがって,~sRGBに属する)が、 `lch$f 関数~内で利用されているので,自動的に~LCH色として解釈されることにも注意。 ◎ Note as well that the origin color is a color keyword (and thus, sRGB), but it’s automatically interpreted as an LCH color due to being used in the lch() function.
例えば,ある~theme色が不透明として指定されているが、 特定0の~instanceに限り,部分的に透明にする必要がある場合: ◎ For example, if a theme color is specified as opaque, but in a particular instance you need it to be partially transparent:
html { --bg-color: blue; } .overlay { background: rgb(from var(--bg-color) r g b / 80%); }
この例では、 `起点~色$の[ `r^, `g^, `b^ ]~channelは変更されない — そのことは、 それらの値を`起点~色$から取り込む~keywordを指定することにより指示される。 一方で,不透明度は、 `起点~色$の不透明度に関わらず,少しだけ透明な `80%^v に設定される。 ◎ In this example, the r, g, and b channels of the origin color are unchanged, indicated by specifying them with the keywords drawing their values from the origin color, but the opacity is set to 80% to make it slightly transparent, regardless of what the origin color’s opacity was.
~Display-P3色が~sRGBの色域の外側にあっても、 切詰められないので,依然として表現できる。 ◎ For example, a Display P3 color which is outside the gamut of sRGB can still be represented, as it is not clipped.
--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));
ここで `--vivid-yellow^p を~sRGBへ変換した結果は、 `rgb(100% 100% -34.63%)^v になり, 負な~blue成分は切詰められない。 当の`相対~色~関数$を計算した結果は、 `rgb(100% 100% 15.37%)^vc になる。 ◎ Here --vivid-yellow, once converted to sRGB, is rgb(100% 100% -34.63%) and the negative blue component is not clamped. The result of the RCS calculation is rgb(100% 100% 15.37%)
起点~色の~alphaが 0.7 で,それを 2 倍するよう試みた場合、 結果の~alphaは, 1.4 ではなく 1 になる。 ◎ For example, attempting to double an alpha of 0.7 in the origin color results in an alpha in the result of 1, not 1.4.
--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));
`~channel~keyword$を通常とは異なる位置で利用して, 色を~grayscale化する大まかな近似を行う例: ◎ For example, to do a rough approximation of grayscaling a color:
--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));
これを利用すれば、[ `red$vN は `rgb(76.5 76.5 76.5)^v / `lime$vN は `rgb(150.45 150.45 150.45)^v / `blue$vN は `rgb(28.05 28.05 28.05)^v【!rgb(150.45 150.45 150.45)】 ]になる 【 28.05 = 255 × 0.11, 等々】。 `darkolivegreen$vN (~RGB値 `rgb(85 107 47)^v )の様な より~~中間的な色は、 およそ `rgb(93.8 93.8 93.8)^v になる。 ◎ Using this, red would become rgb(76.5 76.5 76.5), lime would become rgb(150.45 150.45 150.45), and blue would become rgb(150.45 150.45 150.45). A more moderate color, like darkolivegreen, which has RGB values rgb(85 107 47), would become rgb(93.8 93.8 93.8).
(大まかなわけは、 第一に[ これは,輝度~計算の様な見かけであるが、[ ~red, ~green, ~blue ]値は,[ 光に線形ではなく,~gamma符号化された空間 ]内で操作される ]からであり, 第二に[ 【 `calc^f 内の】重み付け係数は、 ~sRGB用のそれではなく,廃用な~NTSC色~空間~用のそれである ]からである。) ◎ (Rough because firstly, although this looks like a luminance calculation, the red green and blue values are manipulated in gamma-encoded space rather than linear-light; secondly, the weighting factors are those for the obsolete NTSC color space, not sRGB.)
(この例は、 構文を~~説明するためでしかないことにも注意。 `oklch$f 関数を利用すれば、 もっと容易かつ正確aに色を~grayscale化できる — その色~空間は、 ヒトの知覚において より正確aなので: `oklch(from var(--color) l 0 h)^v は、 明度を保全しつつ,色の “~~鮮やかさ” を決定する色度を 0 化する。) ◎ (Note, too, that this is just to illustrate the syntax; an easier and more accurate way to grayscale a color is to use the oklch() function, as that color space is more accurate to human perception: oklch(from var(--color) l 0 h) preserves the lightness, but zeroes out the chroma, which determines how "colorful" the color is.)
~alpha用の`~channel~keyword$を利用する例 ⇒ `color(from color(srgb 0 0 0 / 60%) srgb alpha 0.6 0.6 / 0.9)^v ◎終 の~alpha成分は、 `number$t として解決され, 0.6 を与える。 したがって、 結果の色は ⇒ `60% 60% 60% / 0.9^rgb `color(srgb 0.6 0.6 0.6 / 0.9)^v ◎ For example, • color: color(from color(srgb 0 0 0 / 60%) srgb alpha 0.6 0.6 / 0.9); ◎ The alpha component is resolved as a <number>, giving 0.6; thus the resulting color is color(srgb 0.6 0.6 0.6 / 0.9).
しかしながら、 次の例 ⇒ `rgb(from rgb(0 0 0 / 60%) alpha 153 153 / 0.9)^v ◎終 では,~alphaは再び 0.6 に解決されるが、 `rgb$f 構文における色~成分の範囲 0 〜 255 に因り,結果は `rgb(153 153 153 / 0.9)^vc `にはならず^em,かなり異なる色になる ⇒ `0.235% 60% 60% / 0.9^rgb `rgb(0.6 153 153 / 0.9)^v ◎ However, in this second example, again the alpha resolves to 0.6, giving a very different color due to the color component range of 0 to 255 in rgb() syntax: different color due to the color component range in legacy rgb() syntax: • color: rgb(from rgb(0 0 0 / 60%) alpha 153 153 / 0.9); ◎ which results in rgb(0.6 153 153 / 0.9) and not rgb(153 153 153 / 0.9).
この例では、 `起点~色$は無彩色であり,欠落~色相を伴うので、 `相対~色~構文$も欠落~色相を伴う — その結果、 その色を利用している~gradientに影響する。 ◎ In this example the achromatic origin color has a missing hue; the relative color also has a missing hue, which affects a gradient using that color.
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); }
`--bg^p の値を~OKLChへ変換した結果は, `oklch(0.592 0.009 17.42)^v になるが、 `相似的な成分$である色相は`先へ運ばれ$, `oklch(0.592 0.009 none)^v を与える。 `相対~色~関数$においては、 この値が利用され, より暗な色 `oklch(0.474 0.009 none)^v を与える。 ◎ The value of --bg when converted to OKLCh is oklch(0.592 0.009 17.42) but the analogous hue component is carried forward giving oklch(0.592 0.009 none). These values are then used in the relative function, giving the darker color oklch(0.474 0.009 none).
~gradientにおける明な~green【終端~色 `#4C3^v 】は, `oklch(0.743 0.222 141.6)^v なので、 他方の色【始端~色 `--darker-bg^p 】は, 補間されるとき その色相をとる — すなわち、 `34.96% 36.56% 34.72%^rgb `oklch(0.474 0.009 141.6)^v になる。 ◎ The light green in the gradient is oklch(0.743 0.222 141.6), and so, when interpolated, the other color take that hue, becoming oklch(0.474 0.009 141.6).
したがって、 ~gradientの~greenがかった色相は一定になる。 ◎ Thus, the gradient will have a constant greenish hue.
色相が`先へ運ばれ$なかったとするなら、 ~grayがかった `--darker-bg^p の色相は 0 になる — その結果、 ~gradientの始端は,望ましくない~redがかった濃淡になる。 ◎ If an implementation failed to do this carrying forward, the grayish --darker-bg would have a hue of 0, giving an undesirable reddish tint at the start of the gradient.
しかしながら,欠落~値に対し計算が行われた場合、 `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 ]関数の中で許容される`~channel~keyword$は: ◎ Within a relative color syntax rgb() or rgba() function, the allowed channel keywords are:
- `rgb/r@ck / `rgb/g@ck / `rgb/b@ck ⇒ ~sRGBに`変換-済みな起点~色$の[ ~red/~green/~blue ]~channelに対応する `number$t を与える。 255.0 が 100% と等価。 ◎ r, g, and b are all <number>s that correspond to the origin color’s red, green, and blue channels 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 )を表す (以下も同様)。 】
~sRGB色~空間~内で色~channelを操作するには: ◎ To manipulate color channels in the sRGB color space:
rgb(from indianred 255 g b)
これは、 ~sRGB値 `indianred^vc( `rgb(205 92 92)^v )をとり,~red~channelを 255 に置換する。 その結果は、 `rgb(255 92 92)^vc になる。 ◎ This takes the sRGB value of indianred (205 92 92) and replaces the red channel with 255 to give rgb(255 92 92).
~sRGB用の`相対~色~構文$は、 ~RGB用の`旧来の色~構文$には適用-可能でない。 ◎ Relative sRGB color syntax is only applicable to the non-legacy RGB syntactic forms.
例えば、 ~commaを伴う`旧来の色~構文$ `rgba$f を利用しようとする次の試みは,不正になる。 ◎ For example, this attempt to use the rgba legacy color syntax with commas would be incorrect
rgba(from darkblue 16, 32, b, 0.5 )
代わりに,次を利用すること: ◎ Instead, use
rgb(from darkblue 16 32 b / 0.5 )
これは、 `darkblue^vc の~sRGB値 (0 0 139) をとって,[ ~red, ~green, ~alpha ]~channelを置換して, `rgb(16 32 139 / 0.5)^vc を与える ◎ This takes the sRGB value of darkblue (0 0 139) and replaces the red, green and alpha channels to give rgb(16 32 139 / 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 ]関数の中で許容される`~channel~keyword$は: ◎ Within a relative color syntax hsl() or hsla() function, the allowed channel 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%.
色相~角度に 180° を加算して,補色を与える例: ◎ This adds 180 degrees to the hue angle, giving a complementary color.
--accent: lightseagreen; --complement: hsl(from var(--accent) calc(h + 180) s l);
`--accent^p の値 `lightseagreen^vN は `hsl(177deg 70% 41%)^vc なので、 `--complement^p は `hsl(357deg 70% 41%)^vc になる。 ◎ lightseagreen is hsl(177deg 70% 41%), so --complement is hsl(357deg 70% 41%)
~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 関数の中で許容される`~channel~keyword$は: ◎ Within a relative color syntax hwb() function, the allowed channel 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 関数の中で許容される`~channel~keyword$は: ◎ Within a relative color syntax lab() function, the allowed channel 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%.
基底~色の透明度を調整する複数の仕方: ◎ Multiple ways to adjust the transparency of a base color:
- `lab(from var(--mycolor) l a b / 100%)^v は、 `var(--mycolor)^v の~alphaを 1.0 に設定する — 元は何であったかに関わらず。 ◎ lab(from var(--mycolor) l a b / 100%) sets the alpha of var(--mycolor) to 1.0, regardless of what it originally was.
- `lab(from var(--mycolor) l a b / calc(alpha * 0.8))^v は、 `var(--mycolor)^v の~alphaを元の値の 20% だけ抑制する。 ◎ lab(from var(--mycolor) l a b / calc(alpha * 0.8)) reduces the alpha of var(--mycolor) by 20% of its original value.
~Labは,可視なすべての色を包摂するので、 すべての調整は色域~内に~~収まり,そのイミで~~情報は失われないことに注意。 これは、~sRGBに基づく関数( `rgb^f, `hsl^f, `hwb^f など)における~alpha調整には該当しない — それは、 ~alpha透明度を調整することに加え,[ ~HSL/~HWB ]の計算~用に必要yな段として~sRGBへ変換することになるので。 ◎ Note that all the adjustments are lossless in the sense that no gamut clipping occurs, since lab() encompasses all visible color. This is not true for the alpha adjustments in the sRGB based functions (such as 'rgb()', 'hsl()', or 'hwb()'), which would also convert to sRGB as a necessary step for calculation of HSL or HWB, in addition to adjusting the alpha transparency.
正確に同じ明度を保ちながら,色を無~彩度な~grayにする: ◎ Fully desaturating a color to gray, keeping the exact same lightness:
--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 関数の中で許容される`~channel~keyword$は: ◎ Within a relative color syntax oklab() function, the allowed channel 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 関数の中で許容される`~channel~keyword$は: ◎ Within a relative color syntax lch() function, the allowed channel 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%.
`lch(from peru calc(l * 0.8) c h)^v は、 `peru^vc ( `lch(62.2532% 54.0114 63.6769)^v ) より 20% 暗な色を生産する — その色度と色相が~~保たれるよう。 結果は `57.58% 32.47% 3.82%^rgb `lch(49.80256 54.0114 63.6769)^v になる ◎ lch(from peru calc(l * 0.8) c h) produces a color that is 20% darker than peru or lch(62.2532% 54.0114 63.6769), with its chroma and hue left unchanged. The result is lch(49.80256 54.0114 63.6769)
これは、色相~角度に 180° を加算して,補色を与える: ◎ This adds 180 degrees to the hue angle, giving the complementary color.
--accent: lightseagreen; --complement: lch(from var(--accent) l c calc(h + 180));
`lightseagreen^vc は `lch(65.4937 39.4484 190.1013)^v なので、 `--complement^p は `88.2814% 51.1047% 58.3039%^rgb `lch(65.4937 39.4484 370.1013)^v になる。 ◎ lightseagreen is lch(65.4937 39.4484 190.1013), so --complement is lch(65.4937 39.4484 370.1013)
正確に同じ明度を保ちながら,色を無~彩度な~grayにする: ◎ Fully desaturating a color to gray, keeping the exact same lightness:
--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%) */
次の結果は、 彩度が`~~復活する^em(色相は保全されているので): ◎ But now (since the hue was preserved) re-saturating again
--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.
この例では、 新たな色 — 同じ明度, 色度を伴いつつ,色相は 120° 相違する色 — を生産することを目指す。 `起点~色$は~RGB色域の内側にあるが,~LCH内で色相を回転すると色域~外にある色を生産する。 ◎ In this example, the aim is to produce a new color with the same Lightness and Chroma, but the triad (hue differs by 120 degrees). The origin color is inside the RGB gamut, but rotating the hue in LCH produces an out of gamut color.
--mycolor: `86.1% 33.4% 97.6%^rgb lch(60% 90 320); lch(from var(--mycolor) l c calc(h - 120));
これは、色度がごく高い~blue-green `lch(60% 90 200)^v = `color(srgb -0.6 0.698 0.772)^v を与えるので,~sRGBの色域~外になる(負な~red値)。 それは、 `display-p3$v でも `rec2020$v ですら色域~外になる(順に, `color(display-p3 -0.46 0.68 0.758)^v, `color(rec2020 -0.14 0.623 0.729)^v になる)。 ◎ This gives a very high-chroma blue-green, lch(60% 90 200) which is color(srgb -0.6 0.698 0.772) and thus out of gamut (negative red value) for sRGB. Indeed, it is out of gamut for display-p3: color(display-p3 -0.46 0.68 0.758) and even rec2020: color(rec2020 -0.14 0.623 0.729).
~sRGB色域の内側で最も近い色は、 `lch(60.71% 37.56 201.1)^v — すなわち `rgb(0% 64.2% 66.3%)^vc — になり、 色度は大きく異なる( `90^v ではなく `37.56^v )。 ◎ The closest color inside the sRGB gamut would be lch(60.71% 37.56 201.1) which is rgb(0% 64.2% 66.3%). The difference in chroma (37.5, instead of 90) is huge.
同じ演算を~HSL内で遂行すると,色域~内に入る結果を返すことになる。 が、それは他を満たしていない: ◎ Performing the same operation in HSL will return an in-gamut result. But it is unsatisfactory in other ways:
--mycolor: `86.1% 33.4% 97.6%^rgb lch(60% 90 320); hsl(from var(--mycolor) calc(h - 120) s l);
~HSLにおいては、 `--mycolor^p は `86.1% 33.4% 97.6%^rgb `hsl(289.18 93.136% 65.531%)^v になるので, 120° 減算した結果は `33.428% 97.634% 86.056%^rgb `hsl(169.18 93.136% 65.531%)^v を与える。 その結果を変換して~LCHに戻した結果は、 `33.428% 97.634% 86.056%^rgb `lch(89.0345% 49.3503 178.714)^v になる — 見て判るとおり、 ~HSLにおける色相~回転-に因り, 明度は 60% から 89% に跳ね上がり, 色度は 90 から 49 へ落とされ, 色相は 実際には 141° 変化する — 120° ではなく。 ◎ In HSL, --mycolor is hsl(289.18 93.136% 65.531%) so subtracting 120 degrees gives hsl(169.18 93.136% 65.531%). Converting that result back to LCH lch(89.0345% 49.3503 178.714) we see that, due to the hue rotate in HSL, Lightness shot up from 60% to 89%, the Chroma has dropped from 90 to 49, and the Hue actually changed by 141 degrees, not 120.
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 関数の中で許容される`~channel~keyword$は: ◎ Within a relative color syntax oklch() function, the allowed channel 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.
この例では再び、 新たな色 — 同じ明度, 色度を伴いつつ,色相は 120° 相違する色 — を生産することを目指す。 この例では、 ~OKLCh内で操作を行う。 `起点~色$は,~RGB色域の内側にあるが、 ここでも,~OKLCh内で色相を回転すると色域~外にある色を生産する。 ◎ In this example, the aim is again to produce a new color with the same Lightness and Chroma, but the triad (hue differs by 120 degrees). In this example, we will do the manipulation in OKLCh. The origin color is inside the RGB gamut, but rotating the hue in OKLCh again produces an out of gamut color.
--mycolor: `86.1% 33.4% 97.6%^rgb lch(60% 90 320); oklch(from var(--mycolor) l c calc(h - 120));
~OKLChにおいては、 `--mycolor^p は `86.1% 33.4% 97.6%^rgb `oklch(0.69012 0.25077 319.893)^v になる。 色相から 120 を減算した結果は、 色度がごく高い~blue-green `oklch(0.69012 0.25077 199.893)^v になる。 それは,~sRGBにおいては `color(srgb -0.6018 0.7621 0.8448)^v であり、 負な~red成分が指示するとおり,~sRGBの色域~外になる。 ~OKLCh色度を抑制してこれを色域の中へ持ち込むと `0.079% 69.282% 72.067%^rgb `oklch(0.69012 0.1173 199.893)^v が得られる。 ~OKLCh色度は、 0.251 から 0.117 へ落とされる。 ◎ --mycolor is oklch(0.69012 0.25077 319.893). Subtracting 120 from the Hue gives a very high-chroma blue-green, oklch(0.69012 0.25077 199.893) which is out of sRGB gamut, color(srgb -0.6018 0.7621 0.8448) as the negative red component indicates. Bring this into gamut by reducing OKLCh Chroma, yields oklch(0.69012 0.1173 199.893). The OKLCh chroma has dropped from 0.251 to 0.117.
5. [定義済み色~空間/~custom色~空間]内の色の指定-法: `color^f 関数
`color$f 関数は、 所与の[ 特定0の`色~空間$ ]内の色を指定することを許容する (他のほとんどの`色~関数$が暗黙的に~sRGB色~空間の中で演算するのとは~~対照的に)。 ◎ The color() function allows a color to be specified in a particular, given color space (rather than the implicit sRGB color space that most of the other color functions operate in).
この~levelでは、 `color$f 関数は,次を許容するよう拡張される: ◎ In this level the color() function is\
- `~custom色~空間$ — `~level 4$ の`定義済み色~空間$に加えて。 ◎ extended to allow custom color spaces, in addition to the predefined spaces from CSS Color 4 § 10. Predefined Color Spaces.
- 相対的な色 — 絶対的な色のみならず。 ◎ It is also extended to allow relative, rather than just absolute, colors.
その構文は、 今や,次に従う: ◎ Its syntax is now as follows:
`color@f = color( [from `color$t]? `colorspace-params$t [ / [ `alpha-value$t | `none$v ] ]? ) `colorspace-params@t = `custom-params$t | `predefined-rgb-params$t | `xyz-params$t `custom-params@t = `dashed-ident$t [ `number$t | `percentage$t | `none$v ]+ `predefined-rgb-params@t = `predefined-rgb$t [ `number$t | `percentage$t | `none$v ]{3} `predefined-rgb@t = `srgb$v | `srgb-linear$v | `display-p3$v | `a98-rgb$v | `prophoto-rgb$v | `rec2020$v `xyz-params@t = `xyz$t [ `number$t | `percentage$t | `none$v ]{3} `xyz@t = `xyz$v | `xyz-d50$v | `xyz-d65$v
`color$f 関数は、 明示的に与えられた色~空間~内の色を指定する,一連の~parameterをとる。 ◎ The color function takes parameters specifying a color, in an explicitly listed color space.
この関数は、以下に述べる `無効な色@, それ以外の `妥当な色@ どちらかを表現する。 ◎ It represents either an invalid color, as described below, or a valid color. ◎ Any color which is not an invalid color is a valid color.
色は、 `妥当な色$であっても,出力~機器(~screen/投影機/印刷機など)が生産できる色の範囲の外側になることもある。 そのような色は、 (出力~機器~用の)色~空間の `色域~外@ ( `out of gamut^en )にあるとされる。 【その否定は “色域~内( `in-gamut^en / `in gamut^en )” と称される。】 【!この定義は、文脈によっては,出力~機器に依存することになる。】 ◎ A color may be a valid color but still be outside the range of colors that can be produced by an output device (a screen, projector, or printer). It is said to be out of gamut for that color space.
`色域~外$にある色には、[ 0 以上 1 以下/ 0% 以上 100% 以下 ]の範囲に入らない成分~値がある。 それは,`無効な色$ではなく、 代わりに,表示~用には[ `相対~色計量~意図$を利用して`色域を対応付ける$ことになり、 算出d値の時点で,この範囲に入る ]ようにされる。 ◎ An out of gamut color has component values less than 0 or 0%, or greater than 1 or 100%. These are not invalid; instead, for display, they are gamut-mapped using a relative colorimetric intent which brings the values within the range 0/0% to 1/100% at computed-value time.
`妥当な色$は、 当の出力~機器(~screen/印刷機)用の[ 色域~内, `色域~外$ ]どちらかにある。 ◎ Each valid color is either in-gamut for the output device (screen, or printer), or it is out of gamut.
5.1. 相対~色~関数による色
`相対~色~構文$による `color$f 関数の中で許容される`~channel~keyword$たちは: ◎ ↓
-
`custom-params$t を利用している場合: ◎ Within a relative color syntax color() function using <custom-params>, the number and name of the allowed channel 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で命名された~channel ]に対応する `number$t を与える。 値 1.0 は 100% に対応する。 ◎ They are <number>s that correspond to the origin color’s channels 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 channel keywords are:
- `color/r@ck / `color/g@ck / `color/b@ck ⇒ ~RGB色~空間 — 【 `predefined-rgb$t が指示する】`定義済み色~空間$ — に`変換-済みな起点~色$の[ ~red/~green/~blue ]~channelに対応する `number$t を与える。 値 1.0 は 100% に対応する。 ◎ r, g, and b are all <number>s that correspond to the origin color’s red, green, and blue channels 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 channel keywords are:
- `color/x@ck / `color/y@ck / `color/z@ck ⇒ [ 関連な白色点に順応された,相対~CIE~XYZ色~空間 ]に`変換-済みな起点~色$の[ X / Y / Z ]~channelに対応する `number$t を与える。 値 1.0 は 100% に対応する。 ◎ x, y, z are all <number>s that correspond to the origin color’s X, Y and Z channels 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 channel 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:
-
`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.
-
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 にされる (これは特に,複~channel印刷機において、 追加的な~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 multichannel 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.
-
省略可能な、 ~slashで分離された `alpha-value$t — 省略-時の既定は `100%^v 。 ◎ An optional slash-separated <alpha-value>.If omitted, it defaults to 100%.
例えば,次で利用された~CIE~XYZ~D65色~空間~内の`相対~色~構文$( `--dark^p )は、 `純色度$は同じになるが, 輝度が正確に基底~色( `--base^p )の半分になる色を生成する: ◎ For example, Relative Color Syntax in the CIE XYZ D65 colorspace is used to generate a color which has the same chromaticity but exactly half the luminance of the base color:
--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));
`起点~色$は `color(xyz-d65 0.281 0.253 0.044)^v になるので、 結果の相対~色は `color(xyz-d65 0.14 0.126 0.022)^v になる。 ◎ The origin color is color(xyz-d65 0.281 0.253 0.044) and so the relative color is color(xyz-d65 0.14 0.126 0.022).
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.
次の例は、 4 種の較正-済みな色を指定する。 うち最初の 2 つは,~custom空間 (ある `SWOP-coated^en ~CMYK刷版~用, ある広-色域な 7 色~ink印刷機~用) であり、 他の 2 つは,`定義済み色~空間$( `prophoto-rgb$v, `display-p3$v )である。 各~事例において、 数量的な~parameterは範囲 0.0 〜 1.0 に入る (例えば 0 〜 255 ではなく)。 ◎ This example specifies four calibrated colors: two are custom spaces (for a SWOP-coated CMYK press, and for a wide-gamut seven-ink printer), the other two are predefined spaces (the ProPhoto RGB, and display-p3 RGB spaces). In each case, the numerical parameters are in the range 0.0 to 1.0 (rather than, for example, 0 to 255).
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 ◎用 `color-profile$at ◎値 `url$t ◎初 n/a ◎表終`src$d 記述子は、 色~profile情報を検索取得するための~URLを指定する。 ◎ The src descriptor specifies the URL to retrieve the color-profile information from.
検索取得した~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.
`外部の色~profileを~fetchする@ ときは、所与の ( `color-profile$at 規則 %規則 ) に対し:
- %応答の処理n ~LET 所与の ( `応答$ %応答, [ ~NULL/`失敗^i/~byte~stream ] %~stream ) に対し,次を走らす手続き ⇒ ~IF[ %~stream は~byte~streamである ] ⇒ %~stream から構文解析された色~profileを適用する
- `~style資源を~fetchする$( %規則 の~URL, %規則 の`親~stylesheet$, `color-profile^l, `cors^l, %応答の処理n )
注記: ~ICC~profile用の~MIME型は、 `application/vnd.iccprofile$c である。 ◎ Note: The Internet Media Type ("MIME type") for ICC profiles is application/vnd.iccprofile.
◎述 `rendering-intent@d ◎用 `color-profile$at ◎値 `relative-colorimetric$v | `absolute-colorimetric$v | `perceptual$v | `saturation$v ◎初 `relative-colorimetric$v ◎表終`色~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.
次の記述子は、[ `cyan^v, `magenta^v, `yellow^v, `black^v ]と命名される 4 個の成分が在ることを宣言する: ◎ This descriptor declares that there are four components named cyan, magenta, yellow and black:
components: cyan, magenta, yellow, black
一方で,次の記述子は、 簡素な名前を~~採用する: ◎ while this descriptor opts for terser names:
components: c,m,y,k
次の記述子は、[ `cyan^v, `magenta^v, `yellow^v, `black^v, `orange^v, `green^v, `violet^v ]と命名される 7 個の成分が在ることを宣言する: ◎ This descriptor declares that there are seven components named cyan, magenta, yellow, black, orange, green and violet:
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.
次の記述子は、 成分の名前に,うかつにも `pi$v を用いる — `相対~色~構文$においては、 期待されない結果に至る。 ◎ This descriptor unwisely calls a component pi, leading to unexpected results in Relative Color Syntax.
@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));
ここでは、 `--accent^p の 2 個目の成分~値は,円周率の 2 倍( 6.28318… )になる。 ◎ Here, the component values of --accent are 35%, 3.14159265358979 * 2 = 6.28318530717959, 4%.
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.
115gsm【 gsm は g/m2 単位(坪量)】の塗工~紙に~offset印刷するときの例 — [ `ISO 12647-2:2004 / Amd 1:2007^en, `FOGRA39^en 特性評価~data ]を利用し,~inkの総面積被覆率 ( TAC ) は 300% に制限される下で `FOGRA39$r : ◎ For example, using offset printing to ISO 12647-2:2004 / Amd 1:2007 using the FOGRA39 characterization data on 115gsm coated paper with an ink limit of 300% Total Area Coverage [FOGRA39].
@color-profile --fogra39 { src: url('https://example.org/Coated_Fogra39L_VIGC_300.icc'); } .header { background-color: color(--fogra39 0% 70% 20% 0%); }
ここでの `color$f 関数は、 まず,~profileに与えた名前を言明してから,[ ~cyan, ~magenta, ~yellow, ~black ]の順に百分率を与えている。 ◎ Here the color() function first states the name we have given the profile, then gives the percentage of cyan, magenta, yellow, and black.
この~profileにおいては、 これは次の色に解決される ⇒ `93.124% 44.098% 57.491%^rgb `lab(63.673303% 51.576902 5.811058^v ( ~EQ `rgb(93.124, 44.098% 57.491%)^v ) ◎ In this profile, this resolves to the color lab(63.673303% 51.576902 5.811058) which is rgb(93.124, 44.098% 57.491%).
所与の~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.
一群の色付けられた升目が成す格子。 A 〜 F と~labelされた 6 本の列と, 1 〜 4 と~labelされた 4 本の行がある。 ◎ A grid of colored squares. There are six columns, labelled A to F, and four rows, labelled 1 to 4.
[ 印刷-/写真- ]業界で色の忠実度を確保するために利用される,ある色~検査器。 各~patchには,測定して平均した~Lab値が示される。 各 矩形は、 ~sRGBへ変換された~Lab値を示す。 矩形の中の かすかに可視な真円は、 同じ~Lab値を `FOGRA51^en `FOGRA51$r ~ICC~profileを通過して~CMYKへ変換した結果を示す。 これらの~CMYK値は、 新たな~Lab値を得るため,同じ~ICC~profileを逆向きに通過する。 図では さらに、表示-用に~sRGBへ変換されている。 ◎ A color checker, used for ensuring color fidelity in the print and photographic industries. Averaged measured Lab values are available for each patch. The rectangles show the Lab values, converted to sRGB. The circles, which are barely visible, show the Lab values, passed through a FOGRA51 [FOGRA51] ICC profile to convert them to CMYK. The CMYK values are then passed through the same ICC profile in reverse, to yield new Lab values. These are then converted to sRGB for display.
3 行目の左端の~patchが他より可視な真円になっているのは、 その色が,利用されている `FOGRA51^en ~CMYK空間の色域から少し外側にあることによる。 ◎ The one patch with a more visible circle (third row, first patch) is because the color is slightly outside the gamut of the FOGRA51 CMYK space used.
各~patchに対し,[ 元の~Lab値, ~CMYKを通して往復した後の~Lab値 ]の間の~DeltaE 2000 を下の表tに示す。 ~DeltaE 2000 が 1 以上なら,可視になる【ヒトが差を知覚できる】。 ◎ The table below shows, for each patch, the DeltaE 2000 between the original Lab and the Lab value after round-tripping through CMYK. A DeltaE 2000 of 1 or more is just visible.
A | B | C | D | E | F | |
---|---|---|---|---|---|---|
1 | 0.06 | 0.07 | 0.03 | 0.04 | 0.06 | 0.17 |
2 | 0.03 | 0.75 | 0.05 | 0.06 | 0.03 | 0.02 |
3 | 1.9 | 0.04 | 0.06 | 0.05 | 0.02 | 0.05 |
4 | 0.03 | 0.08 | 0.03 | 0.03 | 0.04 | 0.80 |
`grade 5^en の紙に~offset印刷するときの例 — [ `ISO 12647-2:2004^en, `CGATS/SWOP TR005 2007^en 特性評価~data, ~gray成分~置換 (GCR) は中程度( `medium^en ) ]を利用し,~inkの総面積被覆率は 300% に制限される下で: ◎ This example is using offset printing to ISO 12647-2:2004 using the CGATS/SWOP TR005 2007 characterization data on grade 5 paper with an ink limit of 300% Total Area Coverage, and medium gray component replacement (GCR).
@color-profile --swop5c { src: url('https://example.org/SWOP2006_Coated5v2.icc'); } .header { background-color: color(--swop5c 0% 70% 20% 0%); }
この~profileにおいては、 この量の~CMYK(前の例と同じ百分率)は,次の色に解決される ⇒ `94.903% 45.248% 59.104%^rgb `lab(64.965217% 52.119710 5.406966)^v ( ~EQ `rgb(94.903% 45.248% 59.104%)^v ) ◎ In this profile, this amount of CMYK (the same percentages as the previous example) resolves to the color lab(64.965217% 52.119710 5.406966) which is rgb(94.903% 45.248% 59.104%).
~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^at 内で】上と同じ `--fogra39^v ~profileを利用するが,~sRGB色域の外側にある鮮やかな~greenを指定する。 しかしながら,この色は `display-p3$v 色域の内側にあるので、[ 広-色域~screen/印刷 ]においては,そのまま表示される。 ~sRGB~screen上では,【前者の `media^at 内の】鮮やかさに劣る~fallback色が利用される。 ◎ This example uses the same FOGRA39 setup as before, but specifies a bright green which is outside the sRGB gamut. It is, however, inside the display-p3 gamut. Therefore it is displayed as-is on wide gamut screens and in print, and a less intense fallback color is used on sRGB screens.
@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%); } }
この~CMYK色【 `color(--fogra39 …)^v 】は、 `lab(56.596645% -58.995875 28.072154)^v ( ~EQ `lch(56.596645% 65.33421077211648 154.5533771086801)^v ) に対応する。 これは,~sRGBにおいては `rgb(-60.568% 62.558% 32.390%)^v になり、 大幅に負な~red成分が示すとおり,色域~外にある。 ◎ This CMYK color corresponds to lab(56.596645% -58.995875 28.072154) or lch(56.596645% 65.33421077211648 154.5533771086801). In sRGB this would be rgb(-60.568% 62.558% 32.390%) which, as the large negative red component shows, is out of gamut.
結果が色域に入るまで色度を抑制すると, `lch(56.596645% 51 154.5533771086801)^v になり、 手動で指定した~fallback色 `rgb(8.154% 60.9704% 37.184%)^vc に一致する。 ◎ Reducing the chroma until the result is in gamut gives lch(56.596645% 51 154.5533771086801) which is rgb(8.154% 60.9704% 37.184%) and this has been manually specified as a fallback color.
広-色域~screen用には、 この色は `display-p3$v 色域の内側にある ( `display-p3(0.1658 0.6147 0.3533)^v になる)。 ◎ For wide gamut screens, the color is inside the display-p3 gamut (it is display-p3(0.1658 0.6147 0.3533) ).
色は 4 ~ink(~CMYK)に制約されない。 例えば,広-色域な 7 色~inkも利用できる。 ◎ Colors are not restricted to four inks (CMYK). For example, wide-gamut 7 Color ink sets can be used.
この例は、 ~CMYKOGV 7 色で印刷するために `beta FOGRA55 dataset^en `FOGRA55$r を利用する。 うち 4 種の~ink — ~black, ~cyan, ~magenta, ~yellow — は、 `FOGRA51 set^en と同じであり,同じ結果を与える。 他の 3 種の~inkは ⇒# Orange: CIELAB 65 58 88, Green: CIELAB 60 -75 0, CIELAB 22 47 -56 ◎ This example uses the beta FOGRA55 dataset [FOGRA55] for CMYKOGV seven-color printing. Four of the inks - black, cyan, magenta, and yellow - are the same as, and give the same results as, the FOGRA51 set. The other three inks are: • Orange: CIELAB 65 58 88 • Green: CIELAB 60 -75 0 • CIELAB 22 47 -56
測定~条件は M1 である — すなわち、 紙~内の蛍光染料は織り込まれ,分光光度計には~UV-cut~filterは無い。 ◎ The measurement condition is M1, which means that optical brighteners in the paper are accounted for and the spectrophotometer has no UV-cut filter.
@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. 未較正な~CMYK色: `device-cmyk^f 関数
所与の印刷機が[ `較正-済み$ではないが,特定0の~inkたちの組合n用の出力は[ 実験結果を通して, または印刷された色見本帳を介して ]既知であるとき ]は、[ ~CMYK色を機器に依存する仕方で表出する ]ことが有用になることも,ときにはある。 ◎ Sometimes, when a given printer has not been calibrated, but the output for particular ink combinations is known through experimentation, or via a printed sample swatchbook, it is useful to express CMYK colors in a device-dependent way.
注記: 実際の結果の色は未知なこともあるので、 その場合,[ ~CSS処理器は、 それを近似しようと試みる ]ことになろう。 この近似は、 実際に印刷される結果から視覚的にかけ離れる見込みが高い。 ◎ Note: Because the actual resulting color can be unknown, CSS processors might attempt to approximate it. This approximation is likely to be visually very far from the actual printed result.
`device-cmyk$f 関数により、 作者は,この仕方で色を指定できるようになる: ◎ The device-cmyk() function allows authors to specify a color in this way:
`device-cmyk@f = `legacy-device-cmyk-syntax$t | `modern-device-cmyk-syntax$t `legacy-device-cmyk-syntax@t = device-cmyk( `number$t#{4} ) `modern-device-cmyk-syntax@t = device-cmyk( `cmyk-component$t{4} [ / [ `alpha-value$t | `none$v ] ]? ) `cmyk-component@t = `number$t | `percentage$t | `none$v
`device-cmyk$f 関数の引数のうち: ◎ The arguments of the device-cmyk() function\
- 最初から 4 個の引数は、 順に,[ ~cyan, ~magenta, ~yellow, ~black ]成分を[ 範囲 0 〜 1 の実数 ]または[ 範囲 0% 〜 100% の百分率 ]で指定する — ただし、 百分率は,現代の構文( `modern-device-cmyk-syntax$t )に限られる。 実数と百分率の用法は等価であり,互いの対応関係は線形である。 この範囲~外の値も無効にはされないが、 算出d値の時点で範囲~内に切詰められる。 ◎ specify the cyan, magenta, yellow, and black components, in order, as a number between 0 and 1 or, in the modern syntax, as a percentage between 0% and 100%. These two usages are equivalent, and map to each other linearly. Values less than 0 or 0%, or greater than 1 or 100%, are not invalid; instead, they are clamped to 0/0% or 1/100% at computed-value time.
- 現代の構文における 5 個目の引数は、 色の~alpha~channelを指定し, `rgb$f 関数を成す 4 個目の引数と同じに解釈される。 省略-時の既定は `100%^v 。 ◎ In the modern syntax, the fifth argument specifies the alpha channel of the color. It’s interpreted identically to the fourth argument of the rgb() function. If omitted, it defaults to 100%.
`歴史的な理由@~TR/2011/WD-css3-gcpm-20111129/#cmyk-colors$により、 `device-cmyk$f も`旧来の色~構文$( `legacy-device-cmyk-syntax$t )を~supportする。 【不透明でない記法は無いが。】 ◎ For historical reasons, device-cmyk() also support a legacy color syntax.
概して,印刷用途の~appは、 実際に利用する色を~CMYKとして格納し, それを そのままの形で印刷機へ送信する。 しかしながら,そのような色は、 色計量の解釈がないので,[ ~gradient, 組成-法, 混色-法, 等々 ]には利用できない。 ◎ Typically, print-based applications will actually store the used colors as CMYK, and send them to the printer in that form. However, such colors do not have a colorimetric interpretation, and thus cannot be used in gradients, compositing, blending and so on.
そのようなわけで、 機器~CMYK色は,等価な色に変換されなければならない。 これは、[ ~HSL/~HWB ]から~RGBへ変換するときほど簡単ではない — 精確な変換は、 出力~機器の精確な特性に依存する。 ◎ As such, Device CMYK colors must be converted to an equivalent color. This is not trivial, like the conversion from HSL or HWB to RGB; the precise conversion depends on the precise characteristics of the output device.
`device-cmyk$f 関数の`算出d値$は、 次に従って得られる結果になるモノトスル: ◎ ↓
-
~AND↓ が満たされるならば、 当の~CMYK色を表す~Lab値:
- [ 利用者/作者/~UA ]いずれかの~stylesheetには, `device-cmyk^v 用の `color-profile$at 定義がある
- 前項の定義を成す `src$d 記述子が指定する資源を検索取得できる
- 前項の資源は、 妥当な~CMYK~ICC~profileである
- ~UAは、 ~ICC~profileを処理できる
- 他の場合、 当の~CMYK色を`素朴な変換$~algoで変換した結果の~sRGB値 ◎ Otherwise, the computed value of the device-cmyk() function must be the sRGB value of the CMYK color, as converted with the following naive conversion algorithm.
例えば,次に挙げる色は、 `color-profile$at が無いときは,`素朴な変換$を利用する下で等価になる。 ◎ For example, with no @color-profile, the following colors are equivalent, using the naive conversion.
color: `178 34 34^rgb device-cmyk(0 81% 81% 30%); color: `178 34 34^rgb rgb(178 34 34); color: `178 34 34^rgb firebrick;
~stylesheet例【どの例?】のように `color-profile$at は指定されているならば、 次に挙げる色は,色計量~変換を利用する下で等価になる。 ◎ With the @color-profile specified as in the example stylesheet, the following colors are equivalent, using colorimetric conversion.
color: `70.690% 26.851% 19.724%^rgb device-cmyk(0 81% 81% 30%); color: `70.690% 26.851% 19.724%^rgb lab(45.060% 45.477 35.459) color: `70.690% 26.851% 19.724%^rgb rgb(70.690% 26.851% 19.724%);
`素朴な変換$は、 近似するとは限らない — それには[ ~inkの色計量y, ~dot-gain, ~RGB空間の色計量y, 等々 ]の知識は無いので。 ◎ The naive conversion is necessarily approximate, since it has no knowledge of the colorimetry of the inks, the dot gain, the colorimetry of the RGB space, and so on.
一群の色付けられた升目が成す格子。 A 〜 F と~labelされた 6 本の列と, 1 〜 4 と~labelされた 4 本の行がある。 ◎ A grid of colored squares. There are six columns, labelled A to F, and four rows, labelled 1 to 4.
[ 印刷-/写真- ]業界で色の忠実度を確保するために利用される,ある色~検査器。 各~patchには,測定して平均した~Lab値が示される。 各 矩形は、 ~sRGBへ変換された~Lab値を示す。 矩形の中の真円は,同じ~Lab値を~ICC~profileを通過して~CMYKへ変換した結果を示すが、 図では さらに,`~CMYKから~RGBAへ素朴に変換-$されている。 ◎ A color checker, used for ensuring color fidelity in the print and photographic industries. Averaged measured Lab values are available for each patch. The rectangles show the Lab values, converted to sRGB. The circles show the Lab values, passed through an ICC profile to convert them to CMYK. The CMYK value are then naively converted to sRGB.
各~patchに対し,[ 元の~Lab値, ~CMYKを通して往復した後の~Lab値 ]の間の~DeltaE 2000 を下の表tに示す。 ~DeltaE 2000 が 1 以上なら,可視になる — 5 以上になると,かなり異なる色になる。 ◎ The table below shows, for each patch, the DeltaE 2000 between the original Lab and the Lab value after round-tripping through CMYK. A DeltaE 2000 of 1 or more is just visible, while 5 or more is just a different color altogether.
A | B | C | D | E | F | |
---|---|---|---|---|---|---|
1 | 11.33 | 9.36 | 5.66 | 7.52 | 12.39 | 21.58 |
2 | 6.40 | 8.79 | 11.77 | 17.16 | 11.91 | 3.97 |
3 | 12.1 | 17.00 | 3.38 | 1.94 | 18.08 | 14.97 |
4 | 1.89 | 6.56 | 7.85 | 8.76 | 9.82 | 10.29 |
6.1. 未較正な~CMYK色と~RGBに基づく色の間の素朴な変換-法
`~CMYKから~RGBAへ素朴に変換-@ するときは、所与の ( %cyan, %magenta, %yellow, %black, %alpha ) に対し:
- %w ~LET 1 ~MINUS %black
- %red ~LET `max^op( 0, ( 1 ~MINUS %cyan ) ~MUL %w )
- %green ~LET `max^op( 0, ( 1 ~MINUS %magenta ) ~MUL %w )
- %blue ~LET `max^op( 0, ( 1 ~MINUS %yellow ) ~MUL %w )
- ~RET ( %red, %green, %blue, %alpha )
`~RGBAから~CMYKへ素朴に変換-@ するときは、所与の ( %red, %green, %blue, %alpha ) に対し:
- %w ~LET `max^op( %red, %green, %blue )
- ~IF[ %w ~EQ 0 ] ⇒ ~RET ( 0, 0, 0, 1, %alpha )
- %cyan ~LET 1 ~MINUS ( %red ~DIV %w )
- %magenta ~LET 1 ~MINUS ( %green ~DIV %w )
- %yellow ~LET 1 ~MINUS ( %blue ~DIV %w )
- %black ~LET 1 ~MINUS %w
- ~RET ( %cyan, %magenta, %yellow, %black, %alpha )
【 ~RGBA → ~CMYK → ~RGBA の結果は元に戻るが、 ~CMYK → ~RGBA → ~CMYK の結果は(~~次元が一つ減るので)元に戻るとは限らない。 】
7. 使用~色~schemeに対する反応-法: `light-dark^f 関数
~system色【 `system-color$t 】は、 現在の`使用~色~scheme$に反応する能がある。 `light-dark$f 関数は、 同じ能力を作者に公開する。 ◎ System colors have the ability to react to the current used color-scheme value. The light-dark() function exposes the same capability to authors.
`light-dark@f = light-dark( `color$t, `color$t )
この関数の`算出d値$は、 `使用~色~scheme$に応じて[ `light$v または未知ならば 1 個目の引数/ `dark$v ならば 2 個目の引数 ]の`算出d色$になる。 ◎ This function computes to the computed value of the first color, if the used color scheme is light or unknown, or to the computed value of the second color, if the used color scheme is dark.
8. 必要十分な~contrastを伴う~text色の動的な指定-法: `contrast-color^f 関数
動的に作成された色が背景に利用されるとき、 必要十分な~contrastを供するように~text色を指定することは, 難題になることが多い。 `contrast-color$f 関数は、[ 指定された色によるベタな背景~上で~text色として利用される ]ときに[ 必要十分な~contrastが保証される色 ]を自動的に供する。 ◎ When colors are created dynamically, it can often be a challenge to specify a text color that provides adequate contrast with them when used as a background color. The contrast-color() function automatically provides a color with guaranteed color contrast when used as a text color on a solid background of the specified color.
注記: 判読し易さは,複階的な論題であり、 必要に足る色~contrastは、 この~puzzleを成す一片でしかない。 色~pairが必要に足る~contrastを伴うとしても、 ~textが判読し易くなることは保証されない。 それは、 様々な要因 — ~font, ~textの~size, 周囲の色, 等々 — にも依存するので。 ◎ Note: Legibility is a complex topic, and sufficient color contrast is only one piece of the puzzle. Having a color pair with sufficient contrast does not guarantee that the text will be legible, as that also depends on a variety of factors, such as the font, the size of the text, the surrounding colors, etc.
`contrast-color@f = contrast-color( `color$t max? )
`max^v を伴って指定された場合、 この関数は,[ `white^v, `black^v ]のうち[ 入力~色がベタな背景として利用されるとき,~text用に`最大^emな色~contrastを生産する方 ]に算出される。 どちらの色も同じ~contrastを生産する場合、 `white^v を返すベキである。 ◎ If max' is specified, the function computes to white or black, depending on which of the two produces _maximum_ color contrast for text when the input color is used as a solid background. If both colors produce the same contrast, the function should return white.
`max^v が省略された場合、 この関数は,[ `max^v が指定された場合に[ `white^v / `black^v ]を返す ]ならば、[ 入力~色がベタな背景として利用されるとき,~text用に~~十分な~contrastが得られる ]ほどに,`ごく^em[ 明な色/暗な色 ]を返すモノトスル (結果は[ `white^v / `black^v ]になっても`ヨイ^em)。 ◎ If max' is omitted, the function computes to a very light or very dark color (which may still be white or black), which will contrast well with the input color when used as a text color and the input color is used as a solid background. The function MUST return a light color if it would have returned white if max were specified, and a dark color if it would have returned black if max were specified.
注記: [ これらの色を[ ~white / ~black ]にどこまで近くする必要があるかに関する精確な要件 ]および[ そのために利用する色~差の測定-法 ]は、 依然として論の最中にある。 ◎ Note: The precise requirement for how close these colors need to be to white and black and what color difference measure to use for that are still under discussion.
[[ 明な色, 暗な色 ]どちらを出力するか決定するための精確な色~contrast~algo ]および[ `max^v が省略されたときに生産される精確な色 ]は、 この~levelでは,~UAにより定義される。 ◎ The precise color contrast algorithm for determining whether to output a light or dark color is UA-defined at this level, as is the precise color produced when max' is omitted.
注記: この仕様の将来~versionは、 各種[ 利用事例, 対応する~contrast~algo, 返される色 ]に対する制御をもっと導入するものと期待される。 ◎ Note: Future versions of this specification are expected to introduce more control over both the contrast algorithm(s) used, the use cases, as well as the returned color.
~UAには、[ 明な色, 暗な色 ]どちらにするか裁定する際に,単純に `WCAG21$r `§ 達成基準: ~contrast(最小)@~TR/WCAG21/#contrast-minimum$ による~contrast比~algoを利用しないことを勧める — それには、 `いくつか既知な課題@https://www.cedc.tools/article.html$があるので。 それでも、 この関数が返す色は,この達成基準を満たすベキである — 多くの作者は、 `AA large^en な【`“字が大きい”@~TR/WCAG21/#dfn-large-scale$】~text用には, これを義務付ける法的な要件を満たす必要があるので。 ◎ UAs are advised to not simply use the WCAG 2.1 section 1.4.3 Contrast (Minimum) contrast ratio algorithm to decide between light and dark colors, as it has several known issues. However, colors returned by this function should still meet the WCAG 2.1 section 1.4.3 Contrast (Minimum) for AA large text, as many authors need to meet legal requirements that mandate this.
9. 色~補間
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 | `a98-rgb$v | `prophoto-rgb$v | `rec2020$v | `lab$v | `oklab$v | `xyz$v | `xyz-d50$v | `xyz-d65$v `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. `color$t 値の解決-法
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 値の解決-法
`device-cmyk$f の`算出d値$は、 次が成す~pairになる — `使用~値$は算出d値と同じになる:
- 指定された機器に特有な~CMYK色 (各~成分は `percentage$t ではなく `number$t になる)
- 指定された~alpha~channel ⇒# `percentage$t ではなく `number$t になるとする / 未指定な場合の既定は、 不透明になるとする
`実際の値$は、 当の演算に基づいて変わり得る: ◎ 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.
例えば, `93.124% 44.098% 57.491%^rgb `device-cmyk(0% 70% 20% 0%)^v に対しては: ◎ For example, • device-cmyk(0% 70% 20% 0%)
- その[ 指定d値/実際の値 ]は ⇒ `93.124% 44.098% 57.491%^rgb `device-cmyk(0 0.7 0.2 0)^v ◎ has the specified and actual value • device-cmyk(0 0.7 0.2 0)
- その使用~値は、 実装が~ICC~profileを解する, かつ適切な~profileが~install済みならば ⇒ `93.124% 44.098% 57.491%^rgb `lab(63.673% 51.577 5.811)^v ◎ and will, if the implementation understands ICC profiles and has an appropriate profile installed, have the used value • lab(63.673% 51.577 5.811)
注記: 他の色と同じく、 使用~値は~scriptからは可用でない。 ◎ Note: As with all colors, the used value is not available to script.
11. 直列化
この節は、[ `~level 4$ の `§ ~color_t 値の直列化-法$ ]を拡張して,[ `color-mix$f, `device-cmyk$f, `相対~色~関数$ ]の結果【を成す `color^t 】の直列化を追加する。 ◎ This section extends CSS Color 4 § 15. Serializing <color> Values to add serialization of the results of the color-mix(), device-cmyk(), and relative color functions.
この節に利用される... 【以下、 § ~color_t 値の直列化-法に記された規約と同じなので和訳は省略する。】 ◎ In this section, the strings used in the specification and the corresponding characters are as follows. String Character " " U+0020 SPACE "," U+002C COMMA "-" U+002D HYPHEN-MINUS "." U+002E FULL STOP "/" U+002F SOLIDUS ◎ The string "." shall be used as a decimal separator, regardless of locale, and there shall be no thousands separator.
結果を成す~alphaは、 正確に 1 になる場合は,通例通り直列化から省略される — それは、暗黙的な既定の値 1 (全部的に不透明)を表す。 ◎ As usual, if the alpha of the result is exactly 1, it is omitted from the serialization; an implicit value of 1 (fully opaque) is the default.
11.1. `color-mix^f の直列化-法
`color-mix$f 関数の`宣言d値$の直列化は、 次の結果になる ⇒ 次を順に`連結する$ ⇒# `color-mix(in ^l, 指定された `color-space$t を小文字~化した結果, `, ^l, 指定された 1 個目の色, ` ^l, 指定された 1 個目の百分率, `, ^l, 指定された 2 個目の色, ` ^l 【この訳による補完】, 指定された 2 個目の百分率, `)^l ◎終 ただし ⇒ 百分率は正規化されない。 指定された 2 個の百分率を加算した結果が 100% になる場合, 2 個目の百分率は直列化から省略され†、 両~百分率に 50% が指定された場合には, 1 個目の百分率も直列化から省略される†。 ◎ The serialization of the declared value of a color-mix() function is\ the string "color-mix(in ",\ followed by the specified <color-space> in all-lowercase,\ followed by ", ",\ followed by the first specified color,\ followed by a space,\ followed by the specified (un-normalized) first percentage (unless both percentages are 50%),\ followed by ", ",\ followed by the second specified color,\ followed by the specified (un-normalized) second percentage (unless the two specified percentages add to 100%),\ followed by ")".
【† 百分率の直前に伴われる~spaceも含めて。 】【 どちらの百分率も,指定d値においては省略され得るが、 直列化の目的においては,[ `§ 百分率の正規化@#color-mix-percent-norm$において %拡縮率 を乗算する前 ]における[ %p1, %p2 ]が “指定された” ものと見做される。 】
最短な直列化の原則に従って、 2 個目の百分率は — 明示的に指定されたとしても — 概して,省略される。 ◎ Following the principle of shortest serialization, the second percentage is typically omitted, even if explicitly specified.
宣言d値の例と,それらを直列化した結果の文字列: ◎ For example,\
- `color-mix(in oklab, teal, peru 40%)^v ◎ the serialized declared value of • color-mix(in oklab, teal, peru 40%)
- `color-mix(in oklab, teal 60%, peru)^l ◎ would be the string "color-mix(in oklab, teal 60%, peru)".
- `color-mix(in oklab, teal 50%, peru 50%)^v ◎ The serialized declared value of • color-mix(in oklab, teal 50%, peru 50%)
- `color-mix(in oklab, teal, peru)^l ◎ would be the string "color-mix(in oklab, teal, peru)".
- `color-mix(in oklab, teal 70%, peru 70%)^v ◎ The serialized declared value of • color-mix(in oklab, teal 70%, peru 70%)
- `color-mix(in oklab, teal 70%, peru 70%)^l ◎ would be the string "color-mix(in oklab, teal 70%, peru 70%)"\
- この例の指定された百分率は,どちらも 50% に正規化されるが、 その事実が発見されるのは,百分率を正規化した後なので。 ◎ because the fact that these normalize to 50% each is only discovered after percentage normalization.
`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.
`87.416% 76.036% 47.637%^rgb `color-mix(in lch, peru 40%, palegoldenrod)^v により色を混合した結果を直列化した結果は、 次の文字列になる ⇒ `lch(79.7256 40.448 84.771)^l ◎ The result of this color mixture • color-mix(in lch, peru 40%, palegoldenrod) ◎ is serialized as the string "lch(79.7256 40.448 84.771)"\
一方で, `88.16% 75.45% 49.88%^rgb `color-mix(in srgb, peru 40%, palegoldenrod)^v の結果を直列化した結果は、 次の文字列になる ⇒ `color(srgb 0.8816 0.7545 0.4988)^l ◎ while the result of • color-mix(in srgb, peru 40%, palegoldenrod) ◎ is serialized as the string "color(srgb 0.8816 0.7545 0.4988)".
11.2. 相対~色~関数の直列化-法
`相対~色~関数$の`宣言d値$の直列化は、 次の結果になる ⇒ 次を順に`連結する$ ⇒# 当の色~関数を識別する文字列(すべて小文字), `(from ^l, `起点~色$の`宣言d値$を直列化した結果, 1 個の~space, 当の色~関数の引数たちを~spaceで`連結する$, `)^l ◎ The serialization of the declared value of a relative color function is a string identifying the color function in all-lowercase, followed by "(from ", followed by the serialization of the declared value of the origin color, followed by a single space, followed by a singly-space-separated list of the arguments to the color function, followed by ")".
例えば,宣言d値
OkLcH(from peru l c h)
を直列化した結果は ⇒ `oklch(from peru l c h)^l
◎ For example, the result of serializing the declared value • OkLcH(from peru l c h) is the string "oklch(from peru l c h)"`相対~色~関数$の結果【算出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.
`3.12% 50.352% 68.894%^rgb `lch(from peru calc(l * 0.8) calc(c * 0.7) calc(h + 180))^v を直列化した結果は、 次の文字列になる ⇒ `lch(49.80224 37.80819 243.6803)^l ◎ The result of serializing • lch(from peru calc(l * 0.8) calc(c * 0.7) calc(h + 180)) ◎ is the string "lch(49.80224 37.80819 243.6803)"
11.3. ~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'); }
`94.903% 45.248% 59.104%^rgb `color(--swop5c 0% 70.0% 20.00% .0%)^v を直列化した結果は ⇒ `color(--swop5c 0 0.7 0.2 0)^l
◎ The serialized value of the color in @color-profile --swop5c {src: url('https://example.org/SWOP2006_Coated5v2.icc'); } .header { background-color: color(--swop5c 0% 70.0% 20.00% .0%); } is the string "color(--swop5c 0 0.7 0.2 0)"11.4. `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.
`70.7% 26.9% 19.7%^rgb `device-cmyk(0 81% 81% 30%)^v を直列化した結果は ⇒ `device-cmyk(0 0.81 0.81 0.3)^l ◎ The serialized value of the color • device-cmyk(0 81% 81% 30%) is the string "device-cmyk(0 0.81 0.81 0.3)"
`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. ~API
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.
12. 既定の~style規則
次の~stylesheetは、 参考であり,規範的ではない。 実装は、 この~stylesheetを各種~HTML族~文書にて既定の~style付けの一部として利用できる。 ◎ The following stylesheet is informative, not normative. This style sheet could be used by an implementation as part of its default styling of HTML Family documents.
/* ~hyperlink用には、伝統的な~desktop~UA用の色 ◎ traditional desktop user agent colors for hyperlinks */ :link { color: LinkText; } :visited { color: VisitedText; } :active { color: ActiveText; } /* `device-cmyk^v 用の適度かつ保守的な既定 ◎ a reasonable, conservative default for device-cmyk */ @color-profile device-cmyk { src: url('https://drafts.csswg.org/css-color-4/ICCprofiles/Coated_Fogra39L_VIGC_300.icc'); }
~securityの考慮点
この仕様は、[ ~ICC~profileを必要時に限り~downloadする特能 ]を~CSSに追加する。 これは、実行-可能な~codeは包含しないので,~security~riskを増やすものにはならない。 ◎ This specification adds to CSS the on-demand downloading of ICC profiles. These do not contain executable code, and thus do not constitute an increased security risk.
~privacyの考慮点
この仕様に対し報告された,新たな~privacyの考慮点は、無い。 ◎ No new privacy considerations have been reported on this specification.
~accessibilityの考慮点
この仕様は、 ~textの背景に動的な色が指定された場合【!user-specified】でも,必要十分な~contrastを確保するための仕方 【 `contrast-color$f 】 を追加する。 ◎ This specification adds a way to ensure adequate contrast for text whose background is a user-specified color, including dynamic colors.
変更点
- `2024年 2月 29日 作業草案@~TR/2024/WD-css-color-5-20240229/$ からの変更点 ◎ 17.1. Since the Working Draft of 29 February 2024
- FOGRA39, FOGRA51, FOGRA55 への参照を追加した。 ◎ Added references to FOGRA39, 51 and 55
- 【 `color-mix^f の計算において】 矩形な色~空間に対しては `hue-interpolation-method$t が~errorになることについての言及を除去した — それは、 文法により~~元から許容されないので。 ◎ Removed mention of <hue-interpolation-method> being an error condition for rectangular color spaces, as the grammar does not allow it
- `相対~色$用の各`~channel~keyword$が どの色~空間に関係するかを明確化した。 ◎ Clarified which color space the relative color channel keywords relate to
- `相対~色$を成す概念的な側面を構文上の詳細から分離した。 ◎ Separated out the conceptual aspects of relative colors from the syntactic details
- ~DeltaE表t内の~text用に必要十分な~contrastを確保するようにした。 ◎ Ensured adequate contrast for text in the deltaE table
- `相対~色$を成す色~成分は切詰められない一方で,~alpha成分は切詰められることを明確化した。 ◎ Clarified that relative color components are not clamped, while relative alpha is
- `2022年 6月 28日 作業草案@~TR/2022/WD-css-color-5-20220628/$ からの変更点 ◎ 17.2. Since the Working Draft of 28 June 2022
- 色~関数の【!CSSOM】直列化を指定d値ではなく宣言d値で述べるようにした。 ◎ Described CSSOM serialization in terms of declared values, rather than specified values
- `contrast-color$f 関数を追加した。 ◎ Added the contrast-color() function
- `color-mix$f 用の補間を`~level 4$ の節へ明示的に~linkした。 ◎ Explicitly linked to the CSS color 4 section on interpolation, for color-mix()
- ~HSLへの色域~対応付けに関する不要になった言及を除去した。 ◎ Removed a leftover mention of gamut mapping to HSL
- `絶対的な色$を注釈文にて定義した — 文法を成す一部としてではなく。 ◎ Defined absolute colors in prose, rather than as part of the grammar
- `相対~色$における百分率から実数への変換~用の基準~範囲を事例ごとに明示的に与えた。 ◎ Explicitly repeated the reference ranges for percent to number conversion in RCS for each case
-
`相対~色$の直列化において:
- その`起点~色$が `currentcolor$v をとる場合に,もっと良く定義した。
- [ `srgb$v / `srgb-linear$v / `hsl$v / `hwb$v 【!~sRGB / `hsl$f / `hwb$f】 ]を利用するものは、 往復-可能になるよう `color(srgb …)^v を利用して直列化することにした。
- `light-dark$f 関数を言及するよう,要約aを更新した。 ◎ Updated abstract to mention the light-dark() function
- 矩形な色~空間を成す~listを`~level 4$ からもっと~portした。 ◎ Ported forward the larger list of rectangular color spaces from CSS Color 4
- `custom-params$t 用の文法を正した (~commaで分離されるのではなく,空白で分離されるよう)。 ◎ Correction to the grammar for custom params (whitespace separated, not comma separated)
- `device-cmyk$f の文法において ⇒# `none$v が欠落ったのを正した。 `CSS GCPM^cite による以前の(旧来の)構文を正した。 ◎ Corrections to the grammar of device-cmyk() which was missing none, and the previous (legacy) syntax from CSS GCPM
- `color$t 型の文法において `color-mix$f が欠落ったのを正した。 ◎ color-mix() was missing from the grammar of the color type
- `相対~色~構文$の宣言d値【!指定d値】の直列化を明確化した。 ◎ Clarified serialization of specified RCS values
- `light-dark$f 関数を追加した。 ◎ Added the light-dark() function
- `color-mix$f の百分率を正規化する~algoを,際どい事例 50% を明示的に含めるよう正した。 ◎ Corrected color-mix percent normalization algorithm to include explicit 50% edge case
- ~HSLの例を更新した — それは、 ~sRGBから~HSLへ変換する前に,依然として`色域~対応付け@~CSSCOLOR#gamut-mapping$を利用していた。 ◎ Updated HSL example which still used gamut mapping before sRGB to HSL conversion step
- 一部の例における構文~強調-法を修正した。 ◎ Fixed syntax highlighting in some examples
- `相対~色~構文$の`起点~色$は、 省略可能な~alphaを含み得ることを明確化した。 ◎ Clarified that RCS origin colors can include optional alpha
- `無力$な成分の誤り含みな利用を修正した。 ◎ Fixed erroneous use of powerless components
- `percentage$t から `number$t への変換~用には、 基準~範囲を利用するようにした。 ◎ Used reference ranges for percent to number conversions
- ~CSS~WGによる解決に従って、[ `hsl$f, `hwb$f ]の~channel値を `number$t にした。 また、 すべての色相~角度~channel値を[ 度数による `number$t ]にした。 このことは,すでに`相対~色~構文$の序論で~~述べていたが、 その変更は,全部的に伝播されていなかった。 ◎ Made hsl() and hwb() channel values number, per CSSWG resolution. Also made all the hue angle channel values number, in degrees. The RCS intro already said this but the change had not been fully propagated.
- ~CIE~XYZ~D65色~空間における`相対~色~構文$の例を追加した。 ◎ Added an RCS example in CIE XYZ D65 colorspace
- `~level 4$ から変化してない節の複製を除去した — 不要であり,読者を惑わすので。 ◎ Removed un-needed and unchanged copy of a section of CSS Color 4 which was confusing to read
- 節~titleを "`Specifying Predefined and Custom Color Spaces: the color() Function^en" 【 `§ [定義済み色~空間/~custom色~空間]内の色の指定-法@#color-function$】 に正した。 ◎ Corrected section title to "Specifying Predefined and Custom Color Spaces: the color() Function"
- ~HWBは `number$t も許容するものと定義した — それまでは、 `percentage$t に限られていた。 ◎ Defined that HWB now allows number, previously it was percentage only
- `相対~色~構文$の成分を通例的でない位置に利用している場合に, “魔法の拡縮-法” は無いことを明確化した。 それが求まれる場合、 `calc$f を利用すること。 例を追加した。 ◎ Clarified that, if using RCS components in unusual positions, there is no "magic scaling"; use calc() if you want that. Added example.
- [ ~CIE明度, ~Oklab明度 ]どちらが利用されているかを明確化した。 ◎ Clarified which of CIE Lightness and Oklab lightness are being used
- `color-mix$f 関数の結果が, 【混合される色として】 `currentcolor$v が利用された場合にどう直列化されるかを明確化した。 その例を追加した。 ◎ Clarified serialization of the result of a color-mix() function if currentColor is used. Added an example of this.
- `color-mix$f 用の一部の例における誤記を修正した。 ◎ Fixed typo’s in some color-mix examples
- `無力$な成分に `none$v の代わりに 0 を利用していた例を修正した。 ◎ Fixed an example which used 0 instead of none for powerless components
- `color-mix$f の宣言d値【!指定d値】の直列化を定義した。 それは、 指定された百分率を正規化することなく直列化することを明確化した。 ◎ Defined serialization of specified value of color-mix and clarified that it serializes with specified, not normalized, percentages
- `~level 4$ から変更されてない `alpha-value$t の定義を除去して、 代わりに `~level 4$ へ~linkした。 ◎ Removed the unchanged alpha-value definition, link to Color 4 instead
- [ `rgb$f, `rgba$f, `hsl$f, `hsla$f ]の文法には[ `現代の色~構文$, `旧来の色~構文$ ]用に別々な生成規則を利用するようにした。 ◎ Used separate grammar productions for modern and legacy rgb, rgba, hsl, and hsla
- `起点~色$には[ `現代の色~構文$, `旧来の色~構文$ ]どちらも利用できることを明確化した — 前者に制約されずに。 ◎ Clarified that the origin color is unrestricted and can use either modern or legacy syntax
- `color$t 用の新たな生成規則を追加した。 `相対~色~構文$は入子にできることを明確化した。 ◎ Added a new color production, clarified that RCS can be nested
- [ ~RGB/~HSL ]用にも `percentage$t と `number$t が混在してかまわないこと, もはや`相対~色~構文$に制約されない【?】ことを明確化した。 ◎ Clarified that percentage and number can be freely mixed for RGB, HSL; not restricted to RCS any more
- `相対~色~構文$は`現代の色~構文$に限り適用されることを明確化した。 ◎ Clarified that RCS only applies to the modern color syntax
- 要求される色~空間の変換を定義した。 不要な変換は飛ばせることを明確化した。 【`変換-済みな起点~色$】 ◎ Defined required color space conversions, clarified that un-needed conversions can be skipped
- [ 正しい~gradient, 不正な~gradient ]を描画している画像を追加した。 ◎ Added correct and incorrect gradient rendering images
- `~custom色~空間$において 【 `components$d により?】命名されない成分があっても, 妥当であることを明確化した。 ◎ Clarified that un-named components in custom color spaces are still valid
- 一部の例を もっと明瞭になるよう改善した。 ◎ Improved some examples to make them clearer
- 欠落~成分を伴う`相対~色~構文$を定義した。 ◎ Defined RCS with missing components
- `color-interpolation-method$t に `dashed-ident$t を追加して、 `~custom色~空間$においても補間できるようにした。 ◎ Added dashed-ident to color-interpolation method, can now interpolate in custom color spaces
- `相対~色~構文$における色相~成分は、 度数による `number$t に解決されることを明確化した。 ◎ Clarified that hue components in RCS resolve to a number, in degrees
- `起点~色$が `currentcolor$v にされた`相対~色~構文$を解決した結果を指定した。 ◎ Specified the resolved RCS where the origin color is currentColor
- `~channel~keyword$【が返す値】は、 単独の型【すなわち `number$t 】に限られるようにした。 ◎ Channel keywords can only have a single type
- [ `旧来の色~構文$を伴う妥当でない`相対~色~構文$ ]の例を[ 実際に旧来の色~構文を利用する ]よう正した。 ◎ Corrected invalid example of RCS on legacy syntax, to actually use the legacy syntax
- 各~例において,一貫した直列化を利用するようにした。 ◎ Used consistent serialization in examples
- `device-cmyk$f 用にも直列化が定義されることを注記した【!exists】。 ◎ Noted that a defined serialization for device-cmyk() exists
- `CSSColorProfileRule$I ~interfaceを追加した。 ◎ Added the CSSColorProfileRule interface
- [ ~Oklab/~OKLCh ]の文字大小0が一貫するようにした。 ◎ Consistent capitalization of Oklab and OKLCh
- 色見本~用の~accessibilityを改善した。 ◎ Accessibility improvements for color swatches
- 図式~用の~accessibilityを改善した。 ◎ Accessibility improvements for diagrams
- 一部の色見本における求まれない~clippingを修正した。 ◎ Fixed unwanted clipping of some color swatches
- 一部の `figure^e 用の代替~textを改善した。 ◎ Improved alternative text for some figures
- 一部の欠落った色見本を追加した。 ◎ Added some missing color swatches
- 【!MacBeth】~DeltaE格子を成す表tの[ 行, 列 ]に~labelを追加した。 ◎ Added row and column labels for MacBeth images and table of deltaE
- 色相~回転-図式~内に【色を表す】~labelを与えた。 ◎ Better labelling on hue-rotate diagram
- 図式~上の色の記述をもっと良くした。 図式の~accessibilityを改善した。 ◎ Better descriptions of colors on diagrams, improve Accessibility
- すべての[ 図式/ `figure^e ]に[ ~ID, 自己-~link ]を付与した。 ◎ Ensured all diagrams and figures have IDs, selflinks
- `2022年 4月 28日 作業草案@~TR/2022/WD-css-color-5-20220428/$ からの変更点 ◎ 17.3. Since the Working Draft of 28 April 2022
- `rgb^f の定義における誤記を修正した ◎ Fixed a typo in definition of rgb()
- 編集上の改善 (文字大小0, 綴り, 明確さ) ◎ Editorial improvements (capitalization, spelling, clarity)
- 他の仕様による利用-用に定義を~exportした。 ◎ Exported definitions for other specifications to use
- `color$f の文法~内の~alphaに欠落った `none$v を追加した。 ◎ Add missing none to alpha in grammar of color()
- `color-contrast^f 関数を~level 6 へ移動した。 【以下に現れる `color-contrast^f (または~contrast)に関する変更点も,今や この~level 5 には関わらない。】 ◎ Moved the color-contrast() function to level 6
- `2021年 12月 15日 作業草案@~TR/2021/WD-css-color-5-20211215/$ からの変更点 ◎ 17.4. Since the Working Draft of 15 December 2021
- `color$f 内の[ 多過ぎる/少な過ぎる ]~parameterに対する寛容さを`~custom色~空間$に制約した。 ◎ Forgiveness of too many/too few parameters in color() restricted to custom color spaces
- `相対~色~構文$を,どこでも[ 実数, 百分率 ]を許容するよう変更した。 ◎ Changed RCS to allow number or percent everywhere
- 成分の名前が `pi$v などの有名~定数と衝突する可能性について明瞭に述べた。 ◎ Clearly described potential clash of component names with named constants such as PI
- `相対~色~構文$は`旧来の色~構文$(~commaで分離される)を利用しないことを明確化した。 ◎ Clarified that Relative Color Syntax does not use legacy (comma-separated) syntax
- `rgb$f 関数の文法を正した — それは、 ~alpha用の~optionとして `none$v を挙げていなかった。 ◎ Corrected grammar of the rgb() function, none' was not listed as an option for alpha
- [ `hsl^v / `hwb^v ]を利用している `color-mix$f の直列化を,精度を最大~化するよう変更した。 ◎ Changed serialization of color-mix() which uses hsl or hwb, to maximize precision
- `color-mix$f の例として, 【混合した結果が】色域~外になる場合を追加した。 ◎ Added an out of gamut color-mix example
- 拡張された色域~外にある色を表現し得ない[ ~HSL/~HWB ]~modelを述べるため、 用語 “色を表出し得ない” を利用するようにした。 【が、定義された用語ではない(一般な句として現れる)。】 ◎ Use the term "cannot express the color" to describe HSL and HWB models which cannot represent extended, out of gamut colors.
- 綴りの誤りを修正した。 ◎ Fixed some spelling errors
- `2021 年 6 月 1日 作業草案@~TR/2021/WD-css-color-5-20210601/$ からの変更点 ◎ 17.5. Since the Working Draft of 1 June 2021
- 矩形な空間において `hue-interpolation-method$t を利用するのは、 ~errorとした。 ◎ Using <hue-interpolation-method> in rectangular spaces is an error
- 旧 `hue-adjuster^t を新たな `hue-interpolation-method$t に変更した。 ◎ Changed old <hue-adjuster> to new <hue-interpolation-method>
- ~CSS~WGによる解決に則り, `color-profile^at, `device-cmyk^f を~level 5 へ移動した。 ◎ Moved @color-profile and device-cmyk to level 5 per CSSWG resolution
- 成分の名前として `none^v を除外した。 ◎ Excluded none as a component name
- ~OKLCh相対~色~構文の例を追加した。 ◎ Added OKLCh relative color syntax example
- 補間~色~空間を定義した。 ◎ Defined interpolation color space
- 色~profileの読込ngを~fetchの用語で定義した。 ◎ Defined loading color profiles in terms of fetch
- ~contrastは~D65に順応された~CIE~XYZに相対的に計算されることを明確化した。 ◎ Clarified that contrast is calculated relative to D65-adapted CIE XYZ
- `color-mix$f の直列化に[ `oklab$f, `oklch$f ]を追加した。 ◎ Added oklab() and oklch() to serialization of color-mix()
- `相対~色~構文$に[ `oklab$f, `oklch$f ]を追加した。 ◎ Added oklab() and oklch() relative color syntax
- `lch^v で混合したとき, `oklch^v で混合したときを~~対比する例を追加した。 ◎ Added lch vs. oklch mixing example
- 混合-法には[ `oklab^v / `oklch^v ]が選好されるようにした。 ◎ Prefer oklab and oklch for mixing
- `~level 4$ に従って, `xyz$v は~D65に相対的とするよう変更した。 ◎ Changed xyz to D65-reative, following CSS Color 4
- 色~空間として[ `oklab^v, `oklch^v ]を追加した。 ◎ Added oklab and oklch color spaces
- `color-contrast^f の解決-法を定義した。 ◎ Defined how to resolve color-contrast())
- 直列化された形における最小な精度を明確化した。 ◎ Clarified minimum precision of serialized forms
- 【~LCHは】~CIE~LCHが意味されることを明確化した。 ◎ Clarified that CIE LCH is meant
- いくつか例を追加した。 ◎ Added some more examples
- `color-adjust^f を除去した(`相対~色~構文$の方を残した)。 【以下に現れる “調整子( `adjuster^en )”, `*-adjuster^t も,今や除去された。】 ◎ Removed color-adjust(), keeping relative color syntax
- [ `color-mix$f, `color-contrast^f, `相対~色~構文$ ]の結果の直列化を定義した。 ◎ Defined serialization of the results of the color-mix, color-contrast, and relative color syntaxes
- `2020年 6 月 10日 最初の公な作業草案@~TR/2020/WD-css-color-5-20200303/$ からの変更点 ◎ 17.6. Since the FPWD of 10 June 2020
- `color$f 関数~用の相対~色~構文を追加した。 ◎ Added relative color syntax for the color() function
- `color-adjuster^t は省略可能でないことを明確化した。 ◎ Clarified that the color-adjuster is not optional
- `color-mix$f における百分率は義務的であることを明確化した。 ◎ Clarified that the percentage in color-mix is mandatory
- `hue-adjuster^t を元在った `color-mix$f に戻した【!whee】。 ◎ Moved hue-adjuster back to color-mix whee it belongs
- 異なる色~空間どうしで混合する例を追加した。 ◎ Added example with different mixing color spaces
- `color-mix$f における百分率の正規化に関する例を追加した。 ◎ Added examples of percentage normalization in color-mix()
- `color-mix$f における負な百分率は明示的に除外した。 ◎ Explicitly excluded negative percentages in color-mix()
- `color-mix$f における百分率の総和が 100% 未満になるときは、 1【!100%】 未満の~alpha透明度を生産するようにした。 ◎ Percentages in color-mix() summing to less than 100% produce an alpha transparency less than 100%
- 用語 `color space^en (色~空間)を一貫して利用するようにした — `colorspace^en ではなく。 ◎ Consistently used the term color space rather than colorspace,\
- `color-space$t ~tokenを定義した。 ◎ defined <color-space> token
- `color-contrast^f の文法を正した。 ◎ Corrected color-contrast grammar
- `color-contrast^f に省略可能な~target~contrast比を追加した。 ◎ Added an optional target contrast ratio to color-contrast()
- 調整子の文法を正した。 ◎ Corrected adjuster grammar
- 百分率の総和が 0 になる病んだ事例を取扱う必要があることを注記した。 ◎ Noted that the corner case of percentages summing to zero needs to be handled
- `color-mix$f における演算の順序を明確化した。 ◎ Clarified order of operations in color-mix()
- 各~例を現在の文法に合致するよう更新した。 ◎ Updated examples to match current grammar
- 百分率がどう正規化されるかを定義した。 ◎ Defined how percentages are normalized
- `color-mix$f における[ 0% / 100% ]の意味を明確化した。 ◎ Clarify meaning of 0% and 100% in color-mix()
- 調整子の定義を `color-mix$f から `color-adjust^f へ移動した。 ◎ Definition of adjusters moved from color-mix() to color-adjust()
- `color-mix$f に与える引数には任意の順序を許容した。 ◎ Allow arguments to color-mix() to be in any order
- `color-mix$f 用の色~空間は義務的とした。 ◎ Mandatory color space for color-mix()
- `color-mix$f における百分率は、 色より前に来ることを許容した。 ◎ Allowed the percentage in color-mix() to come before the color
- `color-mix$f 用の明示的な~algoを追加した。 ◎ Added explicit algorithm for color-mix()
- `color-mix$f から調整子を除去して,文法を単純~化した。 ◎ Removed adjusters from color-mix() and simplified the grammar
- 混合するために利用される色~空間を指定するための `in^v ~keywordを追加した。 ◎ Added the "in" keyword to specify the color space used for mixing
- `color-contrast^f ~listには 2 個以上の~itemが要求されるようにした。 ◎ Required color-contrast() list to have at least two items
- 相対-色~構文の説明を改善した。 ◎ Improved explanation of the relative color syntax
- `~level 4$ による,色の直列化の定義へ~linkした。 ◎ Link to CSS 4 definition of color serialization
- 色~空間~用に別々な節を追加した。 ◎ Added separate section for color spaces
- `color-adjust^f の例を更新した。 ◎ Updated color-adjust example
- 説明用の図式を追加した。 ◎ Added explanatory diagrams
- 未解決な百分率への~~対処。【?】 ◎ Deal with unresolved percentages
- `color-mix$f 用の引数を正規化するようにした。 ◎ Normalize arguments to color-mix
- 調整子に百分率を許容した。 ◎ Allow percentages for adjusters
- ~linkを修正した。 ◎ Link fixes
- `color-mix$f の文法を更新した — 調整子を許容するようにして,~alpha調整子を追加した。 ◎ Updated color-mix grammar, allowing adjusters, add alpha adjuster
- いくつかの例を正した。 ◎ Corrections to some examples
- `§ ~securityの考慮点@#security$, `§ ~privacyの考慮点@#privacy$ を更新した。 ◎ Updated Security and Privacy section
- `color-contrast^f に `vs^v ~keywordを追加した。 ◎ added vs keyword to color-contrast
- 文法に `xyz^v 用の調整子( `xyz-adjuster^t )を追加した。 ◎ added xyz adjuster to grammar
- 色相~調整子( `hue-adjuster^t )用の各種~keywordを追加した。 ◎ added hue adjuster keywords
- `color-mix$f 用に,~XYZ色~空間として `xyz^v を追加した。 ◎ add XYZ color space for mixing
- 色~調整子( `color-adjuster^t )と色~空間を定義した。 ◎ defined color-adjuster and color space
- `color-mix$f 用に,省略-時の既定( `50%^v )を許容した。 ◎ allowed mix percent to default to 50%
- 作業した例と図式を追加した。 ◎ added worked examples and diagrams
- [ 綴り/構文/整形 ]に関する小さな課題を正した。 ◎ corrected minor spelling, syntax and formatting issues
- `color-contrast^f 値の解決-法を与える節を追加した。 ◎ Added section on resolving color-contrast() values
- `~level 4$ からの変更点 ◎ 17.7. Changes from CSS Color 4
-
主要な変更は、 ~CSS色は,もはや定義済み~RGB空間 — ~sRGBや `display-p3$v など — に制約されなくなったことである。 これを~supportするため,次に挙げる特能が新規に追加された: ◎ One major change, compared to CSS Color 4, is that CSS colors are no longer restricted to predefined RGB spaces such as sRGB or display-p3. ◎ To support this, several brand new features have been added:
- `color$f 関数は、 ~profiled機器に依存する色(較正-済み~CMYKも含む)用に, `color-profile$at ~at-規則により拡張された。 ◎ The color() function is extended by the @color-profile at-rule, for profiled device-dependent color, including calibrated CMYK.
- `device-cmyk$f 関数は、 出力~機器に特有な~CMYK色~空間~内の未較正な色を指定する。 ◎ device-cmyk() function, for specifying uncalibrated colors in an output-device-specific CMYK color space.
- 新たな `color-mix$f 関数は、 2 個の色を指定された色~空間~内で混合して,新たな色を得ることを許容する。 ◎ In addition the new color-mix() function allows two colors to be mixed, in a specified color space, to yield a new color.