CSS Color Module Level 4 （日本語訳）

◎要約

この仕様は、［前景~色／~group不透明度］用の各種~CSS［ `color$t 値, ~prop ］を述べる。また、色がどう補間されるか, および異なる色域へ対応付ける方法も述べる。 ◎ This specification describes CSS <color> values, and properties for foreground color and group opacity. It also describes how colors are interpolated, and how to gamut map colors.

~CSSisaLANG

1. 序論

◎非規範的

この~moduleは、［要素の~text内容の前景~色と不透明度を指定する］ことを作者に許容する各種~CSS~propを述べる。また、 ~CSS `color$t 値~型も詳細に述べる。 ◎ This module describes CSS properties which allow authors to specify the foreground color and opacity of the text content of an element. This module also describes in detail the CSS <color> value type.

この~moduleは、 `CSS1＠~TR/CSS1$cite, `CSS2＠~TR/CSS2/$cite, `CSS Color 3＠~TR/css-color-3/$cite にすでに存在する，色に関係する各種［ ~prop, 値］を定義するのみならず，新たな各種［ ~prop, 値］も定義する。 ◎ It not only defines the color-related properties and values that already exist in CSS1, CSS2, and CSS Color 3, but also defines new properties and values.

特に、［ ~sRGB以外の`色~空間$内の色を指定する］ことを許容する。これまでは、 ~sRGB色域の外側にある高~彩度な色は — 表示~機器が~supportしていようが — ~CSSにおいては利用できなかった。 ◎ In particular, it allows specifying colors in other color spaces than sRGB; previously, the more saturated colors outside the sRGB gamut could not be used in CSS even if the display device supported them.

`実装~報告（草案）＠https://drafts.csswg.org/css-color-4/test-coverage$ も可用である。 ◎ A draft implementation report is available.

1.1. 値~定義

【この節の内容は `~CSS日本語訳共通~page＠~CSScommon#values$に移譲。】

2. 色の各種用語

`色@ （ `color^en ）は、［光／光で照らされた物体］の［ヒトの視覚的な知覚］に基づく（数量-や~textによる）定義である。客観的なヒトの色~知覚の研究は、色計量y （ colorimetry ）と呼ばれる。 ◎ A color is a definition (numeric or textual) of the human visual perception of a light or a physical object illuminated with light. The objective study of human color perception is termed colorimetry.

物体の色は、［それは、可視な各~波長において，何割の光を反射するか］および［それを照らしている光の実際の色（これも，各~波長における光の量）］に依存する。それは、 `分光光度計^em（ `spectrophotometer^en ）により測定される。 ◎ The color of a physical object depends on how much light it reflects at each visible wavelength, plus the actual color of the light illuminating it (again, the amount of light at each wavelength). It is measured by a spectrophotometer .

光を発する何か（~computer~screenも含む）の色は、［可視な各~波長において，それが発する光の量］に依存する。それは、 `分光放射計^em（ `spectroradiometer^en ）により測定される。 ◎ The color of something that emits light (including colors on a computer screen) depends on how much light it emits at each visible wavelength. It is measured by a spectroradiometer.

2 つの物体は、［波長分布（ spectra ）が異っていても，物理的に同じ感覚を生産する］ならば，同じ色であるとされる。 2 つの色が同じかどうかは、波長分布を~CIE~XYZ（ 3 個の実数）へ変換することにより計算できる。 ◎ If two objects have different spectra, but still produce the same physical sensation, we say they have the same color. We can calculate whether two colors are the same by converting the spectra to CIE XYZ (three numbers).

例えば，［緑色な葉, ~computer~screenに表示された当の葉の写真, 印刷されたそれ］は、それぞれに異なる手段で緑色~感覚を生産している。当の［ ~screen, 印刷機］どちらも`較正-済み$ならば、［葉, 写真, 印刷されたそれ］における緑色は，同じ見かけになる。 ◎ For example a green leaf, a photograph of that leaf displayed on a computer screen, and a print of that photograph, are all producing a green sensation by different means. If the screen and the printer are calibrated, the green in the leaf, and the photo, and the print will look the same.

`色~空間@ （ `color space^en ／ `colorspace^en ）は、［下層の色計量~modelに関して，どの色にも明瞭かつ客観的に測定-可能な意味が備わる］よう組織化された色たちからなる。これはまた，［複数の色~空間において同じ色を表出できること／同じ見かけを~~保ったまま別の色~空間へ変形できること］を意味する。 ◎ A color space is an organization of colors with respect to an underlying colorimetric model, such that there is a clear, objectively-measurable meaning for any color in that color space. This also means that the same color can be expressed in multiple color spaces, or transformed from one color space to another, while still looking the same.

分光光度計で測定された葉の色が `41.587% 50.3670% 36.664%^rgb `lch(51.2345% 21.2 130)^v を有するものと見出されたなら、それは， `lab(51.2345% -13.6271 16.2401)^v に等しい。 ◎ A leaf is measured with a spectrophotometer and found to have the color lch(51.2345% 21.2 130) which is lab(51.2345% -13.6271 16.2401).

同じ色は、様々な色~空間でも表出できる： ◎ This same color could be expressed in various color spaces:

color(sRGB 0.41587 0.503670 0.36664);
color(display-p3 0.43313 0.50108 0.37950);
color(a98-rgb 0.44091 0.49971 0.37408);
color(prophoto-rgb 0.36589 0.41717 0.31333);
color(rec2020 0.6295 0.9657 0.3633);

`加法的な色~空間@ とは、座標系が光~強度に線形であることを意味する。 ~CIE ~XYZ色~空間は、加法的な色~空間である。 ~XYZの Y 成分が `輝度@ （ `luminance^en ） — 単位~面積あたりの強度，平たく言えば “明るさ” — を与える。輝度は、 ~nit（ `nit^en ）とも称され， 1 平方~meterあたりの~candela数【光度】（ cd/m² ）で測定される。 ◎ An additive color space means that the coordinate system is linear in light intensity. The CIE XYZ color space is an additive color space. The Y component of XYZ is the luminance, the light intensity per unit area, or 'how bright it is'. Luminance is measured in candelas per square meter. cd/m², also called nits.

加法的な色~空間における計算は、色を混合した結果を`正確aに予測する^emように行える。ほとんどの~RGB空間は、各~成分が`~gamma符号化される^emので，加法的でない。この~gamma符号化を外すと，光に線形（ `linear-light^en ）~FN な値を生産する。 ◎ In an additive color space, calculations can be done to accurately predict color mixing. Most RGB spaces are not additive, because the components are gamma encoded. Undoing this gamma encoding produces linear-light values.

【~FN “光~強度（ `light intensity^en ）に線形（ `linear^en ）” の略記と見受けられる。】

例えば，同じ有色~光を~~発する 2 個の電灯があって，片方だけ点灯したとき測定された色が `47.74% 35.59% 21.53%^rgb `color(xyz 0.13 0.12 0.04)^v になるならば、両方とも点灯したときの色は，正確にその 2 倍 `65.57% 49.35% 30.58%^rgb `color(xyz 0.26 0.24 0.08)^v になる。 ◎ For example, if a light fixture contains two identical colored lights, and only one is switched on, and the color is measured to be color(xyz 0.13 0.12 0.04), then the color when both are switched on will be exactly twice that, color(xyz 0.26 0.24 0.08).

舞台を~~照らす 2 つの~spotlightがあって，それらに測定された値が `0% 60.02% 47.86%^rgb `color(xyz 0.15 0.24 0.17)^v, `50.45% 9.53% 31.04%^rgb `color(xyz 0.11 0.06 0.06)^v になるならば、それらの有色な光線が重合するように~~照らされたときの混合を成す色は，正確aに予測できる — 結果は、 ~XYZの各~成分~値ごとの総和 `75.5% 51.71% 56.61%^rgb `color(xyz 0.26 0.30 0.23)^v になる。 ◎ If we have two differently colored spotlights shining on a stage, and one has the measured value color(xyz 0.15 0.24 0.17) while the other is color(xyz 0.11 0.06 0.06) then we can accurately predict that if the colored beams are made to overlap, the color of the mixture will be the sum of the XYZ component values, or color(xyz 0.26 0.30 0.23).

`純色度@ （ chromaticity ）は、明度~成分に依らない（~~除外した）色~測定である。上の同じ光を~~発する電灯の例で［片方だけ点灯したとき, 両方とも点灯したとき］の `u', v'^em 純色度は、どちらも同じ ( 0.2537, 0.5268 ) になる（後者の方が明るいことを除けば，同じ色になる）。 ◎ A chromaticity is a color measurement where the lightness component has been factored out. From the identical lights example above, the u',v' chromaticity with one light is (0.2537, 0.5268) and the chromaticity is the same with both lights (they are the same color, it is just brighter).

純色度は加法的なので、混合が成す純色度を正確aに予測できる（結果の明度はそうでないが）。純色度は二次元であり、 `純色度~図式^em（色度図）で表現することにより，混合した色の純色度を容易に予測できる。 2 個の色を混合した結果の色は、図式においては，それらを結ぶ線~上に乗ることになる。平面を形成する 3 個の色【を混合した結果の色】は、図式においては，それらが形成する三角形~内に入ることになる。 ◎ Chromaticities are additive, so they accurately predict the chromaticity (but not the resulting lightness) of a mixture. Being two-dimensional, chromaticity is easily represented on a chromaticity diagram to predict the chromaticity of a color mixture. Any two colors can be mixed, and the resulting colors will lie on the line joining them on the diagram. Three colors form a plane, and the resulting colors will lie in the triangle they form on the diagram.

`display-p3$v 色~空間を示している（ベタな色による）純色度~図式と，比較~用の `srgb$v 色~空間のそれ（薄く示される）。白色点（ ~D65 ）も示される。 ◎ A chromaticity diagram showing (in solid colors) the display-p3 color space and for comparison (faded) the sRGB color space. The white point (D65) is also shown.

各種~RGB色~空間は、線形~化されたなら，加法的であり、それらの色域は，原色［ ~red, ~green, ~blue ］の純色度と `白色点@ （ `white point^en ／ `whitepoint^en ）（これら 3 原色~すべてが全部的な強度を伴うとき，形成される色）の純色度により定義される。 ◎ Thus, once linearized, RGB color spaces are additive, and their gamut is defined by the chromaticities of the red, green and blue primaries, plus the chromaticity of the white point (the color formed by all three primaries at full intensity).

ほとんどの色~空間は、少数の［日光を模倣している`白色点$ ］のうち一つを利用する — それらは、対応している黒体放射体の相関d色~温度（ `correlated color temperature^en, 略称 CCT ） `Understanding_CCT$r により命名される。例えば，`~D65$は、相関d色~温度 6500K~FN に対応している［日光の白色点］を表す。（~FN 実際には 6504K — ~Plank定数の値は、色が元々定義された頃から変更されたので。） ◎ Most color spaces use one of a few daylight-simulating white points, which are named by the correlated color temperature (CCT) [Understanding_CCT] of the corresponding black-body radiator. For example, D65 is a daylight whitepoint corresponding to a correlated color temperature of 6500 Kelvin (actually 6504, because the value of Plank’s constant has changed since the color was originally defined).

累積的な丸誤差を避けるため、計算に利用される純色度~値は，すべての箇所で一貫して一致することが重要になる。したがって，この仕様との最大な互換性を得るためとして、次に挙げる 2 種の標準な［日光を模倣している`白色点$ ］が定義される： ◎ To avoid cumulative round-trip errors, it is important that the identical chromaticity values are used consistently, at all places in a calculation. Thus, for maximum compatibility, for this specification, the following two standard daylight-simulating white points are defined:

名前	x	y	相関d色~温度【！CCT】
`~D50@	0.345700	0.358500	5003K
`~D65@	0.312700	0.329000	6504K

［ `色~空間$／色を生産する機器］は、それに対し測定される物理-特性（利用する原色の`純色度$や，所与の入力~群に対する応答として生産される色など）が既知であるとき、 `有特性@ （ `characterized^en ）という。 ◎ When the measured physical characteristics (such as the chromaticities of the primary colors it uses, or the colors produced in response to a given set of inputs) of a color space or a color-producing device are known, it is said to be characterized.

加えて，機器は、較正~対象 — 白色点, ~grayの中立度, 色調~応答の予測-能と一貫性など — に合わせて調整されているならば， `較正-済み@ （ `calibrated^en ）という。 ◎ If in addition adjustments have been made so that a device meets calibration targets such as white point, neutrality of greys, predictability and consistency of tone response, then it is said to be calibrated.

現実の物理-機器は、ヒトの眼が見れるあらゆる色は未だ生産できていない。所与の機器が生産し得る色の範囲を `色域@ （ `gamut^en ）という（ `gamma^en（ ~gamma ）と混同しないように）。色域が制限された機器は、虹に見出される様な極~彩度な色を生産できない。 ◎ Real physical devices cannot yet produce every possible color that the human eye can see. The range of colors that a given device can produce is termed the gamut (not to be confused with gamma). Devices with a limited gamut cannot produce very saturated colors, like those found in a rainbow.

~Oklab内に~plotされた 3 種の色域の俯瞰図 — 大きいものから順に ~Rec2020, ~Display-P3, ~sRGB 。正な a 軸は右端へ, 正な b 軸は上端へ向かう。 L 軸から見下ろしているので、 ~whiteなど中立的な色は中心にある。 `Alexey Ardov^en 氏により描画された。 ◎ A top-down view of three gamuts, plotted in Oklab with the positive a-axis towards the right and the positive b-axis towards the top; looking down the l-axis so white and neutrals are in the center. The largest of the three gamuts is ITU Rec BT.2020; the medium-sized one is Display P3, and the smallest is sRGB. Rendering by Alexey Ardov.

各種 `色~空間$の色域は、表出できる色の体積（立方-~Lab単位【定義は不明】）で比較できる。次の表tに，~CSSにて可用な`定義済み色~空間$の体積を示す： ◎ The gamuts of different color spaces may be compared by looking at the volume (in cubic Lab units) of colors that can be expressed. The following table examines the predefined color spaces available in CSS.

色~空間	体積（百万~立方-~Lab単位）
`srgb$v【！sRGB】	0.820
`display-p3$v	1.233
`a98-rgb$v	1.310
`prophoto-rgb$v	2.896
`rec2020$v	2.042

~CSSにおける色は、［各~構文-形において述べられるとおり， `無効な色@ とされる］か，それ以外の `妥当な色@ になる。 ◎ A color in CSS is either an invalid color, as described below for each syntactic form, or a valid color. ◎ Any color which is not an invalid color is a valid color.

色は、 `妥当な色$であっても，所与の色の範囲 — ［出力~機器（~screen／投影機／印刷機など）が生産できる範囲］— の外側になることもある。そのような`妥当な色$は，当の出力~機器の `色域~外@ （ `out of 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. ◎ Each valid color is either in-gamut for a particular output device (screen, or printer) or it is out of gamut.

例えば、所与の~screenが `display-p3$v 色~空間までに限り受持つ場合、次の色は色域~外になる ⇒ 【！`100% 49.562% 17.429%^rgb】 `color(prophoto-rgb 0.88 0.45 0.10)^v ◎ For example, given a screen which covers 100% of the display-p3 color space, but no more, the following color is out of gamut: • color(prophoto-rgb 0.88 0.45 0.10)

`display-p3$v 内で表出した場合、次のように， 0.0 以上 1.0 以下に入らない座標があるので ⇒ 【！`100% 49.562% 17.429%^rgb】 `color(display-p3 1.0844 0.43 0.1)^v ◎ because, expressed in display-p3, one or more coordinates are either greater that 1.0 or less than 0.0: • color(display-p3 1.0844 0.43 0.1)

この色は妥当であり，~gradientの`色停$としても利用できるが、［見かけは類似するが，より低-色度な（より低~彩度な）色］を生産している~display用には，`~CSS色域~対応付け$が必要になる。 ◎ This color is valid, and could, for example, be used as a gradient stop, but would need to be CSS gamut mapped for display, producing a similar-looking but lower chroma (less saturated) color.

3. ~CSSにおける色の適用-法

3.1. 色により情報を伝達するときの~accessibility

色は、文書をより読易くして，有意な情報を追加できるが、色それ自体が重要な情報を伝達する~~唯一の手段になるべきでない。文書に色を利用する作者は、 `W3C Web Content Accessibility Guidelines^cite `WCAG21$r （ Web 内容~accessibilityを得るための指針）を考慮するベキである。 ◎ Although colors can add significant information to documents and make them more readable, color by itself should not be the sole means to convey important information. Authors should consider the W3C Web Content Accessibility Guidelines [WCAG21] when using color in their documents.

`1.4.1 色の利用＠~TR/WCAG21/#use-of-color$em：［情報を伝達する／動作を指示する／応答を促す／視覚的な要素を判別する］ための視覚的な手段として，色のみに~~頼らないこと。 ◎ 1.4.1 Use of Color: Color is not used as the only visual means of conveying information, indicating an action, prompting a response, or distinguishing a visual element

3.2. 前景~色： `color^p ~prop

◎名 `color@p ◎値 `color$t ◎初 `CanvasText$vS ◎適すべての要素／~text ◎継される ◎百受容しない ◎算 `算出d色$ ◎順文法に従う ◎ア算出d値の型による ◎表終 ◎ Name: color Value: <color> Initial: CanvasText Applies to: all elements and text Inherited: yes Percentages: N/A Computed value: computed color, see resolving color values Canonical order: per grammar Animation type: by computed value type

この~propは、要素の首な前景~色を指定する。これは，要素の~text内容を埋める色として利用されることに加え、 `currentcolor$v の`使用~値$として解決される色を指定する — それは、この前景~色への間接的な参照を許容し，様々な他の色~prop — `border-color$p や `text-emphasis-color$p など — の初期~値に影響する。 ◎ This property specifies the primary foreground color of the element. This is used as the fill color of its text content, and in addition specifies the used value that currentcolor resolves to, which allows indirect references to this foreground color and affects the initial values of various other color properties such as border-color and text-emphasis-color.

`color$t: 首な前景~色を指定された `color$t に設定する。 ◎ Sets the primary foreground color to the specified <color>.

`color$t 型は、所与の色を指定する仕方として，複数の構文を供する。例えば，次に挙げる宣言は、どれも，同じ~sRGB色 `lime^swatch `lime$vN を指定する：

em { color: lime; }             /* 色~keywordで指定する */
em { color: rgb(0 255 0); }     /* ~RGB範囲 0 以上 255 以下で指定する */
em { color: rgb(0% 100% 0%); }  /* ~RGB範囲 0% 以上 100% 以下で指定する */
em { color: color(sRGB 0 1 0); } /* ~sRGB範囲 0.0 以上 1.0 以下で指定する */

◎ The <color> type provides multiple ways to syntactically specify a given color. For example, the following declarations all specify the sRGB color “lime”: ◎ em { color: lime; } /* color keyword */ em { color: rgb(0 255 0); } /* RGB range 0-255 */ em { color: rgb(0% 100% 0%); } /* RGB range 0%-100% */ em { color: color(sRGB 0 1 0); } /* sRGB range 0.0-1.0 */

この~propが~textに適用されるときは、その~alpha成分も含めて，［組込みの~paletteにより色付けられた “色付き~glyph” （一部の~font内にある絵文字など）］に対する効果は無い。しかしながら，一部の有色~fontは、文脈に応じた “前景~色” を参照rし得る — OpenType の COLR ~table内の~palette~entry 0xFFFF や, SVG-in-OpenType 内の `context-fill^v 値【参照： ~SVGの `paint$t 型】などにより。そのような事例では、この~propは — `currentcolor$v の値を設定するときと同じく — 当の前景~色を設定する。 ◎ When applied to text, this property, including its alpha component, has no effect on “color glyphs” (such as the emoji in some fonts), which are colored by a built-in palette. However, some colored fonts are able to refer to a contextual “foreground color”, such as by palette entry 0xFFFF in the COLR table of OpenType, or by the context-fill value in SVG-in-OpenType. In such cases, the foreground color is set by this property, identical to how it sets the currentcolor value.

3.3. 透明度： `opacity^p ~prop

不透明度は、後処理~演算と捉えることができる。概念的には、要素（その子孫も含めて）が~RGBA~offscreen画像に描画されてから，不透明度の設定が［その描画を現在の組成-描画へ混色する方法］を指定する。詳細は `§ 単純~alpha組成-法＠#alpha$ を見よ。 ◎ Opacity can be thought of as a postprocessing operation. Conceptually, after the element (including its descendants) is rendered into an RGBA offscreen image, the opacity setting specifies how to blend the offscreen rendering into the current composite rendering. See simple alpha compositing for details.

◎名 `opacity@p ◎値 `opacity-value$t ◎初 `1^v ◎適すべての要素 ◎継されない ◎百 0 以上 1 以下の範囲へ対応付けられる ◎算指定された実数を 0 以上 1 以下に切詰めた結果 ◎順文法に従う ◎ア算出d値の型による ◎表終 ◎ Name: opacity Value: <opacity-value> Initial: 1 Applies to: all elements Inherited: no Percentages: map to the range [0,1] Computed value: specified number, clamped to the range [0,1] Canonical order: per grammar Animation type: by computed value type

`opacity-value@t: 要素に適用される不透明度。結果の不透明度は、［特定0の色ではなく，要素~全体］に適用される。 ◎ The opacity to be applied to the element. The resulting opacity is applied to the entire element, rather than a particular color.; 不透明度~値は、範囲 0 以上 1 以下に入らない場合でも無効にはならず，指定d値においては保全されるが、算出d値の時点で，この範囲に切詰められる。 ◎ Opacity values outside the range [0,1] are not invalid, and are preserved in specified values, but are clamped to the range [0, 1] in computed values.

~CSSにおける不透明度は、（例えば， `opacity$p ~propにおいて） `opacity-value$t 構文を利用して表現される。 ◎ Opacity in CSS is represented using the <opacity-value> syntax, for example in the opacity property.

`opacity-value$t
	= `number$t
	| `percentage$t

`number$t として表現される場合、その有用な範囲は， `0^v （全に透明を表現する）以上, `1^v （全に不透明を表現する）以下である。 ◎ Represented as a <number>, the useful range of the value is 0 (representing full transparency) to 1 (representing full opacity).＼
`percentage$t として書くこともでき、その`算出d値$は，等価な `number$t になる（ `0%^v は `0^v, `100%^v は `1^v に対応する）。 ◎ It can also be written as a <percentage>, which computes to the equivalent <number> (0% to 0, 100% to 1).

`opacity$p ~propは、指定された不透明度を［当の要素, その内容~すべて］に対し，`一体として^em適用する — 各~子孫ごとに，ではなく。このことは、次を意味する： ◎ The opacity property applies the specified opacity to the element as a whole, including its contents, rather than applying it to each descendant individually.＼

要素の `opacity$p が 1 未満のときでも、［要素の不透明な子が要素の背景を塞ぐ部分は、不透明であり続ける］が，［一体としての［要素, その子~群］は、自身を透かして下層の~pageを示す］ことになる。 ◎ This means that, for example, an opaque child occluding part of the element’s background will continue to do so even when opacity is less than 1, but the element and child as a whole will show the underlying page through themselves.
要素~内にあるすべての文字に対応する~glyphたちは，`一体として扱われる^em — 複数の部位が重合していても、不透明度が増大することはない。 ◎ It also means that the glyphs corresponding to all characters in the element are treated as a whole; any overlapping portions do not increase the opacity.

`opacity$p 値が 1 未満の~textにおける，重合している~glyphに対する正しい描画と不正な描画。 ◎ Correct and incorrect rendering of text with an opacity value of less than one, whose glyphs overlap.

各~glyphに別々な不透明度が欲される場合、 `opacity$p ~propを設定するのではなく， ~alphaを含む色~値を利用して達成できる。 ◎ If separate opacity for each glyph is desired, it can be achieved by using a color value which includes alpha, rather than setting the opacity property.

【要素が生成する】~boxの `opacity$p が 1 未満の場合、 ~boxは，その子~box用の`積層~文脈$を形成する（これは、［ z-軸において，~boxの内容に~boxの外側の内容が差挟まれる］ことを防止する）。 ◎ If a box has opacity less than 1, it forms a stacking context for its children. (This prevents its contents from interleaving in the z-axis with content outside it.)

更には，~boxに `z-index$p ~propが適用される場合、その値 `auto^v は `0^v として扱われる【！for the element】。他の場合、親の積層~文脈の中で［積層-~level 0 を伴う`有位置$な要素と同じ層］に塗られる（ `z-index^p に `0^v を伴う有位置な要素であったかのように）。 ◎ Furthermore, if the z-index property applies to the box, the auto value is treated as 0 for the element; it is otherwise painted on the same layer within its parent stacking context as positioned elements with stack level 0 (as if it were a positioned element with z-index:0).

積層~文脈についての更なる情報は、 `CSS2$r の［ `§ 多層化された呈示＠~CSS2J#layers$, `付録 E＠~CSS22/zindex.html$ ］を見よ。 ◎ See section 9.9 and Appendix E of [CSS2] for more information on stacking contexts.

これらの z-順序についての規則は、 ~SVG要素には適用されない — ~SVGには、自前の描画~model （ `SVG2$r `§ 描画~順序＠~SVGrender#RenderingOrder$ 【！`SVG11$r § 3＠~SVG11/render.html$】）があるので。 ◎ These rules about z-order do not apply to SVG elements, since SVG has its own rendering model ([SVG11], Chapter 3).

`opacity$p ~propの値は、 `接触判定$には影響しない。 ◎ The value of the opacity property does not affect hit testing.

【定義~表tにおいて `opacity$p あるいは `opacity-value$t を参照している他の~propも同様になる？】

3.4. 有~tag画像の色~空間

`有~tag画像@ （ `tagged image^en ）は、ある色~profileが — 当の画像~形式に定義されるとおりに — 明示的にアテガわれた画像である。これは，通例的には、 ~ICC~profile `ICC$r を含めることにより行われる。 ◎ An tagged image is an image that is explicitly assigned a color profile, as defined by the image format. This is usually done by including an International Color Consortium (ICC) profile [ICC].

例えば，［ ~JPEG `JPEG$r, ~PNG `PNG$r, ~TIFF `TIFF$r ］は、どれも~ICC~profileを埋込む手段を指定する。 ◎ For example JPEG [JPEG], PNG [PNG] and TIFF [TIFF] all specify a means to embed an ICC profile.

画像~形式は、他の等価な — 多くは、より~~簡潔にするための — 手法を利用することもある。 ◎ Image formats may also use other, equivalent methods, often for brevity.

例えば，~PNGは、［ ~ICC~profileを含めることなく，画像を明示的に~tag付ける］ための~~簡潔な手段として，次に挙げるものを指定する： ◎ ↓

`sRGB chunk＠~TR/PNG/#11sRGB$en ⇒ 当の画像は，~sRGB色~空間~内にある ◎ For example, PNG specifies a means (the sRGB chunk) to explicitly tag an image as being in the sRGB color space, without including the sRGB ICC profile.
`cICP chunk＠~TR/png-3/#cICP-chunk$en ⇒ 当の画像は，様々な［ ~SDR／~HDR【 `Standard/High Dynamic Range^en 】］色~空間（~Display-P3や BT.2100 HLG など）のうちいずれか内にある。 ◎ Similarly, PNG specifies a compact means (the cICP chunk) to explicitly tag an image as being one of various SDR or HDR color spaces, such as Display P3 or BT.2100 HLG, without including an ICC profile.

有~tag~RGB画像, および［ ~YCbCrなど，~RGBの変形nを利用している有~tag画像］は、［色~profileやそれを識別する他の情報］が妥当である場合には，指定された色~空間~内にあるものと扱うモノトスル。 ◎ Tagged RGB images, and tagged images using a transformation of RGB such as YCbCr, if the color profile or other identifying information is valid, must be treated as being in the specified color space.

例えば，［ ~Display-P3~monitorを備える~systemで稼働している~browser ］は、［ ~Rec2020色~空間 `Rec.2020$r に属する有~tag~JPEG画像］を表示するときは，［その色が正しく表示されるよう，~Rec2020から~Display-P3へ変換する］モノトスル — ~Rec2020に属する値を~Display-P3に属するかのように扱うと，不正な色を生産することになるので。 ◎ For example, when a browser running on a system with a Display P3 monitor displays an JPEG image tagged as being in the ITU Rec BT.2020 [Rec.2020] color space, it must convert the colors from ITU Rec BT.2020 to Display P3 so that they display correctly. It must not treat the ITU Rec BT.2020 values as if they were Display P3 values, which would produce incorrect colors.

［色~profileやそれを識別する他の情報］が妥当でない場合、当の画像は`無~tag画像$用に述べられたものとして扱われる。 ◎ If the color profile or other identifying information is invalid, the image is treated as described for untagged images.

3.5. 無~tagな色が成す色~空間

互換性を得るため、［ ~HTMLにて指定される色／ `無~tag画像$ ］は， ~sRGB色~空間（ `SRGB$r ）に属するものとして扱うモノトスル — 他が指定されない限り。 ◎ For compatibility, colors specified in HTML, and untagged images must be treated as being in the sRGB color space ([SRGB]) unless otherwise specified.

`無~tag画像@ （ `untagged image^en ）とは、［当の画像~形式による定義に従って，色~profileが明示的にアテガわれている画像］ではない画像を指す。【！`有~tag画像$の否定とは言い切れない】 ◎ An untagged image is an image that is not explicitly assigned a color profile, as defined by the image format.

この規則は、動画には適用されないことに注意。 `無~tag動画@ （ `untagged video^en ）は、 ~ITUが定義する色~空間に属するものと予め見做されるべきなので。 ◎ This rule does not apply to untagged videos, since untagged video should be presumed to be in an ITU-defined color space.

720p 未満においては、それは `ITU-R-BT.601$r を指す。 ◎ At below 720p, it is Recommendation ITU-R BT.601 [ITU-R-BT.601]
720p においては、それは `SMPTE296$r（ 709 と同じ色計量y）を指す。 ◎ At 720p, it is SMPTE ST 296 (same colorimetry as 709) [SMPTE296]
1080p においては、それは `ITU-R-BT.709$r を指す。 ◎ At 1080p, it is Recommendation ITU-R BT.709 [ITU-R-BT.709]
4k （ UHDTV【~~超高精細テレビ】）以上においては、それは~SDR動画~用の `Rec.2020$r を指す。 ◎ At 4k (UHDTV) and above, it is ITU-R BT.2020 [Rec.2020] for SDR video

4. 色の表現-法： `color$t 型

~CSSにおける色は、［色~空間~内の各~軸を表現している色~成分］たちが成す~listとして表現される — そのような各~成分は、ときには， “~channel” とも呼ばれる。各~成分がとり得る値には、最小と最大があり，その合間にあるどの値もとれる。加えて、どの色にも， `~alpha成分@ が付随する — それは、不透明度 — 後景が色を通してどの程度透けて見えるか — を指示する。 ◎ Colors in CSS are represented as a list of color components, also sometimes called “channels”, representing axises in the color space. Each component has a minimum and maximum value, and can take any value between those two. Additionally, every color is accompanied by an alpha component, indicating how transparent it is, and thus how much of the backdrop one can see through the color.

~CSSには、色~値を指定するための構文がいくつかある： ◎ CSS has several syntaxes for specifying color values:

~sRGB`~hex色$は、各~RGB成分, ~alpha成分を~hex記法で表現する。 ◎ the sRGB hex color notation which represents the RGB and alpha components in hexadecimal notation
各種`色~関数$は、様々な色~空間と座標系を利用して色を表現できる。 ◎ the various color functions which can represent colors using a variety of color spaces and coordinate systems
`有名~色$用の~keyword — これらは、【文脈によらず】一定な色を与える。 ◎ the constant named color keywords
`system-color$t, `currentcolor$v ~keyword — これらは、【文脈に応じて】可変な色を与える。 ◎ the variable <system-color> keywords and currentColor keyword.

`色~関数@ は、様々な`色~空間$内の色を — それらの成分~座標を~CSS`関数-記法$を利用して指定することにより — 表現する。これらは、次のいずれかの~modelを利用する： ◎ The color functions use CSS functional notation to represent colors in a variety of color spaces by specifying their component coordinates.＼

`円柱な極-座標@ （ `cylindrical polar color^en ）は、次を利用して色を指定する ⇒＃ `hue$t （色相）角度, 明度（ ~black 〜 ~white ）を表現している中心-軸, 彩度または色度（中立な~grayからどれだけ離れているか）を表現している半径 ◎ Some of these use a cylindrical polar color model, specifying color by a <hue> angle, a central axis representing lightness (black-to-white), and a radius representing saturation or chroma (how far the color is from a neutral grey).＼
`矩形な直交-座標@ （ `rectangular orthogonal color^en ）は、次を利用して色を指定する ⇒ 3 本の互いに直交な成分~軸 ◎ The others use a rectangular orthogonal color model, specifying color using three orthogonal component axes.

この~level 4 にて可用な`色~関数$は： ◎ The color functions available in Level 4 are

`rgb$f, およびその別名 `rgba$f ⇒ ~sRGB色を指定する — その［ ~red, ~green, ~blue, ~alpha ］成分により直に（`~hex色$の様に）。 ◎ rgb() and its rgba() alias, which (like the hex color notation) specify sRGB colors directly by their red/green/blue/alpha components.
`hsl$f, およびその別名 `hsla$f ⇒ ~sRGB色を指定する — `~HSL＠#the-hsl-notation$の円柱な座標~modelを利用して，［色相, 彩度, 明度］により。 ◎ hsl() and its hsla() alias, which specify sRGB colors by hue, saturation, and lightness using the HSL cylindrical coordinate model.
`hwb$f ⇒ ~sRGB色を指定する — `~HWB＠#the-hwb-notation$の円柱な座標~modelを利用して，［色相, 白度, 黒度］により。 ◎ hwb(), which specifies an sRGB color by hue, whiteness, and blackness using the HWB cylindrical coordinate model.
`lab$f ⇒ ~CIE~Lab色を指定する — `~CIE~Lab＠#cie-lab$の矩形な座標~modelを利用して， ~CIE明度, および色相~座標を与える［ a 軸（~red ↔ ~green度）, b 軸（~yellow ↔ ~blue度）］により。 ◎ lab(), which specifies a CIELAB color by CIE Lightness and its a- and b-axis hue coordinates (red/green-ness, and yellow/blue-ness) using the CIE LAB rectangular coordinate model.
`lch$f ⇒ ~CIE~Lab色を指定する — `~CIE~LCH＠#cie-lab$の円柱な座標~modelを利用して，［ ~CIE明度, 色度, 色相］により。 ◎ lch() , which specifies a CIELAB color by CIE Lightness, Chroma, and hue using the CIE LCH cylindrical coordinate model
`oklab$f ⇒ ~Oklab色を指定する — `~OkLCh色~空間$の矩形な座標~modelを利用して， ~Oklab明度, および色相~座標を与える［ a 軸（~red ↔ ~green度）, b 軸（~yellow ↔ ~blue度）］により。 ◎ oklab(), which specifies an Oklab color by Oklab Lightness and its a- and b-axis hue coordinates (red/green-ness, and yellow/blue-ness) using the Oklab rectangular coordinate model.
`oklch$f ⇒ ~Oklab色を指定する — `~OkLCh色~空間$の円柱な座標~modelを利用して，~Oklab［明度, 色度, 色相］により。 ◎ oklch() , which specifies an Oklab color by Oklab Lightness, Chroma, and hue using the OkLCh cylindrical coordinate model.
`color$f ⇒ 次に挙げるものを含む，様々な色~空間~内の色を指定することを許容する ⇒＃ `~sRGB＠#predefined-sRGB$, `光に線形な~sRGB＠#predefined-sRGB-linear$, `~Display-P3＠#predefined-display-p3$, `光に線形な~Display-P3＠#predefined-display-p3-linear$, `~A98~RGB＠#predefined-a98-rgb$, `~ProPhoto~RGB＠#predefined-prophoto-rgb$, `~Rec2020＠#predefined-rec2020$, `~CIE~XYZ＠#predefined-xyz$ ◎ color(), which allows specifying colors in a variety of color spaces including sRGB, Linear-Light sRGB, Display P3, Linear-Light Display P3, A98 RGB, ProPhoto RGB, ITU-R BT.2020-2, and CIE XYZ.

他の仕様から参照し易くするため、次の用語が定義される：

`不透明な黒@ （ `opaque black^en ）: `rgb(0 0 0 / 100%)^v が表現する色。
`透明な黒@ （ `transparent black^en ）: `rgb(0 0 0 / 0%)^v が表現する色 — すなわち，`不透明な黒$と色は同じだが，全に透明な色。

◎ For easy reference in other specifications, opaque black is defined as the color rgb(0 0 0 / 100%); transparent black is the same color, but fully transparent—i.e. rgb(0 0 0 / 0%).

4.1. `color^t 構文

~CSSにおける色は、 `color@t 型で表現される： ◎ Colors in CSS are represented by the <color> type:

`color^t
	= `color-base$t
	| `currentcolor$v
	| `system-color$t

`color-base@t
	= `hex-color$t
	| `color-function$t
	| `named-color$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値は，絶対的な色計量で解釈されるもの］をいう。これは、当の値が次に挙げるものでない【すなわち， `color-base$t である】ことを意味する： ◎ 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)

次に挙げる色が， `~sRGB$に解決される ⇒＃ `~hex色$【！#hex-notation】, `有名~色$【！#named-colors】, `rgb$f 値, `rgba$f 値, `hsl$f 値, `hsla$f 値, `hwb$f 値 ◎ The colors that resolve to sRGB are: • hex colors • rgb() and rgba() values • hsl() and hsla() values • hwb() values • named colors

次に挙げる`色~関数$が， `旧来の色~構文$を~supportする（他の色~関数は`~supportしない$em） ⇒＃ `rgb$f, `rgba$f, `hsl$f, `hsla$f ◎ The functions that support legacy color syntax are: • rgb() and rgba() • hsl() and hsla()

次に挙げる`色~関数$が，［ `hue$t 角度を利用する`円柱な極-座標$ ］を利用して色を表現する — 他の色~関数は，`矩形な直交-座標$を利用する ⇒＃ `hsl()$t, `hsla()$t, `hwb()$t, `lch()$t, `oklch()$t ◎ The <hsl()>, <hsla()>, <hwb()>, <lch()>, and <oklch()> color functions are cylindrical polar color representations using a <hue> angle; the other color functions use rectangular orthogonal color representations.

4.1.1. 現代の（~spaceで分離された）色~関数~構文

この仕様~内に定義される`絶対的な色$を成す関数-形【 `color-function$t 】は、すべて， `現代の色~構文@ を利用する — すなわち： ◎ All of the absolute color functional forms first defined in this specification use the modern color syntax, meaning:

色~成分どうしは、空白で分離される。 ◎ color components are separated by whitespace
省略可能な~alpha項は、 ~slash（ `/^l ）で分離される。 ◎ the optional alpha term is separated by a solidus ("/")
`直列化する＠#serializing-color-values$ときに要求される最小な精度が定義され、成分ごとに 8 ~bitを超え得る。 ◎ minimum required precision when serializing is defined, and may be greater than 8 bits per component
`欠落~成分$を表現する値 `none$v も許容される。 ◎ the none value is allowed, to represent missing components
［ `percentage$t を利用している成分, `number$t を利用している成分］が混在していても，かまわない。 ◎ components using <percentage> and <number> may be freely mixed

`rgb(100% 0% 0% / 50%)^v は、 50% 不透明な有彩度な~sRGB~redを表現する。 ◎ The following represents a saturated sRGB red that is 50% opaque: • rgb(100% 0% 0% / 50%)

4.1.2. 旧来の（~commaで分離された）色~関数~構文

~Web互換性を得るため，以前の仕様にて定義された構文-形［ `rgb$f, `rgba$f, `hsl$f, `hsla$f ］は、 `旧来の色~構文@ も~supportする — それには、次に挙げる相違点がある： ◎ For Web compatibility, the syntactic forms of rgb(), rgba(), hsl(), and hsla(), (those defined in earlier specifications) also support a legacy color syntax which has the following differences:

色~成分どうしは、 ~comma（および，その前後の省略可能な空白）で分離される。 ◎ color components are separated by commas (optionally preceded and/or followed by whitespace)
不透明でない形は、別々な記法を利用する（例： `hsl$f でなく `hsla$f ）。その~alpha項は、 ~comma（および，その前後の省略可能な空白）で分離される。 ◎ non-opaque forms use a separate notation (for example hsla() rather than hsl()) and the alpha term is separated by commas (optionally preceded and/or followed by whitespace)
各~成分に要求される最小な精度は、より低い 8 ~bitである。 ◎ minimum required precision is lower, 8 bits per component
値 `none$v は許容されない。 ◎ the none value is not allowed
色~成分たちは、［すべて `percentage$t ／すべて `number$t ］どちらかを利用して指定しなければナラナイ — それらは、混在し得ない。 ◎ color components must be specified using either all-<percentage> or all-<number>, they can not be mixed.

`rgba(100%, 0%, 0%, 0.5)^v は、 50% 不透明な有彩度な~sRGB~redを表現する。 ◎ The following represents a saturated sRGB red that is 50% opaque: • rgba(100%, 0%, 0%, 0.5)

この~level 4 以降に導入される`色~関数$には，~Web互換性の課題は無いので、それらにおいては，`旧来の色~構文$は妥当でない。 ◎ For the color functions introduced in this or subsequent levels, where there is no Web compatibility issue, the legacy color syntax is invalid.

4.2. 色における透明度の表現-法： `alpha-value^t 構文

`alpha-value@t
	= `number$t
	| `percentage$t

注記： ~alpha成分は、 `旧来の色~構文$用には，この構文がそのまま利用されるが、 `現代の色~構文$用には，値 `none$v もとり得るよう拡張される。 ◎ Note: This syntax is used as-is for legacy color syntax. For modern color syntax, it is extended so that alpha components can also take the value none.

他が指定されない限り、色の `alpha-value$t 成分が省略された場合の既定は， `100%^v になるとする。範囲 0 以上 1 以下に入らない値も無効にはならないが、構文解析した時点で，この範囲に切詰められる。 ◎ Unless otherwise specified, an <alpha-value> component of a color defaults to 100% when omitted. Values outside the range [0,1] are not invalid, but are clamped to that range at parsed-value time.

【 `opacity-value$t と同じ構文であり（ `number^t と `percentage^t の対応関係も同じ），同じく不透明度を表現する（ `1^v が全に不透明）が、いつ切詰められるかが異なる（それゆえ， `opacity-value^t が新たに定義された）。】

4.3. 円柱な座標による色相の表現-法： `hue^t 構文

色相は、 `色相環＠https://ja.wikipedia.org/wiki/%E8%89%B2%E7%9B%B8#.E8.89.B2.E7.9B.B8.E7.92.B0$ における角度として表現される【！(the rainbow, twisted...】。 ◎ Hue is represented as an angle of the color circle (the rainbow, twisted around into a circle, and with purple added between violet and red).

`hue@t
	= `number$t
	| `angle$t

この値は，度数（ ° ／ `deg$u 単位／ `degrees^en ）で与えられることが多いので、単位なしの実数として与えることもでき，度数として解釈される — 度数は、角度~用の`正準-単位$である。 ◎ Because this value is so often given in degrees, the argument can also be given as a number, which is interpreted as a number of degrees and is the canonical unit.

この実数は、範囲 0 以上 360 未満に正規化される。 ◎ This number is normalized to the range [0,360).

例えば，次に挙げる色（いずれも `#000^swatch `不透明な黒$）の `hue$t 成分は ⇒＃ `hsl(-540 0 0)^v においては 180° ／ `hsl(540 0 0)^v においては 180° ／ `hsl(360 0 0)^v においては 0° ／ `hsl(calc(-infinity) 0 0)^v においては 0° ／ `hsl(calc(infinity) 0 0)^v においては 0° ◎終に正規化される。 ◎ For example, in hsl(-540 0 0) or hsl(540 0 0), the <hue> component is normalized to 180 degrees. ◎ In hsl(360 0 0) the <hue> component is normalized to 0 degrees. ◎ In hsl(calc(-infinity) 0 0) or hsl(calc(infinity) 0 0), the <hue> component is again normalized to 0 degrees.

注記：特定0の色相に対応する角度と~~分布は、色~空間に依存する。例えば、 ~sRGB色~空間を利用する［ ~HSL／~HWB ］においては，~sRGB~greenは 120° になり、 ~LCHにおいては［ ~sRGB~greenは 134.39° ／ `display-p3$v ~greenは 136.01° ／ `a98-rgb$v ~greenは 145.97° ／ `prophoto-rgb$v ~greenは 141.04° ］になる（これらすべては、濃淡が異なる~greenなので）。 ◎ Note: The angles and spacing corresponding to particular hues depend on the color space. For example, in HSL and HWB, which use the sRGB color space, sRGB green is 120 degrees. In LCH, sRGB green is 134.39 degrees, display-p3 green is 136.01 degrees, a98-rgb green is 145.97 degrees and prophoto-rgb green is 141.04 degrees (because these are all different shades of green).

`無力$になることが最も共通的な成分は、 `hue$t 成分である — どの色も、無彩度~軸に “十分近い” ならば，その色相~成分は`無力$になる。 ◎ <hue> components are the most common components to become powerless; any color sufficiently close to the central achromatic axis will have a powerless hue component.

4.4. “欠落” 色~成分と `none^v ~keyword

ある種の事例では、色は， 1 個~以上の `欠落~成分@ （ `missing color component^en ）を伴い得る。 ◎ In certain cases, a color can have one or more missing color components.

【略して， `missing component^en あるいは `missing^en — この訳では、一律に（前者の略記に対応する） “欠落~成分” と表記する。】

これは、自動的に起こることもある： ◎ ↓

この仕様においては、一部の色（ `white$vN など）【無彩-色】に対し， `色相に基づく補間＠#hue-interpolation$に因り起こる。 ◎ In this specification, this happens automatically due to hue-based interpolation for some colors (such as white);＼
他の仕様も［自動的に，`欠落~成分$になる状況］を追加的に定義し得る。 ◎ other specifications can define additional situations in which components are automatically missing.

それはまた、色~関数~内のある成分に~keyword `none@v を供することにより，明示的に指定できる。すべての色~関数は（`旧来の色~構文$を利用しているものは例外として）、どの成分にも， `none$v を指定することを許容する。 ◎ It can also be specified explicitly, by providing the keyword none for a component in a color function. All color functions (with the exception of those using the legacy color syntax) allow any of their components to be specified as none.

これは、特定0の効果が欲されるときに限り，~careの下で行うベキである。 ◎ This should be done with care, and only when the particular effect of doing so is desired.

2 つの色を組合せる状況 — 色~補間など — における`欠落~成分$の取扱いは、 `§ 欠落~成分との補間-法＠#interpolation-missing$ を見よ。 ◎ For handling of missing components in situations which combine two colors, such as color interpolation, see § 13.2 Interpolating with Missing Components.

他のすべての目的においては、 `欠落~成分$は，その成分に適切な単位を伴う 0 値 — `0^v ／ `0%^v ／ `0deg^v — として挙動する。これには、当の色を［直に描画するとき／別の色~空間へ変換するとき］や［当の色~成分~値の算出を遂行するとき~FN ］, 等々も含まれる。 ◎ For all other purposes, a missing component behaves as a zero value, in the appropriate unit for that component: 0, 0%, or 0deg. This includes rendering the color directly, converting it to another color space, performing computations on the color component values, etc.

【~FN 例えば、色~関数~内に入子にされた`~math関数$内に利用された`成分~keyword$が `none$v をとるとき。】

`欠落~成分$を伴う色が，［直列化されるその他，作者に直に呈示される場合］【すなわち，~APIを介して~scriptに公開される場合】、その成分は，［ `旧来の色~構文$用には 0 値／ ~ELSE_ `none$v ~keyword ］として表現される。 ◎ If a color with a missing component is serialized or otherwise presented directly to an author, then for legacy color syntax it represents that component as a zero value; otherwise, it represents that component as being the none keyword.

色相が`欠落~成分$になることは、円柱な色~空間~内で補間するときに共通的にある。例えば、 `color-mix$f 関数 `CSS-COLOR-5$r を利用して， `color-mix(in hsl, white 30%, green 70%)^v と書くこともできる。 `white$vN は無彩-色なので、 `hsl$f で表出されるときには，その色相は`欠落~成分$になる（実質的に `hsl(none 0% 100%)^v になる — 色相が何であれ，同じ色を生産するので）。このことは、次を意味する ⇒ `color-mix$f 関数は、 `white$vN を `green$vN （ `hsl(120deg 0% 100%)^v ）と同じ色相を有するものと扱ってから，それらの成分に基づいて補間する。 ◎ A missing hue is common when interpolating in cylindrical color spaces. For example, using the color-mix() function specified in [CSS-COLOR-5] one could write color-mix(in hsl, white 30%, green 70%). Since white is an achromatic color, it has a missing hue when expressed in hsl() (effectively hsl(none 0% 100%)), since any hue will produce the same color) which means that the color-mix function will treat it as having the same hue as green (effectively hsl(120deg 0% 100%)), and then interpolate based on those components.

結果の色は、 ~~本当に~greenと~whiteを混色した様な見かけになり， ~redがかった見かけ（ `white^v の色相が既定で `0deg^v になるとした場合）にはならない。 ◎ The result will be a color that truly looks like a blend of green and white, rather than perhaps looking reddish (if whites hue was defaulted to 0deg).

欠落~成分を明示的に指定することは、［ある種の成分に限り，色を補間する効果］を達成するよう`求まれる^em所で有用になり得る。 ◎ Explicitly specifying missing components can be useful to achieve an effect where you only want to interpolate certain components of a color.

例えば，所与の色が何であれ、その色から開始して “~grayscale” へ~animateするときは， `oklch(none 0 none)^v で補間できる。これは、［所与の色から色相と明度をとるが，色度だけ 0 へ下げていくよう~animateする］ことで、 ~animation全体を通して［色相, 明度］を~~一定に~~保ちながら，~grayへ向かうよう描画する。 ◎ For example, to animate a color to "grayscale", no matter what the color is, one can interpolate it with oklch(none 0 none). This will take the hue and lightness from the starting color, but animate its chroma down to 0, rendering it into an equal-lightness gray with a steady hue across the whole animation.

これを手動で行うためには、補間する 2 つの色の［色相, 明度］を明示的に合致させることが要求されよう。 ◎ Doing this manually would require matching the hue and lightness of the starting color explicitly.

4.4.1. “無力” な色~成分

個々の色~構文は、その構文の所与の成分を，一部の事例では `無力@ （ `powerless^en ）になるものと指定し得る。これは、当の成分の値は，描画される色には影響しないことを指示する — その成分の値に何を与えようが，~screenに表示される結果は同じ色になる。 ◎ Individual color syntaxes can specify that, in some cases, a given component of their syntax becomes a powerless color component. This indicates that the value of the component doesn’t affect the rendered color; any value you give it will result in the same color displayed in the screen.

例えば `hsl$f においては、彩度~成分が `0%^v のときには，色相~成分は`無力$になる — 彩度 `0%^v は，色相がまったくない【色相が適用-不能な】~grayscale色を指示するので、色相がどの角度であっても，正確に同じ結果を与えることになる。 ◎ For example, in hsl(), the hue component is powerless when the saturation component is 0%; a 0% saturation indicates a grayscale color, which has no hue at all, so 0deg and 180deg, or any other angle, will give the exact same result.

`無力$な成分が手動で指定された場合、それは通常通り動作する — それが`無力$である事実には、効果は無い。 ◎ If a powerless component is manually specified, it acts as normal; the fact that it’s powerless has no effect.

しかしながら，色~空間の変換により自動的に生産される色においては、その`無力$な成分は — 変換~処理nにより生産される値が何であれ — `欠落~成分$に設定するモノトスル。 ◎ However, if a color is automatically produced by color space conversion, then any powerless components in the result must instead be set to missing, instead of whatever value was produced by the conversion process.

~UAは、 `円柱な極-座標$による色~空間への変換を遂行するとき，結果の色彩度（ `measure of colorfulness^en ） — `oklch$v における色度や `hsl$v における彩度など — が当の色~空間~用に指定された `微小数@ （ `epsilon^en ）未満【または以下（場合による）】になる場合には、結果の色相~成分を`無力$として扱う`モノトスル^em【！shall】。例えば，~gray色を `oklch$v【！`oklch$f】の中へ変換した結果の色度は、［丸誤差に因り、精確に `0%^v にはならず，それに`極めて近く^emなる］こともあろうが，結果の色相~成分は`無力$になる。 ◎ When performing color space conversion to a cylindrical polar color space, user agents shall treat a hue component as powerless if the chroma (or other measure of colorfulness, such as saturation in hsl) is less than the epsilon (ε) specified for that color space. For example, a gray color converted into oklch() may, due to numerical errors, have an extremely small chroma rather than precisely 0%; as a result, the hue component is powerless.

4.5. `color$t 値の構文解析-法

`~CSS色~値を構文解析する@ ~algoは、所与の ( `文字列$ %入力, `要素$ %文脈~要素 ~DF ε ) に対し： ◎ To parse a CSS <color> value, given a string input, and an optional context element element:

%色 ~LET %入力を `color$t の`文法に則って構文解析する$ ◎ Parse input as a <color>.＼
~IF［ %色 ~EQ `失敗^i ］ ⇒ ~RET `失敗^i ◎ If the result is failure, return failure; otherwise, let color be the result.
%使用~色 ~LET %色を`使用~色$に`解決する＠#resolving-color-values$ — ある要素の~propに %入力を成す `color$t を与えたとするとき、それを解決するためには，当の要素の他の~prop %~prop の値が要求される場合（例： `currentcolor$v や`~system色$） ⇒＃ %文脈~要素 ~NEQ ε ならば %文脈~要素の %~prop の値を利用する／ ~ELSE_ %~prop の`初期~値$を利用する ◎ Let used color be the result of resolving color to a used color. If the value of other properties on the element a <color> is on is required to do the resolution (such as resolving a currentcolor or system color), use element if it was passed, or the initial values of the properties if not.
~RET %使用~色 ◎ Return used color.

注記：この~algoは、［ ~CSS~stylesheet内／~CSSOM~interface ］で指定された~CSS `color$t 値を構文解析するために意図されたものではない — ~HTML属性や~HTML~Canvas~interfaceの様な他の場所で指定されたものに意図される。 ◎ Note: This algorithm is not intented to parse a CSS <color> value specified in a CSS stylesheet or with a CSSOM interface, but in other places like HTML attributes or Canvas interfaces.

5. ~sRGB色

`~sRGB$色~空間による~CSS色は、値の三組 — ~red, ~green, ~blue — により表現され，~sRGB色~空間 `SRGB$r 内のある点を識別する。この色~空間は，［国際的に認識される，機器に依存しない色~空間］であり、 ~computer~screenに対し表示される色を指定するときのみならず，印刷機の様な他の型の機器に対し色を指定するときにも有用にもなる。 ◎ CSS colors in the sRGB color space are represented by a triplet of values—red, green, and blue—identifying a point in the sRGB color space [SRGB]. This is an internationally-recognized, device-independent color space, and so is useful for specifying colors that will be displayed on a computer screen, but is also useful for specifying colors on other types of devices, like printers.

~CSSでは、 ~sRGBでない`色~空間$の利用も許容される。それらについては、 § `定義済み色~空間$に述べる。 ◎ CSS also allows the use of non-sRGB color spaces, as described in § 10 Predefined Color Spaces.

~CSSは、 ~sRGB色を直に指定するための手法として，次に挙げるものを供する：

`~hex色$
`有名~色$
`transparent$v ~keyword
各種 `色~関数$のうち，次に挙げるもの ⇒＃ `rgb$f, `rgba$f, `hsl$f, `hsla$f, `hwb$f

◎ CSS provides several methods of directly specifying an sRGB color: hex colors, rgb()/rgba() color functions, hsl()/hsla() color functions, hwb() color function, named colors, and the transparent keyword.

5.1. ~RGB関数： `rgb^f, `rgba^f

［ `rgb$f ／ `rgba$f ］関数は、［ r, g, b （ ~red, ~green, ~blue ）］成分を直に指定して~sRGB色を定義する。その構文は： ◎ The rgb() and rgba() functions define an sRGB color by specifying the r, g and b (red, green, and blue) components directly. Their syntax is:

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

【関数~名を除いて， `rgb^f と `rgba^f の構文は一致する。】

百分率	r, g, b に許容される
百分率t基準~範囲（ r, g, b ）	0% = 0.0, 100% = 255.0
百分率t基準~範囲（ ~alpha ）	0% = 0.0, 100% = 1.0

◎ Percentages｜Allowed for r, g and b Percent reference range｜For r, g and b: 0% = 0.0, 100% = 255.0 For alpha: 0% = 0.0, 100% = 1.0

最初の 3 個の引数は、順に，色の［ r, g, b （ ~red, ~green, ~blue ）］成分を指定する。 `percentage$t を成す［ `0%^v ／ `100%^v ］は、 ~sRGB色域における当の色~成分の［最小~値／最大~値］を表現する。 ◎ The first three arguments specify the r, g and b (red, green, and blue) components of the color, respectively. 0% represents the minimum value for that color component in the sRGB gamut, and 100% represents the maximum value.

色~成分の百分率~基準~範囲は、多くの~graphic~engineが，色~成分を［ 0 以上 255 以下の整数を保持できる単独の~byte ］として内部的に格納していた歴史的な事実に由来する。実装は，アリな所では、成分の精度を［著作-／計算- ］されたとおりに尊守するベキである。これがアリでない場合、当の成分を`丸める$ベキである。 ◎ The percentage reference range of the color components comes from the historical fact that many graphics engines stored the color components internally as a single byte, which can hold integers between 0 and 255. Implementations should honor the precision of the component as authored or calculated wherever possible. If this is not possible, the component should be rounded towards +∞.
~~最後の引数 `alpha-value$t は、色の~alphaを指定する。省略-時の既定は `100%^v になる。 ◎ The final argument, the <alpha-value>, specifies the alpha of the color. If omitted, it defaults to 100%.

これらの範囲~外の値も無効ではないが、値に構文解析した時点でここで定義した範囲に切詰められる。 ◎ Values outside these ranges are not invalid, but are clamped to the ranges defined here at parsed-value time.

歴史的な理由により、［ `rgb$f ／ `rgba$f ］関数は，`旧来の色~構文$も~supportする。 ◎ For historical reasons, rgb() and rgba() also support a legacy color syntax.

5.2. RGB ~hex記法： `#RRGGBB^v

~CSS `~hex色@ 記法により、各~成分に~hex数を与えて~sRGB色を指定することも許容される。それは、 ~computer~codeで色を直に与えるときによくある書き方に類似する。また、 `rgb$f 記法より短く書ける。 ◎ The CSS hex color notation allows an sRGB color to be specified by giving the components as hexadecimal numbers, which is similar to how colors are often written directly in computer code. It’s also shorter than writing the same color out in rgb() notation.

`hex-color@t の構文は、［［ 3 ／ 4 ／ 6 ／ 8 ］個の~hex数字が成す並び］を.値にとる `hash-token$t ~tokenである。言い換えれば、 ~hex色は，［ ~hash文字 `#^l, ［ 3 ／ 4 ／ 6 ／ 8 ］個の［数字 0 〜 9 または英字 a 〜 f ］］が成す並びで記される（英字は大小無視なので， `#00ff00^v は `#00FF00^v と同じになる）。 ◎ The syntax of a <hex-color> is a <hash-token> token whose value consists of 3, 4, 6, or 8 hexadecimal digits. In other words, a hex color is written as a hash character, "#", followed by some number of digits 0-9 or letters a-f (the case of the letters doesn’t matter - #00ff00 is identical to #00FF00).

~hex記法を~RGB色に復号する方法は、所与の~hex数字の個数に応じて： ◎ The number of hex digits given determines how to decode the hex notation into an RGB color:

6 桁: 2 桁ごとに~hex数として解釈され、順に，色の［ ~red, ~green, ~blue ］成分を指定する。ここで，［ `00^v が色の最小~値／ `ff^v （ 10 進数で255 ）が色の最大~値］を表現する。色の~alpha成分は全に不透明になる。 ◎ The first pair of digits, interpreted as a hexadecimal number, specifies the red component of the color, where 00 represents the minimum value and ff (255 in decimal) represents the maximum. The next pair of digits, interpreted in the same way, specifies the green component, and the last pair specifies the blue. The alpha component of the color is fully opaque.; 例えば， `#00ff00^v は、 `0 255 0^rgb `rgb(0 255 0)^v と同じ色（~lime~green）を表現する。 ◎ In other words, #00ff00 represents the same color as rgb(0 255 0) (a lime green).
8 桁: 最初の 6 桁は、 6 桁~記法と同じに解釈される。最後の 2 桁も~hex数に解釈され、色の~alpha成分を指定する。ここで，［ `00^v は全に透明な色／ `ff^v は全に不透明な色］を表現する。 ◎ The first 6 digits are interpreted identically to the 6-digit notation. The last pair of digits, interpreted as a hexadecimal number, specifies the alpha component of the color, where 00 represents a fully transparent color and ff represent a fully opaque color.; したがって， `#0000ffcc^v は、 `0% 0% 100% / 80%^rgb `rgb(0% 0% 100% / 80%)^v【！rgb(0 0 100% / 80%)】と同じ色（少しばかり透明な~blue）を表現する。 ◎ In other words, #0000ffcc represents the same color as rgb(0 0 100% / 80%) (a slightly-transparent blue).
3 桁: これは、 6 桁~記法を短く記す変種である。 1 桁ごとに~hex数として解釈され、順に，色の［ ~red, ~green, ~blue ］成分を指定する。ここで，［ `0^v が色の最小~値／ `f^v が色の最大~値］を表現する。色の~alpha成分は全に不透明になる。 ◎ This is a shorter variant of the 6-digit notation. The first digit, interpreted as a hexadecimal number, specifies the red component of the color, where 0 represents the minimum value and f represents the maximum. The next two digits represent the green and blue components, respectively, in the same way. The alpha component of the color is fully opaque.; この構文は、［すべての桁を “二重に” して得される 6 桁~記法と同じになる］と説明されることも多い。例えば、 `#123^v による表記は， `#112233^swatch `#112233^v による表記と同じ色を指定する。この手法は、 6 桁~記法より “解像度” が低い。 3 桁の~hex構文では 4096 色しか表出できない一方で， 6 桁の~hex構文では ( 4096 ~MUL 4096 ) 色がアリになる。 ◎ This syntax is often explained by saying that it’s identical to a 6-digit notation obtained by "duplicating" all of the digits. For example, the notation #123 specifies the same color as the notation #112233. This method of specifying a color has lower "resolution" than the 6-digit notation; there are only 4096 possible colors expressible in the 3-digit hex syntax, as opposed to approximately 17 million in 6-digit hex syntax.
4 桁: これは、 8 桁~記法を短くした変種であり， 3 桁~記法と同じ仕方で “展開される” 。最初の 3 桁は 3 桁~記法と同様に解釈される。最後の桁は~alpha成分を表現し，同様に［ `0^v が最小~値／ `f^v が最大~値］に解釈される。 ◎ This is a shorter variant of the 8-digit notation, "expanded" in the same way as the 3-digit notation is. The first digit, interpreted as a hexadecimal number, specifies the red component of the color, where 0 represents the minimum value and f represents the maximum. The next three digits represent the green, blue, and alpha components, respectively.

6. 色~keyword

`color$t 用の様々な数量-構文に加え、 ~CSSでは，代わりに利用できる色~keywordたちが成す集合もいくつか定義する — それぞれには、自前の［利点／利用事例］がある。 ◎ In addition to the various numeric syntaxes for <color>s, CSS defines several sets of color keywords that can be used instead—each with their own advantages or use cases.

6.1. 有名~色

共通的な色をもっと容易に［書ける／読める］ようにするため、 ~CSSは，長大な `有名~色@ たちが成す集合 — `named-color@t — を定義する。 `named-color$t は、 `ident$t として記され， `color$t が受容される所ならどこでも利用できる。 ~CSSにより定義される通例の `ident$t と同様に、これらの~keywordは，すべて`~ASCII大小無視$である。 ◎ CSS defines a large set of named colors, so that common colors can be written and read more easily. A <named-color> is written as an <ident>, accepted anywhere a <color> is. As usual for CSS-defined <ident>s, all of these keywords are ASCII case-insensitive.

これらの名前は、 ~sRGB色に解決される。 ◎ The names resolve to colors in sRGB.

~CSSの有名~色のうち： ◎ ↓

次に挙げる 16 個の色は、元々は~VGA~paletteに由来し，~HTMLに採用された ⇒＃ `aqua^v, `black^v, `blue^v, `fuchsia^v, `gray^v, `green^v, `lime^v, `maroon^v, `navy^v, `olive^v, `purple^v, `red^v, `silver^v, `teal^v, `white^v, `yellow^v ◎ 16 of CSS’s named colors come from the VGA palette originally, and were then adopted into HTML: aqua, black, blue, fuchsia, gray, green, lime, maroon, navy, olive, purple, red, silver, teal, white, and yellow.＼
残りを成すほとんどは、 ~X11色~systemのある~versionに由来し， ~Unix系の~systemで~consoleの色を指定するときに利用され， ~SVGに採用された。 ◎ Most of the rest come from one version of the X11 color system, used in Unix-derived systems to specify colors for the console, and were then adopted into SVG.

注記：これらの色~名がここに標準~化されているわけは、 `それらが良いからではない^em — それらの利用と実装が何十年も広く~~普及していて、標準は，その現実を反映する必要があるからである。 ~~実際，どの様な見かけになるか想像するのが難しい名前も多い（それゆえ、下に挙げられている）。これらの名前は、 ~sRGB色~空間~全体に均等に分布していないし，内部的に一貫でない（ `gray^swatch `gray$vN より `darkgray^swatch `darkgray$vN の方が明な色であり、 `pink^swatch `pink$vN より `lightpink^swatch `lightpink$vN の方が暗な色である）。一部の名前は（元々は~Indiaからの~red顔料より後に命名された `indianred^swatch `indianred$vN など）、侮辱的（ `offensive^en ）であることが見出された。したがって、それらの利用は`奨励されない^em。 ◎ Note: these color names are standardized here, not because they are good, but because their use and implementation has been widespread for decades and the standard needs to reflect reality. Indeed, it is often hard to imagine what each name will look like (hence the list below); the names are not evenly distributed throughout the sRGB color volume, the names are not even internally consistent ( darkgray is lighter than gray, while lightpink is darker than pink), and some names (such as indianred, which was originally named after a red pigment from India), have been found to be offensive. Thus, their use is not encouraged.

（ 2 つの特別な色~値 `transparent$v, `currentcolor$v は、それ用の節にて特別に定義される。） ◎ (Two special color values, transparent and currentcolor, are specially defined in their own sections.)

次の表tに、定義されるすべての（不透明な）有名~色を挙げる： ◎ The following table defines all of the opaque named colors, by giving equivalent numeric specifications in the other color syntaxes.

色~名の左にある 2 列には、その色による背景~色~styleが，順に［色~名~keyword, ~hex記法］を用いて指定されている。色~名の右にある 2 列には、順に，その色に等価な［ 6 桁~hex表記, その 10 進~表現］を示す。
~style		色~名	値
色~名	~hex	色~名	#RRGGBB	10 進 R, G, B

注記：この色の~listとそれらの定義は、 `SVG 1.1 にて定義される有名~色~list＠~SVG11/types.html#ColorKeywords$ の上位集合である。【 SVG 1.1 に無い色~名は `rebeccapurple$vN のみ。】 ◎ Note: this list of colors and their definitions is a superset of the list of named colors defined by SVG 1.1.

歴史的な理由から、これは~X11色~集合とも呼ばれている。 ◎ For historical reasons, this is also referred to as the X11 color set.

注記： ~X11色~systemの歴史は興味深く， `Alex Sexton^en 氏による優れた公演 “`Peachpuffs and Lemonchiffons＠https://www.youtube.com/watch?v=HmStJQzclHc$en” に要約されている。 ◎ Note: The history of the X11 color system is interesting, and was excellently summarized by Alex Sexton in their talk “Peachpuffs and Lemonchiffons”.

6.2. ~system色

一般に， `system-color$t ~keywordは、［利用者／~browser／~OS ］が`既定の^em色として選んだものを反映する。この理由から、それらは概して，~browserの既定の~stylesheet内で利用される。 ◎ In general, the <system-color> keywords reflect default color choices made by the user, the browser, or the OS. They are typically used in the browser default stylesheet, for this reason.

判読し易さを保守するため、 `system-color$t ~keywordは，要素の`色~scheme$elにも応答する。 ◎ To maintain legibility, the <system-color> keywords also respond to the element color scheme.

例えば，伝統的な `blue^swatch ~blueな~link~textは、 `white^swatch ~whiteな背景~上では判読し易くなるが（~WCAG~contrastは 8.59:1 になり，~AAAに合格する）， `black^swatch ~blackな背景~上では判読し難くなる（~WCAG~contrastは 2.44:1 になり，~AAに合格しない）。暗な~modeにおいては、代わりに，より明な~blue — `#81D9FE^swatch `#81D9FE^v など — が利用されることになろう（~WCAG~contrastは 13.28:1 になり，~AAAに合格する）。 ◎ For example, traditional blue link text is legible on a white background (WCAG contrast 8.59:1, AAA pass) but would not be legible on a black background (WCAG contrast 2.44:1, AA fail). Instead, a lighter blue such as #81D9FE would be used in dark mode (WCAG contrast 13.28:1, AAA pass).

判読し易い~link~text ◎ Legible link text
判読し難い~link~text ◎ Illegible link text
判読し易い~link~text ◎ Legible link text

しかしながら，`強制d色~mode$においては、 ~page上のほとんどの色は，利用者が選んだ制約された~paletteの中へ強制される — `CSS-COLOR-ADJUST-1$r `§ 強制d色~mode用の色~palette＠~CSSCOLORADJUST#forced-color-palettes$ を見よ。各種 `system-color@t ~keywordは，この~paletteを成す色を公開して、 ~pageの残りを，この制約された~paletteに統合できるようにする。 ◎ However, in forced colors mode, most colors on the page are forced into a restricted, user-chosen palette, see CSS Color Adjustment 1 § 5.2 Forced Colors Mode Color Palettes. The <system-color> keywords expose these user-chosen colors so that the rest of the page can integrate with this restricted palette.

`媒体~特能$ `forced-colors$d が `active^v にある下では、作者は — ~page全体にわたる判読し易さと一貫性を確保するため, および［利用者が強制した色，~pageが選んだ色］が~~不釣り合いになるのを避けるため — ［ `§ 強制d色~modeに影響される~prop＠~CSSCOLORADJUST#forced-colors-properties$ `CSS-COLOR-ADJUST-1$r に挙げられるもの］以外の~propには，色~値としていずれかの `system-color$t ~keywordを利用する`ベキ^emである。 ◎ When the forced-colors media feature is active, authors should use the <system-color> keywords as color values in properties other than those listed in CSS Color Adjustment 1 § 3.1 Properties Affected by Forced Colors Mode, to ensure legibility and consistency across the page and avoid an uncoordinated mishmash of user-forced and page-chosen colors.

`system-color$t ~keyword用の値を~browserが与える場合（~OSの既定や利用者が選んだものではなく）、 ~browserは， `合致している［背景, 前景］~pair＠#system-color-pairs$ が最小な~WCAG~AA~contrast以上になることを確保するベキである。しかしながら，（より高／低~contrast用の）利用者-選好は、この要件より優先するモノトスル — ［ ~browser選好, 利用者~stylesheet, ~OSの既定を改めること］のどれで設定されようが。 ◎ When the values of <system-color> keywords come from the browser, (as opposed to being OS defaults or user choices) the browser should ensure that matching foreground/background pairs have a minimum of WCAG AA contrast. However, user preferences (for higher or lower contrast), whether set as a browser preference, a user stylesheet, or by altering the OS defaults, must take precedence over this requirement.

作者はまた，これらの~keywordをいつでも利用して`ヨイ^emが、適切な~contrastを確保するため，利用する色が `合致している［背景, 前景］~pair＠#system-color-pairs$ を成すよう気を付ける`ベキ^emである — 合致しない~pairには、特定0の~contrast関係性は保証されないので（例： `Canvas$vS と `ButtonText$vS ）。 ◎ Authors may also use these keywords at any time, but should be careful to use the colors in matching background-foreground pairs to ensure appropriate contrast, as any particular contrast relationship across non-matching pairs (e.g. Canvas and ButtonText) is not guaranteed.

`system-color$t ~keywordは、次に従って定義される： ◎ The <system-color> keywords are defined as follows:

【各~keywordの前に示される色見本は、利用-中な~UAにおける色（`利用-中な色~scheme＠~CSSCOLORADJUST#used-color-scheme$に依存し得る）。色見本が市松模様に現れるものは、利用-中な~UAが~supportしていない（または本当に透明にされている）。】

`AccentColor^swatch `AccentColor@vS: 目立たせた（ `accented^en な）~UI~controlの背景 ◎ Background of accented user interface controls.
`AccentColorText^swatch `AccentColorText@vS: 目立たせた~UI~controlの~text ◎ Text of accented user interface controls.
`ActiveText^swatch `ActiveText@vS: 作動中な~link内の~text。伝統的には~red。 ◎ Text in active links. For light backgrounds, traditionally red.
`ButtonBorder^swatch `ButtonBorder@vS: ~push~button用の基底~border色。 ◎ The base border color for push buttons.
`ButtonFace^swatch `ButtonFace@vS: ~push~button用の~~表面~背景~色。 ◎ The face background color for push buttons.
`ButtonText^swatch `ButtonText@vS: ~push~button上の~text。 ◎ Text on push buttons.
`Canvas^swatch `Canvas@vS: ［ ~app内容／文書］の背景。 ◎ Background of application content or documents.
`CanvasText^swatch `CanvasText@vS: ［ ~app内容／文書］内の~text。 ◎ Text in application content or documents.
`Field^swatch `Field@vS: 入力-欄の背景。 ◎ Background of input fields.
`FieldText^swatch `FieldText@vS: 入力-欄~内の~text。 ◎ Text in input fields.
`GrayText^swatch `GrayText@vS: 不能化された【~UIなどの】~text （ `gray^swatch ~grayになることが多いが、常にそうなるとは限らない）。 ◎ Disabled text. (Often, but not necessarily, gray.)
`Highlight^swatch `Highlight@vS: 選択されている~textの背景。例えば、 `selection$pe 用の。 ◎ Background of selected text, for example from ::selection.
`HighlightText^swatch `HighlightText@vS: 選択されている~text。 ◎ Text of selected text.
`LinkText^swatch `LinkText@vS: ［作動中でない／訪問-済みでない］~link内の~text。伝統的には~blue。 ◎ Text in non-active, non-visited links. For light backgrounds, traditionally blue.
`Mark^swatch `Mark@vS: 特別に~markされている~textの背景（~HTML `mark$e 要素など）。 ◎ Background of text that has been specially marked (such as by the HTML mark element).
`MarkText^swatch `MarkText@vS: 特別に~markされている~text （~HTML `mark$e 要素など）。 ◎ Text that has been specially marked (such as by the HTML mark element).
`SelectedItem^swatch `SelectedItem@vS: 選択されている~itemの背景。例えば、選択された~checkbox。 ◎ Background of selected items, for example a selected checkbox.
`SelectedItemText^swatch `SelectedItemText@vS: 選択されている~item。 ◎ Text of selected items.
`VisitedText^swatch `VisitedText@vS: 訪問-済み~link内の~text。伝統的には~purple。 ◎ Text in visited links. For light backgrounds, traditionally purple.

注記：他のすべての`~keyword$と同じく、これらの名前は`~ASCII大小無視$である。判読し易くなるよう，ここでは大文字混じりで示されているが。 ◎ Note: As with all other keywords, these names are ASCII case-insensitive. They are shown here with mixed capitalization for legibility.

特定0の~system~UI概念がない~system用には、指定d値は，［存在する，最も近く関係する~system色］値に対応付けられるベキである。 ◎ For systems that do not have a particular system UI concept, the specified value should be mapped to the most closely related system color value that exists.＼

`~system色の~pair法@ として： ◎ ↓

次の表tの各行に挙げるものは，判読し易い［背景, 前景］を形成することが期待される：

背景	前景
`Canvas$vS	`CanvasText$vS
`Canvas$vS	`LinkText$vS
`Canvas$vS	`VisitedText$vS
`Canvas$vS	`ActiveText$vS
`ButtonFace$vS	`ButtonText$vS
`Field$vS	`FieldText$vS
`Mark$vS	`MarkText$vS
`Highlight$vS	`HighlightText$vS
`SelectedItem$vS	`SelectedItemText$vS
`AccentColor$vS	`AccentColorText$vS

◎ The following system color pairings are expected to form legible background-foreground colors: • Canvas background with CanvasText, LinkText, VisitedText, ActiveText foreground. • Canvas background with a ButtonBorder border and adjacent color Canvas • ButtonFace background with ButtonText foreground. • Field background with FieldText foreground. • Mark background with MarkText foreground • ButtonFace or Field background with a ButtonBorder border and adjacent color Canvas' • Highlight background with HighlightText foreground. • SelectedItem background with SelectedItemText foreground. • AccentColor background with AccentColorText foreground.

次の表tの各行に挙げるものは，判読し易い［背景, ~border, 隣接な色］を形成することが期待される：

背景 ~border 隣接な色

`Canvas$vS `ButtonBorder$vS `Canvas$vS
`ButtonFace$vS `ButtonBorder$vS `Canvas$vS
`Field$vS `ButtonBorder$vS `Canvas$vS

【 “隣接な色” は隣接な背景の色と思われる。】
◎ ↑
加えて， `GrayText$vS は、【他の背景~用の~system色と~pairにされたとき】読易くなることが期待される — 背景によっては、 ~contrast比が低くなるが。 ◎ Additionally, GrayText is expected to be readable, though possibly at a lower contrast rating, over any of the backgrounds.

背景	~border	隣接な色
`Canvas$vS	`ButtonBorder$vS	`Canvas$vS
`ButtonFace$vS	`ButtonBorder$vS	`Canvas$vS
`Field$vS	`ButtonBorder$vS	`Canvas$vS

~widgetの`~accent色$の~style法との一貫性を保守するため： ◎ To maintain consistency with widget accent color styling,＼

`AccentColor$vS は、 `強制d色~mode$が可能化されていない限り，その値を `accent-color$p からとる。 ◎ AccentColor takes its value from accent-color, unless Forced Colors Mode is enabled.＼
`AccentColorText$vS は、その値を［ ~widgetの`~accent色$の~style法に述べられるとおりに，前景~色を `AccentColor$vS に対し~contrastすること］からとる。 ◎ AccentColorText takes its value from the contrasting foreground color to AccentColor as is described for widget accent color styling.

例えば、現在~利用-中な~browserにおける，~system色による［背景 / 前景］の組合nは：

`Canvas/CanvasText^sysC
`Canvas/LinkText^sysC
`Canvas/VisitedText^sysC
`Canvas/ActiveText^sysC
`Canvas/GrayText^sysC
`Canvas/CanvasText/ButtonBorder^sysC（隣接な色）（ ~border `ButtonBorder^v, 隣接な色 `Canvas^v ）
`ButtonFace/ButtonText^sysC
`ButtonFace/ButtonText/ButtonBorder^sysC（ ~border `ButtonBorder^v ）
`ButtonFace/GrayText^sysC
`Field/FieldText^sysC
`Field/GrayText^sysC
`Mark/MarkText^sysC
`Mark/GrayText^sysC
`Highlight/HighlightText^sysC
`Highlight/GrayText^sysC
`SelectedItem/SelectedItemText^sysC
`AccentColor/AccentColorText^sysC
`AccentColor/GrayText^sysC

◎ For example, the system color combinations in the browser you are currently using: • Canvas with CanvasText: CanvasText • Canvas with LinkText: LinkText • Canvas with VisitedText: VisitedText • Canvas with ActiveText: ActiveText • Canvas with GrayText: GrayText • Canvas with ButtonBorder and adjacent Canvas: CanvasTextAdjacent • ButtonFace with ButtonText: ButtonText • ButtonFace with ButtonText and ButtonBorder: ButtonText • ButtonFace with GrayText: GrayText • Field with FieldText: FieldText • Field with GrayText: GrayText • Mark with MarkText: MarkText • Mark with GrayText: GrayText • Highlight with HighlightText: HighlightText • Highlight with GrayText: GrayText • SelectedItem with SelectedItemText: SelectedItemText • AccentColor with AccentColorText: AccentColorText • AccentColor with GrayText: GrayText

~CSSの早期の~versionは，追加的な `system-color$t を定義していたが、それ以来，非推奨にされた。それらは、 `§ 非推奨にされた~CSS~system色＠#deprecated-system-colors$ にて文書化されている。 ◎ Earlier versions of CSS defined additional <system-color>s, which have since been deprecated. These are documented in Appendix A: Deprecated CSS System Colors.

注記： `system-color$t は、ある［ ~privacy／~security ］~riskを招く — 詳細は、 `§ ~privacyの考慮点＠#privacy$／ `§ ~securityの考慮点＠#security$ に。 ◎ Note: The <system-color>s incur some privacy and security risk, as detailed in § 22 Privacy Considerations and § 21 Security Considerations.

~UAは，［ ~privacy／~security ］の~risk（指紋収集など）を軽減するため、 ~system色の使用~値~用には，［利用者が選んだ~custom化や~theme法を反映しない，固定的な値］を選出して返すようにしてもヨイ。 ◎ User agents may, to mitigate privacy and security risks such as fingerprinting, elect to return fixed values for the used value of system colors which do not reflect customisation or theming choices made by the user.

6.3. `transparent^v ~keyword

~keyword `transparent@v は、 `透明な黒$を指定する。これは、 `named-color$t の一種である~FN。 ◎ The keyword transparent specifies a transparent black. It is a type of <named-color>.

【~FN と記されているが、 `color$t の構文にて示されるとおり， `named-color^t の一部を成すものではない。】

6.4. `currentcolor^v ~keyword

~keyword `currentcolor@v は、同じ要素~上の `color$p ~propの値を表現する。 `named-color$t と違って、これは，~sRGBには制約されない — どの `color$t も値にとり得る。その`使用~値$は、 `§ その他の色の解決-法＠#resolving-other-colors$により決定される。 ◎ The keyword currentcolor represents value of the color property on the same element. Unlike <named-color>s, it is not restricted to sRGB; the value can be any <color>. Its used values is determined by resolving color values.

`currentcolor$v ~keywordの利用-法を示す単純な例をここに示す： ◎ Here’s a simple example showing how to use the currentcolor keyword:

.foo {
  color: `red^swatch red;
  background-color: `red^swatch currentcolor;
}

これは、次の様に書くことに等価になる： ◎ This is equivalent to writing:

.foo {
  color: `red^swatch red;
  background-color: `red^swatch red;
}

例えば、初期~値が `currentcolor$v である `text-emphasis-color$p ~prop `CSS3-TEXT-DECOR$r は、既定では，その~text色に合致する — `color$p ~propが要素ごとに変化するときでも。 ◎ For example, the text-emphasis-color property [CSS3-TEXT-DECOR], whose initial value is currentcolor, by default matches the text color even as the color property changes across elements.

上の例における圏点の色は、 ~text［ "ある" ／ "~~強勢されたテキスト" ］では `black^v になるが，~text "~~本当に" では `red^v になる。 ◎ In the above example, the emphasis marks are black over the text "Some" and "emphasized text", but red over the text "really".

注記： ~CSSにおける，複数の単語からなる~keywordは、通例的には，その各~成分~単語を~hyphenで分離するが、 `currentcolor$v はそうでない — なぜかと言えば… それは、元々は，~SVGにて、通例的な~CSSの綴りによる~prop値 "`current-color^v" として導入された。それは、 ~XSLTの生成をより容易にするため，（他のすべての~prop, それらの値とともに）［ `呈示~属性$, 属性~値］になった【！？as well as properties】。その後，すべての呈示~属性は、 ~hyphen化から~camelCaseへ変更された — ~hyphenは、 ~DOM【~API】において “負符号” を意味する課題があったので。その結果，~CSS規約にはもはや従わなくなったので、 `すでに^em~CSSの一部を成していたすべての［ ~prop, それらの値］は，~hyphen化に戻すよう変更されてしまった。 `currentcolor^v は、その時点では~CSSの一部を成していなかったので， ~camelCase（ `currentColor^v ）のままであり続けた。後に，~CSSがそれを~~採用した時点で、 ~~大文字化は問われなくなった — ~CSS~keywordは`~ASCII大小無視$なので。 ◎ Note: Multi-word keywords in CSS usually separate their component words with hyphens. currentcolor doesn’t, because (deep breath) it was originally introduced in SVG as a property value, "current-color" with the usual CSS spelling. It (along with all other properties and their values) then became presentation attributes and attribute values, as well as properties, to make generation with XSLT easier. Then all of the presentation attributes were changed from hyphenated to camelCase, because the DOM had an issue with hyphen meaning "minus". But then, they didn’t follow CSS conventions anymore so all the properties and property values that were already part of CSS were changed back to hyphenated! currentcolor was not a part of CSS at that time, so remained camelCased. Only later did CSS pick it up, at which point the capitalization stopped mattering, as CSS keywords are ASCII case-insensitive.

7. HSL 色： `hsl^f, `hsla^f 関数

色を指定するための ~RGB~systemは、 ~machineや~graphic~libraryにとっては簡便な一方で，ヒトにとっては直感的に把握し難いと~~見なされることも多い。例えば、［ある~RGB色から同じ色相のより明な変種を生産する方法］を~~説明することは，容易でない。 ◎ The RGB system for specifying colors, while convenient for machines and graphic libraries, is often regarded as very difficult for humans to gain an intuitive grasp on. It’s not easy to tell, for example, how to alter an RGB color to produce a lighter variant of the same hue.

アリな色~schemeは、他にもいくつかある。そのような一つは，~HSL `HSL$r による色~schemeであり、より直感的に利用でき，かつ ~RGB色に対応付けるのも容易である。 ◎ There are several other color schemes possible. One such is the HSL [HSL] color scheme, which is more intuitive to use, but still maps easily back to RGB colors.

~HSL（~keyword `hsl@v ）色は、［色相, 彩度, 明度（＝ `Hue^en, `Saturation^en, `Lightness^en ）］からなる三組で指定される。［ `hsl$f ／ `hsla$f ］関数の構文は次で与えられる： ◎ HSL colors are specified as a triplet of hue, saturation, and lightness. The syntax of the hsl() and hsla() functions is:

`hsl@f
	= `legacy-hsl-syntax$t
	| `modern-hsl-syntax$t
`hsla@f
	= `legacy-hsla-syntax$t
	| `modern-hsla-syntax$t
`modern-hsl-syntax@t
	= hsl(
		[`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(
		[`hue$t | `none$v]
		[`percentage$t | `number$t | `none$v]
		[`percentage$t | `number$t | `none$v]
		[ / [`alpha-value$t | `none$v] ]? )
`legacy-hsl-syntax@t
	= hsl( `hue$t, `percentage$t, `percentage$t, `alpha-value$t? )
`legacy-hsla-syntax@t
	= hsla( `hue$t, `percentage$t, `percentage$t, `alpha-value$t? )

【関数~名を除いて， `hsl^f と `hsla^f の構文は一致する。】

百分率	S, L に許容される
百分率t基準~範囲（ S, L ）	0% = 0.0, 100% = 100.0
色相が`無力$になる条件（`微小数$）	S ~LTE 0.001

◎ Percentages｜Allowed for S and L Percent reference range｜for S and L: 0% = 0.0, 100% = 100.0 Powerless hue ε｜S <= 0.001

1 個目の引数は、色相~角度を指定する。 ◎ The first argument specifies the hue angle.

~HSL（および~HWB）における角度 `0deg^v は、 ~sRGB原色~redを表現する（ `360deg^v , `720deg^v, 等々も）。他の色相は、それを~~起点に環の周に~~分布する — 例：［ `120deg^v は~sRGB原色~green, `240deg^v は~sRGB原色~blue ］を表現する，等々。 ◎ In HSL (and HWB) the angle 0deg represents sRGB primary red (as does 360deg, 720deg, etc.), and the rest of the hues are spread around the circle, so 120deg represents sRGB primary green, 240deg represents sRGB primary blue, etc.
2 個目の引数は、彩度を指定する。彩度に対する［ `100%^v, `100^v ］は全~彩度な鮮やかな色，［ `0%^v, `0^v ］は無~彩度な~grayである。 ◎ ↓ The next two arguments are the saturation and lightness, respectively.＼ For saturation, 100% or 100 is a fully-saturated, bright color, and 0% or 0 is a fully-unsaturated gray.＼

歴史的な理由により、彩度として `0%^v 未満の値が与えられた場合，［ ~sRGB色へ変換される前，構文解析-時］に `0%^v へ切詰められる。 ◎ ↓ For lightness, 50% or 50 represents the "normal" color, while 100% or 100 is white and 0% or 0 is black. ◎ For historical reasons, if the saturation is less than 0% it is clamped to 0% at parsed-value time, before being converted to an sRGB color.
3 個目の引数は、明度を指定する。明度に対する［ `50%^v, `50^v ］は “通常の” 色を表現する一方で，［ `100%^v, `100^v ］は ~white,［ `0%^v, `0^v ］は ~blackを表現する。 ◎ ↑
4 個目の引数は、色の~alpha成分を指定する — それは、 `rgb$f 関数を成す 4 個目の引数と同じに解釈される。省略-時の既定は `100%^v になる。 ◎ The final argument specifies the alpha component of the color. It’s interpreted identically to the fourth argument of the rgb() function. If omitted, it defaults to 100%.

~HSL色は~sRGBに解決される。 ◎ HSL colors resolve to sRGB.

~HSL色の彩度が［ `0%^v ／ `0^v ］の場合、その色相~成分は`無力$になる。 ◎ If the saturation of an HSL color is 0% or 0, then the hue component is powerless.

例えば、［ ~keyword `red^swatch `red$vN ／ ~hex記法 `#f00^swatch `#f00^v ］と同じ色を表す普通の~redは，~HSLにおいては `hsl(0, 100%, 50%)^swatch `hsl(0, 100%, 50%)^v で表現される。 ◎ For example, an ordinary red, the same color you would see from the keyword red or the hex notation #f00, is represented in HSL as hsl(0deg 100% 50%).

~HSLの~RGBに対する利点は、より直感的なことにある — 求める色を推測しながら調節できるほどに。 ◎ An advantage of HSL over RGB is that it is more intuitive: people can guess at the colors they want, and then tweak.

例えば、次に挙げるどの色も，単に他の 2 つの引数を変えることにより，基本的な “~green” 色相から~~派生したものである： ◎ For example, the following colors can all be generated off of the basic "green" hue, just by varying the other two arguments:

hsl(120deg 100% 50%) `hsl(120,100%,50%)^swatch lime green
hsl(120deg 100% 25%) `hsl(120,100%,25%)^swatch dark green
hsl(120deg 100% 75%) `hsl(120,100%,75%)^swatch light green
hsl(120deg 75% 85%)  `hsl(120,75%,85%)^swatch pastel green

~HSLの`~OkLCh$に対する不利点は、色相~操作が視覚的な明度を変更することに加え，色相が均等に~~分布しないことにある。 ◎ A disadvantage of HSL over OkLCh is that hue manipulation changes the visual lightness, and that hues are not evenly spaced apart.

したがって，~HSLにおいては、 ~sRGB成分~値を操作するよりも，~~調和する一連の色を作成するのは容易になる（色相を同じに保ちつつ，彩度や明度を変えることにより）。しかしながら，明度は単純に~gamma補正された［ ~red, ~green, ~blue ］成分の平均mなので、明度の視覚的な知覚は，色相に応じて変わる。 ◎ It is thus easier in HSL to create sets of matching colors (by keeping the hue the same and varying the saturation and lightness), compared to manipulating the sRGB component values; however, because the lightness is simply the mean of the gamma-corrected red, green and blue components it does not correspond to the visual perception of lightness across hues.

例えば，~HSLにおいては、 `blue^swatch `blue$vN は `hsl(240deg 100% 50%)^v として表現される一方， `yellow^swatch `yellow$vN は `hsl(60deg 100% 50%)^v として表現される。どちらも~HSL明度は 50% だが、明らかに，~yellowは~blueよりずっと明な見かけになる。 ◎ For example, blue is represented in HSL as hsl(240deg 100% 50%) while yellow is hsl(60deg 100% 50%). Both have an HSL Lightness of 50%, but clearly the yellow looks much lighter than the blue.

~OkLChにおいては、 ~sRGB~blueは `blue^swatch `oklch(0.452 0.313 264.1)^v になる一方， ~sRGB~yellowは `yellow^swatch `oklch(0.968 0.211 109.8)^v になる。 ~OkLCh明度 0.452, 0.968 は、この 2 つの色の視覚的な明度を明瞭に反映する。 ◎ In OkLCh, sRGB blue is oklch(0.452 0.313 264.1) while sRGB yellow is oklch(0.968 0.211 109.8). The OkLCh Lightnesses of 0.452 and 0.968 clearly reflect the visual lightnesses of the two colors.

~HSLにおける色相~角度は知覚的に一様でない — 同じ角度~差にある色たちは、ある区域では~~密に現れ，別の区域では~~疎に現れる。 ◎ The hue angle in HSL is not perceptually uniform; colors appear bunched up in some areas and widely spaced in others.

例えば、 ~HSLにおいて同じ色相~差にある 2 つの色~pair：

`hsl(220 100% 50%)^swatch `hsl(220deg 100% 50%)^v と `hsl(250 100% 50%)^swatch `hsl(250deg 100% 50%)^v
`hsl(50 100% 50%)^swatch `hsl(50deg 100% 50%)^v と `hsl(80 100% 50%)^swatch `hsl(80deg 100% 50%)^v

は、前者の見かけはかなり似る一方で，後者の見かけはかなり異なる。

◎ For example, the pair of hues hsl(220deg 100% 50%) and hsl(250deg 100% 50%) have an HSL hue difference of 250-220 = 30deg and look fairly similar, while another pair of colors hsl(50deg 100% 50%) and hsl(80deg 100% 50%), which also have a hue difference of 80-50 = 30deg, look very different.

~OkLChにおいては、前述と同じ色~pairたちは：

`hsl(220 100% 50%)^swatch `oklch(0.533 0.26 262.6)^v と `hsl(250 100% 50%)^swatch `oklch(0.462 0.306 268.9)^v
`hsl(50 100% 50%)^swatch `oklch(0.882 0.181 94.24)^v と `hsl(80 100% 50%)^swatch `oklch(0.91 0.245 129.9)^v

であり、前者の色相~差は `6.3deg^v （ 268.9 ~MINUS 262.6 ）になる一方で，後者の色相~差は `35.66deg^v （ 129.9 ~MINUS 94.24 ）になり、視覚的な色相の違いを正しく反映している。

◎ In OkLCh, the same pair of colors oklch(0.533 0.26 262.6) and oklch(0.462 0.306 268.9) have a hue difference of 268.9 - 262.6 = 6.3deg while the second pair oklch(0.882 0.181 94.24) and oklch(0.91 0.245 129.9) have a hue difference of 129.9 - 94.24 = 35.66deg, correctly reflecting the visual separation of hues.

歴史的な理由により、［ `hsl$f ／ `hsla$f ］関数は，`旧来の色~構文$も~supportする。 ◎ For historical reasons, hsl() and hsla() also support a legacy color syntax.

7.1. ~HSL色から~sRGBへの変換-法

~HSL色から~sRGBへの変換-法は、数学的に単直に行える。ここに，~JSによる変換~algoの見本~実装を与える。これは、色の［ ~red, ~green, ~blue ］成分を表現する 3 個の実数が成す配列を返す — それらは、 ~sRGB色域~内の色~用には，範囲 0 以上 1 以下になる。 ◎ Converting an HSL color to sRGB is straightforward mathematically. Here’s a sample implementation of the conversion algorithm in JavaScript. It returns an array of three numbers representing the red, green, and blue components of the colors, which for colors in the sRGB gamut will be in the range [0, 1].

次の~codeは、負な彩度に対する`構文解析-時^emの切詰ngは，すでに適用されたものと見做す。 ◎ This code assumes that parse-time clamping of negative saturation has already been applied.

/**
 * @param {number} %hue — 色相 ~IN 度数 0..360
 * @param {number} %sat — 彩度 ~IN 基準~範囲 0..100
 * @param {number} %light — 明度 ~IN 基準~範囲 0..100
 * @return {number[]} — ~sRGB成分たちが成す配列, 色域~内の色ならば ~IN 範囲 0..1
 */
◎
/**
 * @param {number} hue - Hue as degrees 0..360
 * @param {number} sat - Saturation in reference range [0,100]
 * @param {number} light - Lightness in reference range [0,100]
 * @return {number[]} Array of sRGB components; in-gamut colors in range [0..1]
 */
function hslToRgb (%hue, %sat, %light) {

    %sat /= 100;
    %light /= 100;

    function f(%n) {
        let %k = (%n + %hue / 30) % 12;
        let %a = %sat * Math.min(%light, 1 - %light);
        return %light - %a * Math.max(-1, Math.min(%k - 3, 9 - %k, 1));
    }

    return [f(0), f(8), f(4)];
}

7.2. ~sRGB色から~HSLへの変換-法

逆~方向における変換は、類似に行われる： ◎ Conversion in the reverse direction proceeds similarly.

~sRGB色域から大きく外れた色は、中間~計算において負な彩度を生産し得るので，特別に~careされる。 ◎ Special care is taken to deal with intermediate negative values of saturation, which can be produced by colors far outside the sRGB gamut.

/**
 * @param {number} %red — ~red成分 ~IN 0..1
 * @param {number} %green — ~green成分 ~IN 0..1
 * @param {number} %blue — ~blue成分 ~IN 0..1
 * @return {number[]} — ~HSL成分~値たちが成す配列：
 *    色相（H） ~IN 度数 0..360,
 *    彩度（S） ~IN 基準~範囲 0..100,
 *    明度（L） ~IN 基準~範囲 0..100
 */
◎
/** 
 * @param {number} red - Red component 0..1
 * @param {number} green - Green component 0..1
 * @param {number} blue - Blue component 0..1
 * @return {number[]} Array of HSL values: Hue as degrees 0..360, Saturation and Lightness in reference range [0,100]
 */
function rgbToHsl (%red, %green, %blue) {
    let %max = Math.max(%red, %green, %blue);
    let %min = Math.min(%red, %green, %blue);
    let [%hue, %sat, %light] = [NaN, 0, (%min + %max)/2];
    let %d = %max - %min;
	let %微小数 = 1 / 100000;   /* 
この~codeにおいては %sat の最大は 1
◎
max Sat is 1, in this code
 */

    if (%d !== 0) {
        %sat = (%light === 0 || %light === 1)
            ? 0
            : (%max - %light) / Math.min(%light, 1 - %light);

        switch (%max) {
            case %red:   %hue = (%green - %blue) / %d + (%green < %blue ? 6 : 0); break;
            case %green: %hue = (%blue - %red) / %d + 2; break;
            case %blue:  %hue = (%red - %green) / %d + 4;
        }

        %hue = %hue * 60;
    }

    /* 
色域から大きく外れた色は、
負な彩度を生産し得る
— その場合、
色相を 180° 回転して，正な彩度を生産させる。
`9222$issue を見よ。
◎
Very out of gamut colors can produce negative saturation
If so, just rotate the hue by 180 and use a positive saturation
see https://github.com/w3c/csswg-drafts/issues/9222
 */
    if (%sat < 0) {
        %hue += 180;
        %sat = Math.abs(%sat);
    }

    if (%hue >= 360) {
        %hue -= 360;
    }

    if (%sat <= %微小数) {
        %hue = NaN;
    }

    return [%hue, %sat * 100, %light * 100];
}

7.3. ~HSL色の例

◎非規範的

【この訳では、原文の［ 30° 間隔で選定された色相~別に分けられた，~HSL色たちが成す表tたち］ではなく，任意の色相から~scriptにより生成して呈示することにする。また、 ~HWB色の例（原文では次節）も同時に示す。（ Canvas ~APIを~supportしない／対応が古い~browserでは~~機能しない。）】

下の図に、特定0の色相の下で表現し得る， ~HSL色と~HWB色（次節）を順に示す。色相はスライダで調節できる。 ~HSL色の彩度は下方向に, 明度は右方向に増大する。 ~HWB色の白度は下方向に, 黒度は右方向に増大する。 ◎ The tables below illustrate a wide range of possible HSL colors. Each table represents one hue, selected at 30° intervals, to illustrate the common "core" hues: red, yellow, green, cyan, blue, magenta, and the six intermediary colors between these. ◎ In each table, the X axis represents the saturation while the Y axis represents the lightness.

`HSL-HWB-color-table^dgm

8. ~HWB色： `hwb^f 関数

~HWB（~keyword `hwb@v ）（ `Hue-Whiteness-Blackness^en の略称） `HWB$r は、 ~sRGB色を指定する別の手法であり，~HSLに類似するが、ヒトにとって更に使い易いことが多い。それは、色を［基底となる色相を与える色, その色に混合される白度, 黒度］で述べる。 ◎ HWB (short for Hue-Whiteness-Blackness) [HWB] is another method of specifying sRGB colors, similar to HSL', but often even easier for humans to work with. It describes colors with a starting hue, then a degree of whiteness and blackness to mix into that base hue.

色~pickerは、その直感性に因り~HWB色~systemに基づくものが多い。 ◎ Many color-pickers are based on the HWB color system, due to its intuitiveness.

~HWB色は、 ~sRGB色に解決される。 ◎ HWB colors resolve to sRGB.

これは、利用者が `<input type="color">^c を作動化したときに示される，ある~browserにおける色~pickerの~screenshot（一部分）である。外縁の環を~clickして色相を選択し、 ~whiteと~blackの相対~量は，内縁の三角形を~clickして選択するようになっている。 ◎ This is a screenshot of Chrome’s color picker, shown when a user activates an <input type="color">. The outer wheel is used to select the hue, then the relative amounts of white and black are selected by clicking on the inner triangle.

`hwb$f 関数の構文は次で与えられる： ◎ The syntax of the hwb() function is:

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

百分率	W, B に許容される
百分率t基準~範囲（ W, B ）	0% = 0.0, 100% = 100.0
色相が`無力$になる条件（`微小数$）	W ~PLUS B ~GTE 99.999

◎ Percentages｜Allowed for W and B Percent reference range｜for W and B: 0% = 0.0, 100% = 100.0 Powerless hue ε｜W + B >= 99.999

1 個目の引数は、色相を指定する — それは、 `hsl$f のそれと同じに定義される。このことは、色相の一様~性など，~HSLと同じ`不利点の難がある＠#disadvantage-hsl$ことを意味する。 ◎ The first argument specifies the hue, and is defined identically to hsl(); this means it suffers the same disadvantages such as hue uniformity.

範囲 0 以上 360 以下の外側にある色相~角度は、この範囲に入るよう正規化される。 ◎ ↓
［ 2 個目／ 3 個目］の引数は、［白度／黒度］を表す［範囲 `0%^v 以上 `100%^v 以下に入る百分率］として，混合する［ ~white／~black ］の量を指定する。 ◎ The second argument specifies the amount of white to mix in, as a percentage from 0% (no whiteness) to 100% (full whiteness). Similarly, the third argument specifies the amount of black to mix in, also from 0% (no blackness) to 100% (full blackness).

例えば， `hwb(150 20% 10%)^swatch `hwb(150 20% 10%)^v は、次と同じ色になる ⇒＃ `hsl(150 77.78% 55%)^v, `rgb(20% 90% 55%)^v ◎ For example, hwb(150 20% 10%) is the same color as hsl(150 77.78% 55%) and rgb(20% 90% 55%).

注記： `hwb$f は、 `Abney^en 効果 `Abney$r — 単色な光源に白色~光が追加されたとき知覚される色相のズレ — を織り込まない。 ◎ Note: hwb() does not account for the Abney effect [Abney] which is the perceived hue shift that occurs when white light is added to a monochromatic light source.

値が範囲~外でも、無効にはならない — ［白度, 黒度【！white and black】］の総和が 100% 以上になる場合でも、以下に述べるとおり，無彩-色を生産することになる。 ◎ Values outside of these ranges are not invalid;＼ ↑ hue angles outside the range [0,360) will be normalized to that range＼ and values of white and black which sum to 100% or greater will produce achromatic colors as described below.

【［白度／黒度］に 0% 未満の値が指定された場合の挙動が述べられていないが、現実の実装では，総和をとる前に 0% に切り上げているようだ。】

結果の色は、概念的には，［選ばれた色相を塗ってから, 百分率で決定される相対~量により~whiteを塗って, ~blackを塗った混合］と捉えることができる。 ◎ The resulting color can be thought of conceptually as a mixture of paint in the chosen hue, white paint, and black paint, with the relative amounts of each determined by the percentages.

~whiteと~blackの和が `100%^v 以上になる場合、無彩-色 — すなわち，~grayの濃淡 — を定義する。それを~sRGBへ変換したときの［ R, G, B ］値は、次で与えられ，互いに一致する。 ⇒ ~white ~DIV ( ~white ~PLUS ~black ) ◎ If the sum white+black is greater than or equal to 100%, it defines an achromatic color, i.e. a shade of gray; when converted to sRGB the R, G and B values are identical and have the value white / (white + black).

例えば，色 `hwb(45 40% 80%)^v は、 ~whiteと~blackを加算した結果が 120 になるので，無彩-色になる。その［ R, G, B ］成分はいずれも 40 ~DIV 40 ~PLUS 80 = 0.33 になり， `33.33% 33.33% 33.33%^rgb `rgb(33.33% 33.33% 33.33%)^v と同じになる。 ◎ For example, in the color hwb(45 40% 80%) white and black adds to 120, so this is an achromatic color whose R, G and B components are 40 / 40 + 80 = 0.33 rgb(33.33% 33.33% 33.33%).

無彩度になる~HWB色は、選ばれた色相についての~hintをもはや包含しなくなり，その色相~成分は`無力$になる。 ◎ Achromatic HWB colors no longer contain any hint of the chosen hue. In this case, the hue component is powerless.
4 個目の引数は、色の~alpha成分を指定する — それは、 `rgb$f 関数を成す 4 個目の引数と同じに解釈される。省略-時の既定は `100%^v になる。 ◎ The fourth argument specifies the alpha component of the color. It’s interpreted identically to the fourth argument of the rgb() function. If omitted, it defaults to 100%.

`hwb$f 関数は、 `旧来の色~構文$を`~supportしない$em。 ◎ There is no Web compatibility issue with hwb, which is new in this level of the specification, and so hwb() does not support a legacy color syntax that separates all of its arguments with commas. Using commas inside hwb() is an error.

8.1. ~HWB色から~sRGBへの変換-法

~HWB色から~sRGBへの変換-法は、単直であり，~HSLから~RGBへ変換する方法に関係する。その~algoは、次の~JS実装で与えられる — ~white, ~black成分は、総和が 100% 以下になるよう，最初に正規化される： ◎ Converting an HWB color to sRGB is straightforward, and related to how one converts HSL to RGB. The following Javascript implementation of the algorithm first normalizes the white and black components, so their sum is no larger than 100%.

/**
 * @param {number} %hue — 色相 ~IN 度数 0..360
 * @param {number} %white — 白度 ~IN 基準~範囲 0..100
 * @param {number} %black — 黒度 ~IN 基準~範囲 0..100
 * @return {number[]} — ~RGB成分~値 ~IN 0..1 たちが成す配列
 */
◎
/**
 * @param {number} hue -  Hue as degrees 0..360
 * @param {number} white -  Whiteness in reference range [0,100]
 * @param {number} black -  Blackness in reference range [0,100]
 * @return {number[]} Array of RGB components 0..1
 */
function hwbToRgb(%hue, %white, %black) {
    %white /= 100;
    %black /= 100;
    if (%white + %black >= 1) {
        let %gray = %white / (%white + %black);
    return [%gray, %gray, %gray];
    }
    let %rgb = hslToRgb(%hue, 100, 50);
    for (let %i = 0; %i < 3; %i++) {
        %rgb[%i] *= (1 - %white - %black);
        %rgb[%i] += %white;
    }
    return %rgb;
}

8.2. ~sRGB色から~HWBへの変換-法

逆~方向における変換は、類似に行われる： ◎ Conversion in the reverse direction proceeds similarly.

/**
 * @param {number} %red — ~red成分 ~IN 0..1
 * @param {number} %green — ~green成分 ~IN 0..1
 * @param {number} %blue — ~blue成分 ~IN 0..1
 * @return {number} — 色相 ~IN 度数 0..360
 */
◎
/**
 * @param {number} red - Red component 0..1
 * @param {number} green - Green component 0..1
 * @param {number} blue - Blue component 0..1
 * @return {number} Hue as degrees 0..360
 */
function rgbToHue(%red, %green, %blue) {
    /* 
`rgbToHsl^c と類似する
— 彩度と明度は計算されず，
彩度は負になっても そのままにされることを除いて。
◎
Similar to rgbToHsl, except that saturation and lightness are not calculated, and potential negative saturation is ignored.
 */
    let %max = Math.max(%red, %green, %blue);
    let %min = Math.min(%red, %green, %blue);
    let %hue = NaN;
    let %d = %max - %min;

    if (%d !== 0) {
        switch (%max) {
            case %red:   %hue = (%green - %blue) / %d + (%green < %blue ? 6 : 0); break;
            case %green: %hue = (%blue - %red) / %d + 2; break;
            case %blue:  %hue = (%red - %green) / %d + 4;
        }

        %hue *= 60;
    }

    if (%hue >= 360) {
        %hue -= 360;
    }

    return %hue;
}

/**
 * @param {number} %red — ~red成分 ~IN 0..1
 * @param {number} %green — ~green成分 ~IN 0..1
 * @param {number} %blue — ~blue成分 ~IN 0..1
 * @return {number[]} — ~HWB成分~値たちが成す配列：
 *    色相（H） ~IN 度数 0..360,
 *    白度（W） ~IN 基準~範囲 0..100,
 *    黒度（B） ~IN 基準~範囲 0..100
 */
◎
/**
 * @param {number} red - Red component 0..1
 * @param {number} green - Green component 0..1
 * @param {number} blue - Blue component 0..1
 * @return {number[]} Array of HWB values: Hue as degrees 0..360, Whiteness and Blackness in reference range [0,100]
 */
function rgbToHwb(%red, %green, %blue) {
    let %微小数 = 1 / 100000;  /* 
100 で乗算されることを織り込む
◎
account for multiply by 100
 */
    var %hue = rgbToHue(%red, %green, %blue);
    var %white = Math.min(%red, %green, %blue);
    var %black = 1 - Math.max(%red, %green, %blue);
    if (%white + %black >= 1 - %微小数) {
        %hue = NaN;
    }
    return([%hue, %white * 100, %black * 100]);
}

8.3. ~HWB色の例

【この節の内容は、 `§ ~HSL色の例＠#hsl-examples$に移譲。】

9. 機器に依存しない色： ~Labと~LCH, ~Oklabと~OkLCh

9.1. ~CIE~Labと~CIE~LCH

◎非規範的

色の物理的な測定は、概して，［ 1976 年に CIE により創出された L*a*b* 色~空間 `CIELAB$r ］として表出され，単に~Labと称される。ある機器から別の機器への色~変換でも，その中間段階に~Labが利用され得る。 ~Labはヒトの視覚経験から導出されており，ヒトが見れる色の全~範囲を表現する。 ◎ Physical measurements of a color are typically expressed in the CIE L*a*b* [CIELAB] color space, created in 1976 by the CIE and commonly referred to simply as Lab. Color conversions from one device to another may also use Lab as an intermediate step. Derived from human vision experiments, Lab represents the entire range of color that humans can see.

~Labは、中心に明度（ L ）軸を伴う矩形な座標系である。この値は，通例的には単位なしの実数で記されるが、 ~CSSの他所との互換性を得るため，その明度 L は百分率として記されてもヨイ。 `100%^v は L 値 100 を意味する — 1.0 ではなく。 L に対する［ `0%^v ／ `0^v ］は漆黒（明るさ皆無）【黒色点に対応する】, ［ `100%^v ／ `100^v ］は拡散~white【白色点に対応する】を表す。 ◎ Lab is a rectangular coordinate system with a central Lightness (L) axis. This value is usually written as a unitless number; for compatibility with the rest of CSS, it may also be written as a percentage. 100% means an L value of 100, not 1.0. L=0% or 0 is deep black (no light at all) while L=100% or 100 is a diffuse white.

有用にするため、［ `50%^v ／ `50^v ］が真中の~grayになり， L における~~一定~増分に対応する視覚的な~~差は L に依らず等しくなるように設計されている — ~Lab色~空間は，`知覚的に一様になる^em~FN ように意図されている。 ◎ Usefully, L=50% or 50 is mid gray, by design, and equal increments in L are evenly spaced visually: the Lab color space is intended to be perceptually uniform.

【~FN ヒトが感じる色の近さ度合いが、どの座標でも一様に，空間における色の距離におよそ比例する（`参考＠https://en.wikipedia.org/wiki/Color_difference#Tolerance$）。】

図左は~CIE~Lab色~空間の L 軸，図右は`輝度$を示す。左右どちらも， 0% から 100% まで 5% 刻みで 21 個の中立な色【！swatch】が示されている。図左では、各~段は視覚的に均等に~~分布する。図右では、各~段は光~energy【強度？】において均等に~~分布するが，視覚的には均等に~~分布しない。 ◎ This figure shows, to the left, the Lightness axis of the CIE Lab color space. Twenty-one neutral swatches are shown (L=0%, L=5%, to L=100%). The steps are equally spaced, visually. To the right, the same number of steps in luminance are equally spaced in light energy but not equally spaced visually.

a, b 軸は色相を伝達する。 a 軸における正な値は~purpleがかった~redになる一方, 負な値は補色の~greenになる。同様に， b 軸における正な値は~yellowになる一方, 負な値は補色である~blue_violetになる。彩度が低い色の a, b 値は小さくなる — すなわち、彩度を下げれば L 軸に近づき，彩度を上げれば L 軸から離れる。 ◎ The a and b axes convey hue; positive values along the a axis are a purplish red while negative values are the complementary color, a green. Similarly, positive values along the b axis are yellow and negative are the complementary blue/violet. Desaturated colors have small values of a and b and are close to the L axis; saturated colors lie far from the L axis.

【光源の】照度は`~D50$~white — 標準~化された色~温度 5000 K による日光の波長分布の下で、全拡散反射板~FN から反射される色 — であり，晴天日の太陽光の色を近似する。 ~D50はまた、 ~ICC色~空間の変換における~profile接続~空間（ `profile connection space^en, 略称 PCS ）の白色点として利用される。これは、［ ~Lab編集を提供する画像~editor ］や［分光光度計や分光放射計などの物理的な測定~機器］が［測定された色を~Labで報告する］ときに利用される白色点である。 ◎ The illuminant is D50 white, a standardized daylight spectrum with a color temperature of 5000K, as reflected by a perfect diffuse reflector; it approximates the color of sunlight on a sunny day. D50 is also the whitepoint used for the profile connection space in ICC color interconversion, the whitepoint used in image editors which offer Lab editing, and the value used by physical measurement devices such as spectrophotometers and spectroradiometers, when they report measured colors in Lab.

【~FN 平たく言えば、 “真白な紙” （鏡ではなく） — この仕様に現れる “拡散~white” は、その色（それが発する光の色）を指すと見受けられる。】

他の白色点を利用して指定された色からの変換~FN は， `有彩色~順応~変形@ （ `chromatic adaptation transform^en ）と呼ばれ、新たな光環境にヒトが順応するときの，ヒトの視覚-~systemにおける変化を~modelにしている。線形~Bradford~algo `ICC$r （元の~Bradford~algo `Bradford-CAT$r の単純~化）は，有彩色~順応~変形の工業規格であり、単純な行列の乗算により，容易に計算できる。 ◎ Conversion from colors specified using other white points is called a chromatic adaptation transform, which models the changes in the human visual system as we adapt to a new lighting condition. The linear Bradford algorithm [ICC] (a simplification of the original Bradford algorithm [Bradford-CAT]) is the industry standard chromatic adaptation transform, and is easy to calculate as it is a simple matrix multiplication.

【~FN すなわち、白色点（波長分布）が異なる光源の下で撮影された画像の色を， “標準な光源”（ ~D50 ）の下で撮影されたかのように補正する（`参考＠https://fujiwaratko.sakura.ne.jp/infosci/colorspace/bradford.html$）。】

~CIE~LCHは、 ~Labと同じ L 軸を利用しつつ，極-座標 ( C, H ) （＝ ( Chroma, Hue ) ＝ ( 色度, 色相 ) ）を利用して，円柱状な座標系を成すようにする。 C は L 軸からの距離であり， H は正な a 軸から正な b 軸へ向かう角度（ ° ）である。 ◎ CIE LCH has the same L axis as Lab, but uses polar coordinates C (chroma) and H (hue), making it a polar, cylindrical coordinate system. C is the geometric distance from the L axis and H is the angle from the positive a axis, towards the positive b axis.

この図は、 ~CIE~Lab色~空間の L=50 平面を示す。 ~CIE~LCH における増分 20 度（°）は、 3 ~levelの色度 20, 40, 60 にて~~円環に表示される。色度 20 の色は，すべて~sRGB色域の内側に収まる一方、色度 40, 60 の色のうち一部は，外側にある。色域から外れたこれらの色は、赤く縁取られた灰色として視覚-化されている。 ◎ This figure shows the L=50 plane of the CIE Lab color space. 20 degree increments in CIE LCH are displayed as circles at three levels of Chroma: 20, 40 and 60. All the 20 Chroma colors fit inside sRGB gamut, some of 40 and 60 Chroma are outside. These out of gamut colors are visualized as grey, with a red warning outer stroke.

【参考：`HCL 色~picker＠http://tristen.ca/hcl-picker/$ （~LCH色~空間~内で~sRGB色域が受持つ範囲の詳細な視覚-化）】

注記：［ ~Lab／~LCH ］における L 軸を~HSLにおける L 軸と混同しないこと。例えば~HSLにおいては、 ~sRGB色~blue（ `#00F^v ）は視覚的には~yellow（ `#FF0^v ）よりずっと暗くなるが，それらの L 値（ 50% ）は同じになる。 ~Labにおいては、このことはずっと明瞭になる — ~sRGB ~blueは `lab(29.567% 68.298 -112.0294)^v になる一方，~sRGB ~yellowは `lab(97.607% -15.753 93.388)^v になる。［ ~Lab／~LCH ］においては、同じ L 値に測定される 2 つの色の視覚的な明度は一致する。 ~HSL, および関係する極-座標~RGB~modelは、 ~LCHが~Labに与えたものに類似する便益を~RGBにも与える試みの下で開発されたが，正確aさは有意に劣る。 ◎ Note: The L axis in Lab and LCH is not to be confused with the L axis in HSL. For example, in HSL, the sRGB colors blue (#00F) and yellow (#FF0) have the same value of L (50%) even though visually, blue is much darker. This is much clearer in Lab: sRGB blue is lab(29.567% 68.298 -112.0294) while sRGB yellow is lab(97.607% -15.753 93.388). In Lab and LCH, if two colors have the same measured L value, they have identical visual lightness. HSL and related polar RGB models were developed in an attempt to give similar usability benefits for RGB that LCH gave to Lab, but are significantly less accurate.

~CIE~Labと~LCHの利用は広く~~普及しているが、問題があることも知られている。特に： ◎ Although the use of CIE Lab and LCH is widespread, it is known to have some problems. In particular:

色相の線形~性 ◎ Hue linearity: ~blue領域（~LCH色相 270° 以上 330° 以下）においては、視覚的な色相が~LCHが予測するものからそれていく。色相は同じで色度は相違する一群の~blueを~plotしたとき、中立な軸からの直線に乗るべきだが，曲線を形成する。別の言い方をするなら、有彩度な~blueの色度が次第に抑制されるに伴い，~purpleが目立ってくる。 ◎ In the blue region (LCH Hue between 270° and 330°), visual hue departs from what LCH predicts. Plotting a set of blues of the same hue and differing Chroma, which should lie on a straight line from the neutral axis, instead form a curve. Put another way, as a saturated blue has it’s Chroma progressively reduced, it becomes noticeably purple.
色相の一様~性 ◎ Hue uniformity: ~LCHにおける色相は、一般に均等に~~分布するが（~HSLや~HWBよりは、ずっと良い），その一様~性は完璧ではない。 ◎ While hues in LCH are in general evenly spaced, (and far better than HSL or HWB), uniformity is not perfect.
高い色度における差の予測過多 ◎ Over-prediction of high Chroma differences: 色度が高くなるほど，色度の変化が目立たなくなる。 ◎ For high Chroma colors, changes in Chroma are less noticeable than for more neutral colors.

これらの欠陥は、例えば，次に影響する ⇒＃均等に~~分布する~gradientの作成／ある色~空間からより狭い色~空間への`色域~対応付け$／ 2 つの色の視覚的な差の算出 ◎ These deficiencies affect, for example, creation of evenly spaced gradients, gamut mapping from one color space to a smaller one, and computation of the visual difference between two colors.

これを補償するため、 2 つの色の視覚的な差（~DeltaE）を予測するための公式は，時を経て正確aさを増してきた（が、その算出も，ずっと複階的になった）。現在の工業規格である公式 ~DeltaE 2000 は、［ ~Lab／~LCH ］の問題の一部を軽減するよう，きちんと働く。見本~実装は、 `§ ~DeltaE 2000＠#color-difference-2000$ にて与えられる。 ◎ To compensate for this, formulae to predict the visual difference between two colors (delta E) have been made more accurate over time (but also, much more complex to compute). The current industry standard formula, delta E 2000, works well to mitigate some of the Lab and LCH problems. A sample implementation is given in § 20.2 ΔE2000.

しかしながら，これは、色相の曲線~性には役立たない。 ◎ This does not help with hue curvature, however.

【 ~DeltaE （ `deltaE^en ／ `delta E^en ／ `ΔE*^en ／ `DeltaE^en ）は、色~差の指標として利用される計算法（または、それによる結果の色~差）を表す接頭辞（`参考＠https://ja.wikipedia.org/wiki/%E8%89%B2%E5%B7%AE$）。この訳では、一律に ~DeltaE と表記する。】

9.2. ~Oklabと~OkLCh

◎非規範的

近年、改善された~Labと同様な空間として， ~Oklab `Oklab$r が開発された。対応する極-座標~形は、 ~OkLChと呼ばれる。それは、［視覚的に類似な色が成す大量な~dataset ］の数量的な最適化により生産され、 ~CIE~LCHに比較して，［色相の線形~性, 色相の一様~性, 色度の一様~性］を改善した。 ◎ Recently, Oklab, an improved Lab-like space has been developed [Oklab]. The corresponding polar form is called OkLCh. It was produced by numerical optimization of a large dataset of visually similar colors, and has improved hue linearity, hue uniformity, and chroma uniformity compared to CIE LCH.

~CIE~Labと同様，中心に明度（ L ）軸があり、通例的には範囲 0 以上 1 以下に入る単位なしの実数で記されるが、 ~CSSの他所との互換性を得るため，その明度 L は百分率として記されてもヨイ。 `100%^v は L 値 1.0 を意味する。 L に対する［ `0%^v ／ `0^v ］は漆黒（明るさ皆無）【黒色点に対応する】, ［ `100%^v ／ `1.0^v ］は拡散~white【白色点に対応する】を表す。 ◎ Like CIE Lab, there is a central lightness L axis which is usually written as a unitless number in the range [0,1]; for compatibility with the rest of CSS, it may be written as a percentage. 100% means an L value of 1.0. L=0% or 0.0 is deep black (no light at all) while L=100% or 1.0 is a diffuse white.

注記：拡散~whiteへ順応されるものと見做す~CIE~Labと違って、 ~Oklabは，定義されている色へ順応されるものと見做す【？】 — それには、それ【色~空間】を~scale不変にすることが意図される。 ◎ Note: Unlike CIE Lab, which assumes adaptation to the diffuse white, Oklab assumes adaptation to the color being defined, which is intended to make it scale invariant.

~CIE~Labと同じく， a, b 軸は色相を伝達する。 a 軸における正な値は~purpleがかった~redになる一方, 負な値は補色の~greenになる。同様に， b 軸における正な値は~yellowになる一方, 負な値は補色である~blue_violetになる。 ◎ As with CIE Lab, the a and b axes convey hue; positive values along the a axis are a purplish red while negative values are the complementary color, a green. Similarly, positive values along the b axis are yellow and negative are the complementary blue/violet.

照度は`~D65$であり、白色点は，ほとんどの~RGB色~空間と同じになる。 ◎ The illuminant is D65, the same white point as most RGB color spaces.

~OkLChは、 ~Oklabと同じ L 軸を利用しつつ，極-座標 ( C, H ) （＝ ( Chroma, Hue ) ＝ ( 色度, 彩度 ) ）を利用する。 ◎ OkLCh has the same L axis as Oklab, but uses polar coordinates C (chroma) and H (hue).

注記：色度が 200 以上の値に達し得る~CIE~LCHと違って、 ~OkLCh色度の範囲は 0.5 あたりまでになる。 ~CIE~LCHと~OkLChの色相~角度は、広く類似するが，一致しない。 ◎ Note: Unlike CIE LCH, where Chroma can reach values of 200 or more, OkLCh Chroma ranges to 0.5 or so. The hue angles between CIE LCH and OkLCh are broadly similar, but not identical.

一定な~CIE~LCH色相による断面は、原色~blue周りの~sRGB色域を示している。目立った~purple化が直ちに判明する。 ◎ A constant CIE LCH hue slice, showing the sRGB gamut around primary blue. A noticeable purpling is immediately evident.

一定な~OkLCh色相による断面は、原色~blue周りの~sRGB色域を示している。視覚的な色相は一定であり続ける。 ◎ A constant OkLCh hue slice, showing the sRGB gamut around primary blue. The visual hue remains constant.

~Oklabは、 ~CIE~Labよりもさらに知覚的に一様なので，色~差は単直な~3D空間における距離（二乗和の平方根）になる。自明ではあるが，見本~実装は、 `§ ~DeltaE~OK＠#color-difference-OK$ にて与えられる。 ◎ Because Oklab is more perceptually uniform than CIE Lab, the color difference is a straightforward distance in 3D space (root sum of squares). Although trivial, a sample implementation is give in § 20.3 ΔEOK.

9.3. ~Lab, ~LCH の指定-法： `lab^f, `lch^f 関数-記法

~CSSでは、［ ~Lab／~LCH ］で直に色を表出することも許容される。 ◎ CSS allows colors to be directly expressed in Lab and LCH.

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

百分率	L, a, b に許容される
百分率t基準~範囲（ L ）	0% = 0.0, 100% = 1.0
百分率t基準~範囲（ a, b ）	−100% = −125, 100% = 125

◎ Percentages｜Allowed for L, a and b Percent reference range｜for L: 0% = 0.0, 100% = 100.0 for a and b: -100% = -125, 100% = 125

~Lab — ~keyword `lab@v — においては： ◎ In Lab,＼

1 個目の引数は、 ~CIE明度（ L ）を指定する。これは、［ `0%^v 以上 `100%^v 以下に入る百分率／ 0 以上 100 以下に入る実数］である。［ `0%^v ／ `0^v ］未満の値は、値に構文解析した時点で `0%^v に切詰めるモノトスル。［ `100%^v ／ `100^v ］を超える値は、値に構文解析した時点で `100%^v に切詰めるモノトスル。 ◎ the first argument specifies the CIE Lightness, L. This is a number between 0% or 0 and 100% or 100 Values less than 0% or 0 must be clamped to 0% at parsed-value time; values greater than 100% or 100 are clamped to 100% at parsed-value time.
2 個目, 3 個目の引数（ a, b ）は、前節に述べたとおり，順に ~Lab色~空間における a 軸, b 軸~~方向の距離を与える。これらの値は、有符号であり，理論的には~~限界は無い（が、実施においては，現実世界の色~用には ±160 を超過しない）。 ◎ The second and third arguments are the distances along the "a" and "b" axes in the Lab color space, as described in the previous section. These values are signed (allow both positive and negative values) and theoretically unbounded (but in practice do not exceed ±160 for real-world colors).
省略可能な 4 個目の引数として，~slashで分離した後に`~alpha成分$を表現する `alpha-value$t もとれる。 ◎ There is an optional fourth <alpha-value> component, separated by a slash, representing the alpha component.

~Lab色の（切詰めた後における）明度が［ `0%^v ／ `100%^v ］の場合、 ~displayへの`色域~対応付け$に因り，［ ~black ／ ~white ］として表示されることになる。 ◎ If the lightness of a Lab color (after clamping) is 0%, or 100% the color will be displayed as black, or white, respectively due to gamut mapping to the display.

`49.06% 13.87% 15.9%^rgb lab(29.2345% 39.3825 20.0664);
`77.61% 36.34% 2.45%^rgb lab(52.2345 40.1645 59.9971);
`61.65% 57.51% 9.28%^rgb lab(60.2345 -5.3654 58.956);
`40.73% 65.12% 22.35%^rgb lab(62.2345% -34.9638 47.7721);
`38.29% 67.27% 93.85%^rgb lab(67.5345 -8.6911 -41.6019);
`50.2% 0% 50.2%^rgb lab(29.69% 44.888% -29.04%);

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

百分率	L, C に許容される
百分率t基準~範囲（ L ）	0% = 0.0, 100% = 1.0
百分率t基準~範囲（ C ）	0% = 0, 100% = 150
色相が`無力$になる条件（`微小数$）	C ~LT 0.0015

◎ Percentages｜Allowed for L and C Percent reference range｜for L: 0% = 0.0, 100% = 100.0 for C: 0% = 0, 100% = 150 Powerless hue ε｜C <= 0.0015

~CIE~LCH— ~keyword `lch@v — においては： ◎ In CIE LCH＼

1 個目の引数は， ~CIE明度（ L ）を指定する — それは、 `lab$f のそれと同じに解釈される。 ◎ the first argument specifies the CIE Lightness L, interpreted identically to the Lightness argument of lab().
2 個目の引数は、色度（ C ）を指定する（概ね， “色の含有量” を表現する）。その有用な最小~値は `0^v である一方、その最大は，理論的には~~限界は無い（が、実施においては， `230^v を超過しない）。供された値が負な場合、値に構文解析した時点で `0^v に切詰められる。 ◎ The second argument is the chroma C, (roughly representing the "amount of color"). Its minimum useful value is 0, while its maximum is theoretically unbounded (but in practice does not exceed 230). If the provided value is negative, it is clamped to 0 at parsed-value time.
3 個目の引数は、色相~角度（ H ）を指定する — それは， `hsl$f の `hue$t 引数と類似に解釈されるが — 知覚的に均等に~~分布するので — 色相と角度は同じ仕方では対応付けられず，次のようになる ⇒＃ `0deg^v は正な a 軸（ `purplish red^en へ向かう）, `90deg^v は正な b 軸（ `mustard yellow^en へ向かう）, `180deg^v は負な a 軸（ `greenish cyan^en へ向かう）, `270deg^v は負な b 軸（ `sky blue^en へ向かう） ◎ The third argument is the hue angle H. It’s interpreted similarly to the <hue> argument of hsl(), but doesn’t map hues to angles in the same way because they are evenly spaced perceptually. Instead, 0deg points along the positive "a" axis (toward purplish red), (as does 360deg, 720deg, etc.); 90deg points along the positive "b" axis (toward mustard yellow), 180deg points along the negative "a" axis (toward greenish cyan), and 270deg points along the negative "b" axis (toward sky blue).
省略可能な 4 個目の引数として，~slashで分離した後に`~alpha成分$を表現する `alpha-value$t もとれる。 ◎ There is an optional fourth <alpha-value> component, separated by a slash, representing the alpha component.

~LCH色の色度が `0%^v の場合、その色相~成分は`無力$になる。 ~LCH色の（切詰めた後における）明度が［ `0%^v ／ `100%^v ］の場合、 ~displayへの`色域~対応付け$に因り，［ ~black ／ ~white ］として表示されることになる。 ◎ If the chroma of an LCH color is 0%, the hue component is powerless. If the lightness of an LCH color (after clamping) is 0%, or 100%, the color will be displayed as black, or white, respectively due to gamut mapping to the display.

`49.06% 13.87% 15.9%^rgb lch(29.2345% 44.2 27);
`77.61% 36.34% 2.45%^rgb lch(52.2345% 72.2 56.2);
`61.65% 57.51% 9.28%^rgb lch(60.2345 59.2 95.2);
`40.73% 65.12% 22.35%^rgb lch(62.2345% 59.2 126.2);
`38.29% 67.27% 93.85%^rgb lch(67.5345% 42.5 258.2);
`50.2% 0% 50.2%^rgb lch(29.69% 45.553% 327.1);

［ `lab$f ／ `lch$f ］関数は、 `旧来の色~構文$を`~supportしない$em。 ◎ There is no Web compatibility issue with lab or lch', which are new in this level of the specification, and so lab() and lch() do not support a legacy color syntax that separates all of their arguments with commas. Using commas inside these functions is an error.

9.4. ~Oklab, ~OkLChの指定-法： `oklab^f, `oklch^f 関数-記法

~CSSでは、［ ~Oklab／~OkLCh ］で直に色を表出することも許容される。 ◎ CSS allows colors to be directly expressed in Oklab and OkLCh.

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

百分率	L, a, b に許容される
百分率t基準~範囲（ L ）	0% = 0.0, 100% = 1.0
百分率t基準~範囲（ a, b ）	−100% = −0.4, 100% = 0.4

◎ Percentages｜Allowed for L, a and b Percent reference range｜for L: 0% = 0.0, 100% = 1.0 for a and b: -100% = -0.4, 100% = 0.4

~Oklab — ~keyword `oklab@v — においては： ◎ In Oklab＼

1 個目の引数は、 ~Oklab明度（ L ）を指定する。これは、［ `0%^v 以上 `100%^v 以下に入る百分率／ 0 以上 1.0 以下に入る実数］である。 ◎ the first argument specifies the Oklab Lightness. This is a number between 0% or 0 and 100% or 1.0.

［ `0%^v ／ `0.0^v ］未満の値は、値に構文解析した時点で `0%^v に切詰めるモノトスル。［ `100%^v ／ `1.0^v ］を超える値は、値に構文解析した時点で `100%^v に切詰めるモノトスル。 ◎ Values less than 0% or 0.0 must be clamped to 0% at parsed-value time; values greater than 100% or 1.0 are clamped to 100% at parsed-value time.
2 個目, 3 個目の引数（ a, b ）は、前節に述べたとおり， ~Oklab色~空間における［ a 軸, b 軸］~~方向の距離を順に指定する。これらの値は、有符号であり，理論的には~~限界は無い（が、実施においては， ±0.5 を超過しない）。 ◎ The second and third arguments are the distances along the "a" and "b" axes in the Oklab color space, as described in the previous section. These values are signed (allow both positive and negative values) and theoretically unbounded (but in practice do not exceed ±0.5).
省略可能な 4 個目の引数として，~slashで分離した後に`~alpha成分$を表現する `alpha-value$t もとれる。 ◎ There is an optional fourth <alpha-value> component, separated by a slash, representing the alpha component.

~Oklab色の明度が［ `0%^v ／ `100%^v ］あるいは［ `0^v ／ `1.0^v ］の場合、 ~displayへの`色域~対応付け$に因り，［ ~black ／ ~white ］として表示されることになる。 ◎ If the lightness of an Oklab color is 0% or 0, or 100% or 1.0, the color will be displayed as black, or white, respectively due to gamut mapping to the display.

`49.06% 13.87% 15.9%^rgb oklab(40.101% 0.1147 0.0453);
`77.61% 36.34% 2.45%^rgb oklab(59.686% 0.1009 0.1192);
`61.65% 57.51% 9.28%^rgb oklab(0.65125 -0.0320 0.1274);
`40.73% 65.12% 22.35%^rgb oklab(66.016% -0.1084 0.1114);
`38.29% 67.27% 93.85%^rgb oklab(72.322% -0.0465 -0.1150);
`50.2% 0% 50.2%^rgb oklab(42.1% 41% -25%);

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

百分率	L, C に許容される
百分率t基準~範囲（ L ）	0% = 0.0, 100% = 1.0
百分率t基準~範囲（ C ）	0% = 0.0, 100% = 0.4
色相が`無力$になる条件（`微小数$）	C ~LT 0.000004

◎ Percentages｜Allowed for L and C Percent reference range｜for L: 0% = 0.0, 100% = 1.0 for C: 0% = 0.0 100% = 0.4 Powerless hue ε｜C <= 0.000004

~OkLCh — ~keyword `oklch@v — においては： ◎ In OkLCh＼

1 個目の引数は、 ~OkLCh明度（ L ）を指定する — それは、 `oklab$f のそれと同じに解釈される。 ◎ the first argument specifies the OkLCh Lightness L, interpreted identically to the Lightness argument of oklab().
2 個目の引数は、色度（ C ）を指定する。その有用な最小~値は `0^v である一方、その最大は，理論的には~~限界は無い（が、実施においては， `0.5^v を超過しない）。供された値が負な場合、値に構文解析した時点で `0^v に切詰められる。 ◎ The second argument is the chroma C. Its minimum useful value is 0, while its maximum is theoretically unbounded (but in practice does not exceed 0.5). If the provided value is negative, it is clamped to 0 at parsed-value time.
3 個目の引数は、色相~角度（ H ）を指定する — それは，［ `hsl$f ／ `lch$f ］の `hue$t 引数と類似に解釈されるが、色相と角度は同じ仕方では対応付けられず，次のようになる ⇒＃ `0deg^v は正な a 軸（ `purplish red^en へ向かう）, `90deg^v は正な b 軸（ `mustard yellow^en へ向かう）, `180deg^v は負な a 軸（ `greenish cyan^en へ向かう）, `270deg^v は負な b 軸（ `sky blue^en へ向かう） ◎ The third argument is the hue angle H. It’s interpreted similarly to the <hue> arguments of hsl() and lch(), but doesn’t map hues to angles in the same way. 0deg points along the positive "a" axis (toward purplish red), (as does 360deg, 720deg, etc.); 90deg points along the positive "b" axis (toward mustard yellow), 180deg points along the negative "a" axis (toward greenish cyan), and 270deg points along the negative "b" axis (toward sky blue).
省略可能な 4 個目の引数として，~slashで分離した後に`~alpha成分$を表現する `alpha-value$t もとれる。 ◎ There is an optional fourth <alpha-value> component, separated by a slash, representing the alpha component.

~OkLCh色の色度が［ `0%^v ／ `0^v ］の場合、その色相~成分は`無力$になる。 ~OkLCh色の明度が［ `0%^v ／ `100%^v ］あるいは［ `0^v ／ `1.0^v ］の場合、 ~displayへの`色域~対応付け$に因り，［ ~black ／ ~white ］として表示されることになる。 ◎ If the chroma of an OkLCh color is 0% or 0, the hue component is powerless. If the lightness of an OkLCh color is 0% or 0, or 100% or 1.0, the color will be displayed as black, or white, respectively due to gamut mapping to the display.

`49.06% 13.87% 15.9%^rgb oklch(40.101% 0.12332 21.555);
`77.61% 36.34% 2.45%^rgb oklch(59.686% 0.15619 49.7694);
`61.65% 57.51% 9.28%^rgb oklch(0.65125 0.13138 104.097);
`40.73% 65.12% 22.35%^rgb oklch(0.66016 0.15546 134.231);
`38.29% 67.27% 93.85%^rgb oklch(72.322% 0.12403 247.996);
`50.2% 0% 50.2%^rgb oklch(42.1% 48.25% 328.4);

［ `oklab$f ／ `oklch$f ］関数は、 `旧来の色~構文$を`~supportしない$em。 ◎ There is no Web compatibility issue with oklab or oklch', which are new in this level of the specification, and so oklab() and oklch() do not support a legacy color syntax that separates all of their arguments with commas. Using commas inside these functions is an error.

9.5. ~Lab色から~LCH色へ／~Oklab色から~OkLCh色への変換-法

極-座標~形への変換は簡単である ⇒＃ %H ~SET `atan2^op( %b, %a )~FN, %C ~SET `sqrt^op( %a ~MUL %a ~PLUS %b ~MUL %b ), %L はそのまま同じ

~FN ただし，［ %C ~LTE `微小数$ ］になる場合、 %H は`欠落~成分$になるとする。

◎ Conversion to the polar form is trivial: • C = sqrt(a^2 + b^2) • if (C > epsilon) H = atan2(b, a) else H is missing • L is the same

%b, %a とも極めて小さい（色度が 0 に近い）とき、結果の色は，視覚的には中立~軸から変化しないが、結果の色相~角度は， %b, %a に対する小さな変化に対し激しく振れる（本質的に~randomになる）。このことは、次を意味する： ◎ For extremely small values of a and b (near-zero Chroma), although the visual color does not change from being on the neutral axis, small changes to the values can result in the reported hue angle swinging about wildly and being essentially random.＼

~CSSにおいては、［ ~LCH／~OkLCh ］へ変換した結果の色相は`無力$になり，`欠落~成分$として扱われる。 ◎ In CSS, this means the hue is powerless, and treated as missing when converted into LCH or OkLCh;＼
~CSS以外の文脈においては、 ~NaNなど，欠落~値として反映されるかもしれない。 ◎ in non-CSS contexts this might be reflected as a missing value, such as NaN.

9.6. ~LCH色から~Lab色へ／~OkLCh色から~Oklab色への変換-法

矩形な形への変換は簡単である ⇒＃ %a ~SET %C ~MUL `cos^op( %H )~FN, %b ~SET %C ~MUL `sin^op( %H )~FN, %L はそのまま同じ ◎ Conversion to the rectangular form is trivial: • If H is missing, a = b = 0 • Otherwise, •• a = C cos(H) •• b = C sin(H) • L is the same

~FN ただし， %H が`欠落~成分$である場合、 %a, %b どちらも 0 になるとする。 ◎ ↑

10. 定義済み色~空間

~CSSは、いくつかの定義済み色~空間を供する — 次に挙げるものなど： ◎ CSS provides several predefined color spaces including＼

`display-p3$v `Display-P3$r — 現在の広-色域~monitorに典型的な，広-色域~空間。 ◎ display-p3 [Display-P3], which is a wide gamut space typical of current wide-gamut monitors,＼
`prophoto-rgb$v — 写真家たちから広く利用されている ◎ prophoto-rgb, widely used by photographers and＼
`rec2020$v `Rec.2020$r — 現実世界のほぼすべての可視~色を表現できる超広-色域~空間であり、 ~~普及している工業規格である。 ◎ rec2020 [Rec.2020], which is a broadcast industry standard, ultra-wide gamut space capable of representing almost all visible real-world colors.

10.1. 定義済み色~空間~内の色の指定-法： `color^f 関数

`color$f 関数は、［特定0の指定した`色~空間$内の色を指定する］ことを許容する（他のほとんどの色~関数が暗黙的に~sRGB色~空間の中で演算するのとは~~対照的に）。その構文は： ◎ The color() function allows a color to be specified in a particular, specified color space (rather than the implicit sRGB color space that most of the other color functions operate in). Its syntax is:

`color@f
	= color( `colorspace-params$t [ / [ `alpha-value$t | `none$v ] ]? )
`colorspace-params@t
	= `predefined-rgb-params$t
	| `xyz-params$t
`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
	| `display-p3-linear$v
	| `a98-rgb$v
	| `prophoto-rgb$v
	| `rec2020$v
`xyz-params@t
	= `xyz-space$t [ `number$t | `percentage$t | `none$v ]{3}
`xyz-space@t
	= `xyz$v
	| `xyz-d50$v
	| `xyz-d65$v

`color$f 関数は、［ある色~空間を明示的に指定する~parameter ］および［その空間~内の色を指定する一連の~parameter ］をとる。 ◎ The color function takes parameters specifying a color, in an explicitly listed color space.

この関数は、［ `無効な色$【！, as described below】, `妥当な色$ ］どちらかを表現する。 ◎ It represents either an invalid color, as described below, or a valid color.

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

`ident$t ⇒ `定義済み色~空間$（ `predefined-rgb$t ）を表す。 ◎ An <ident> denoting one of the predefined color spaces (such as display-p3)＼

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

`ident$t が，存在しない色~空間の名前（すなわち、どの`定義済み色~空間$にも合致しない名前）を与えている場合、当の関数【！この引数】は，`無効な色$を表現する。 ◎ If the <ident> names a non-existent color space (a name that does not match one of the predefined color spaces), this argument represents an invalid color.
当の色~空間がとり得る値（~RGB値／~XYZ値）を成す 3 個の~parameter。 ◎ The three parameter values that the color space takes (RGB or XYZ values).

`色域~外$にある色には、範囲［ 0 以上 1 以下／ 0% 以上 100% 以下］に入らない成分~値がある。それは、 `無効な色$ではなく，中間的な算出~用に維持される — 表示~用には、代わりに，`相対~色計量~意図$を利用して`~CSS色域~対応付け$が施され、 `実際の値$の時点で，この範囲に（~display色~空間~内で）入るようにされる。 ◎ An out of gamut color has component values less than 0 or 0%, or greater than 1 or 100%. These are not invalid, and are retained for intermediate computations; instead, for display, they are css gamut mapped using a relative colorimetric intent which brings the values (in the display color space) within the range 0/0% to 1/100% at actual-value time.
省略可能な，~slashで分離された `alpha-value$t ◎ An optional slash-separated <alpha-value>.

`color$f 関数は、 `旧来の色~構文$を`~supportしない$em。 ◎ There is no Web compatibility issue with color(), which is new in this level of the specification, and so color() does not support a legacy color syntax that separates all of its arguments with commas. Using commas inside this function is an error.

［ `無効な色$／`色域~外$にある色］は、 `表示し得ない@ （ `can’t be displayed^en ）とされ，それ以外の色は `表示し得る@ （ `can be displayed^en ）とされる。 ◎ A color which is either an invalid color or an out of gamut color can’t be displayed. ◎ ↓

`color$f 関数に指定された色 %指定d色が： ◎ ↓

`妥当な色$である場合、当の関数の`実際の値$は：
- %指定d色を`表示し得る$場合 ⇒ %指定d色になる
- 他の場合 ⇒ 表示~用に %指定d色に`~CSS色域~対応付け$を施して導出される色になる
◎ If the specified color can be displayed, (that is, it isn’t an invalid color and isn’t out of gamut) then this is the actual value of the color() function. ◎ If the specified color is a valid color but can’t be displayed, the actual value is derived from the specified color, css gamut mapped for display.
`無効な色$である場合、当の関数の`使用~値$は ⇒ `不透明な黒$になる ◎ If the color is an invalid color, the used value is opaque black.

`rec2020$v 用の`色域~内$にある，ごく鮮やかな~lime色 ⇒ `color(rec2020 0.42053 0.979780 0.00579)^v ◎ This very intense lime color is in-gamut for rec.2020: • color(rec2020 0.42053 0.979780 0.00579);

その色は、 ~LCHにおいては ⇒ `lch(85.9017% 166.116 138.207)^v ◎ in LCH, that color is • lch(85.9017% 166.116 138.207);

その色は、 `display-p3$v においては ⇒ `color(display-p3 -0.350289 1.00707 -0.144209)^v ◎ in display-p3, that color is • color(display-p3 -0.350289 1.00707 -0.144209);

それは、 `display-p3$v 用の`色域~外$にある（~red, ~blueは負であり, ~greenは 1 より大きい）。利用中の~screenが `display-p3$v のとき、その色は ⇒＃ `妥当な色$であり，`rec2020$v 用の`色域~内$にはあるが、（利用中の~display用の）`色域~外$にあるので，`表示し得ない$ ◎ and is out of gamut for display-p3 (red and blue are negative, green is greater than 1). If you have a display-p3 screen, that color is: • valid • in gamut (for rec.2020) • out of gamut (for your display) • and so can’t be displayed

表示-用に利用される色は、 `色域~対応付け$により自動的に生産され，鮮やかさに劣る色になる。 ◎ The color used for display will be a less intense color produced automatically by gamut mapping.

この例は、 `profoto-rgb^v と誤記されており，この（存在しない）空間~内に鮮やかな~greenが供されている ⇒ `color(profoto-rgb 0.4835 0.9167 0.2188)^v

これは`無効な色$になるので、使用~値は`不透明な黒$になる。

◎ This example has a typo! An intense green is provided in profoto-rgb space (which doesn’t exist). This makes it invalid, so the used value is opaque black • color(profoto-rgb 0.4835 0.9167 0.2188)

10.2. 定義済み色~空間 — ~sRGB： `srgb^v ~keyword

以下に定義される定義済み色~空間~sRGBは、 `rgb$f など，旧来の~sRGB色に利用されるものと同じである。 ◎ The sRGB predefined color space defined below is the same as is used for legacy sRGB colors, such as rgb().

~keyword `srgb@v は、 `~sRGB@ 色~空間 `SRGB$r を指示する。この色~空間は： ◎ srgb • The srgb [SRGB] color space＼

色の［ ~red, ~green, ~blue ］成分を表現する 3 個の数量-~parameterを受容する — `色域~内$にあるならば，いずれの成分も範囲 0 以上 1 以下に入る。白色点は`~D65$。 ◎ accepts three numeric parameters, representing the red, green, and blue components of the color. In-gamut colors have all three components in the range [0, 1]. The whitepoint is D65.
観視~条件（ `viewing condition^en ）として， `encoding^en と `typical^en を指定する。 `ICC$r が［色~変換, 最適な観視］用に推奨するものは `encoding^en 条件であり、その値は下の表tに与えられる。 ◎ [SRGB] specifies two viewing conditions, encoding and typical. The [ICC] recommends using the encoding conditions for color conversion and for optimal viewing, which are the values in the table below.
~CSSにおける既定の色~空間であり、旧来の色~関数~すべてから利用される。 ◎ sRGB is the default color space for CSS, used for all the legacy color functions.

この色~空間は、次に挙げる特性を有する： ◎ It has the following characteristics:

~red純色度	x = 0.640, y = 0.330
~green純色度	x = 0.300, y = 0.600
~blue純色度	x = 0.150, y = 0.060
~white純色度	`~D65$
伝達t関数	下の，光に線形な成分を見よ
~white輝度	80.0 cd/m2
~black輝度	0.20 cd/m2
画像~状態~FN	`display-referred^en
百分率	R, G, B に許容される
百分率t基準~範囲（ R, G, B ）	0% = 0.0, 100% = 1.0

◎ ｜x｜y Red chromaticity｜0.640｜0.330 Green chromaticity｜0.300｜0.600 Blue chromaticity｜0.150｜0.060 White chromaticity｜D65 Transfer function｜see below White luminance｜80.0 cd/m2 Black luminance｜0.20 cd/m2 Image state｜display-referred Percentages｜Allowed for R, G and B Percent reference range｜for R,G,B: 0% = 0.0, 100% = 1.0

【~FN 画像~状態（ `image state^en ）は、 ISO 22028-1 に定義される色~空間~propの一つで，色~情報が何を基準に符号化されるかを表すようだ。大雑把には、［ `scene-referred^en, `display-referred^en ］に大別され，［前者は被写体（入力）／後者は~display（出力）］の特性を基準に測定されるらしい。】

~gamma符号化された［ ~red／~green／~blue ］成分 %C に対応する光に線形な成分は：

%符号 ~LET ［ %C ~LT 0 ならば −1 ／ ~ELSE_ 1 ］
%C ~SET %C の絶対値
%結果 ~LET %C に応じて ⇒＃ %C ~LTE 0.04045 ならば %C ~DIV 12.92 ／ ~ELSE_ ( %C ~PLUS 0.055) ~DIV 1.055 ) の 2.4 乗
~RET %符号 ~MUL %結果

◎ let sign = c < 0? -1 : 1; let abs = Math.abs(c); if (abs <= 0.04045) { cl = c / 12.92; } else { cl = sign * (Math.pow((abs + 0.055) / 1.055, 2.4)); } ◎ c is the gamma-encoded red, green or blue component. cl is the corresponding linear-light component.

~OkLChにおける~sRGB色~空間の視覚-化。原色と二次色が示されている。 ◎ Visualization of the sRGB color space in Oklch. The primaries and secondaries are shown.

10.3. 定義済み色~空間 — 光に線形な~sRGB： `srgb-linear^v ~keyword

~keyword `srgb-linear@v は、 `線形~sRGB@ （ `sRGB-linear^en ）色~空間 `SRGB$r を指示する。この色~空間は、その伝達t関数が光に線形である（~gamma符号化は無い）ことを`除いて^em， `srgb$v と同じである。 `色域~内$にあるならば，いずれの成分も範囲 0 以上 1 以下に入る。白色点は`~D65$。 ◎ The sRGB-linear predefined color space is the same as srgb except that the transfer function is linear-light (there is no gamma-encoding). ◎ srgb-linear • The srgb-linear [SRGB] color space accepts three numeric parameters, representing the red, green, and blue components of the color. In-gamut colors have all three components in the range [0, 1]. The whitepoint is D65.

この色~空間は、次に挙げる特性を有する： ◎ It has the following characteristics:

~red純色度	x = 0.640, y = 0.330
~green純色度	x = 0.300, y = 0.600
~blue純色度	x = 0.150, y = 0.060
~white純色度	`~D65$
伝達t関数	元と同じ — 下の，光に線形な成分を見よ
~white輝度	80.0 cd/m2
~black輝度	0.80 cd/m2
画像~状態	`display-referred^en
百分率	R, G, B に許容される
百分率t基準~範囲（ R, G, B ）	0% = 0.0, 100% = 1.0

◎ ｜x｜y Red chromaticity｜0.640｜0.330 Green chromaticity｜0.300｜0.600 Blue chromaticity｜0.150｜0.060 White chromaticity｜D65 Transfer function｜unity, see below White luminance｜80.0 cd/m2 Black luminance｜0.20 cd/m2 Image state｜display-referred Percentages｜Allowed for R, G and B Percent reference range｜for R,G,B: 0% = 0.0, 100% = 1.0

［ ~red／~green／~blue ］成分 %C に対応する光に線形な成分は、 %C と一致する。 ◎ cl = c; ◎ c is the red, green or blue component. cl is the corresponding linear-light component, which is identical.

`banding artifacts^en 【`縞状の帯＠https://en.wikipedia.org/wiki/Colour_banding$】を避けるため、 `srgb-linear$v 用には `srgb$v より`高い精度が要求される＠#predefined-precision-table$。 ◎ To avoid banding artifacts, a higher precision is required for srgb-linear than for srgb.

例えば、次に挙げる色は同じになる： ◎ For example, these are the same color

`69.1% 13.9% 25.9%^rgb color(srgb 0.691 0.139 0.259)
`69.1% 13.9% 25.9%^rgb color(srgb-linear 0.435 0.017 0.055)

10.4. 定義済み色~空間 — ~Display-P3： `display-p3^v ~keyword

~keyword `display-p3@v は、 ~Display-P3色~空間 `Display-P3$r を指示する。この色~空間は： ◎ display-p3 • The display-p3 [Display-P3] color space＼

色の［ ~red, ~green, ~blue ］成分を表現する 3 個の数量-~parameterを受容する — `色域~内$にあるならば，いずれの成分も範囲 0 以上 1 以下に入る。 ◎ accepts three numeric parameters, representing the red, green, and blue components of the color. In-gamut colors have all three components in the range [0, 1].＼
利用する原色の純色度は `DCI-P3$r と同じである一方、白色点は~sRGBと同じ`~D65$, 伝達t曲線も~sRGBと同じである。 ◎ It uses the same primary chromaticities as [DCI-P3], but with a D65 whitepoint, and the same transfer curve as sRGB.

現代の~display（~TV, ~laptop, ~phoneも含む）の~screenは、すべてに近い `display-p3$v 色域を表示-可能である。 ◎ Modern displays, TVs, laptop screens and phone screens are able to display all, or nearly all, of the display-p3 gamut.

この色~空間は、次に挙げる特性を有する： ◎ It has the following characteristics:

~red純色度	x = 0.680, y = 0.320
~green純色度	x = 0.265, y = 0.690
~blue純色度	x = 0.150, y = 0.060
~white純色度	`~D65$
伝達t関数	`srgb$v と同じ
~white輝度	80.0 cd/m2
~black輝度	0.80 cd/m2
画像~状態	`display-referred^en
百分率	R, G, B に許容される
百分率t基準~範囲（ R, G, B ）	0% = 0.0, 100% = 1.0

◎ ｜x｜y Red chromaticity｜0.680｜0.320 Green chromaticity｜0.265｜0.690 Blue chromaticity｜0.150｜0.060 White chromaticity｜D65 Transfer function｜same as srgb White luminance｜80.0 cd/m2 Black luminance｜0.80 cd/m2 Image state｜display-referred Percentages｜Allowed for R, G and B Percent reference range｜for R,G,B: 0% = 0.0, 100% = 1.0

~OkLChにおける~P3色~空間の視覚-化。原色と二次色が示されている（が、~sRGB内であり，正しい色ではない）。比較~用に，~sRGBの原色と二次色も破線で示されている。 ~P3原色の色度は、もっと高い。 ◎ Visualization of the P3 color space in Oklch. The primaries and secondaries are shown (but in sRGB, not in the correct colors). For comparison, the sRGB primaries and secondaries are also shown, as dashed circles. P3 primaries have higher Chroma.

10.5. 定義済み色~空間 — 光に線形な~Display-P3： `display-p3-linear^v ~keyword

~keyword `display-p3-linear@v は、光に線形な~Display-P3色~空間を指示する。この色~空間は、その伝達t関数が光に線形である（~gamma符号化は無い）ことを`除いて^em， `display-p3$v と同じである。 ◎ display-p3-linear ◎ The display-p3-linear predefined color space is the same as display-p3 except that the transfer function is linear-light (there is no gamma-encoding).

この色~空間は、次に挙げる特性を有する： ◎ It has the following characteristics:

~red純色度	x = 0.680, y = 0.320
~green純色度	x = 0.265, y = 0.690
~blue純色度	x = 0.150, y = 0.060
~white純色度	`~D65$
伝達t関数	元と同じ — 下の，光に線形な成分を見よ
~white輝度	80.0 cd/m2
~black輝度	0.80 cd/m2
画像~状態	`display-referred^en
百分率	R, G, B に許容される
百分率t基準~範囲（ R, G, B ）	0% = 0.0, 100% = 1.0

◎ ｜x｜y Red chromaticity｜0.680｜0.320 Green chromaticity｜0.265｜0.690 Blue chromaticity｜0.150｜0.060 White chromaticity｜`~D65$ Transfer function｜unity, see below White luminance｜80.0 cd/m2 Black luminance｜0.80 cd/m2 Image state｜display-referred Percentages｜Allowed for R, G and B Percent reference range｜for R,G,B: 0% = 0.0, 100% = 1.0

`banding artifacts^en 【`縞状の帯＠https://en.wikipedia.org/wiki/Colour_banding$】を避けるため、 `display-p3-linear$v 用には `display-p3$v より`高い精度が要求される＠#predefined-precision-table$。 ◎ To avoid banding artifacts, a higher precision is required for display-p3-linear than for display-p3.

例えば、次に挙げる色は同じになる： ◎ For example, these are the same color

`64.55% 2.065% 26.03%^rgb color(display-p3 0.591 0.123 0.264)
`64.55% 2.065% 26.03%^rgb color(display-p3-linear 0.3081 0.014 0.0567)

10.6. 定義済み色~空間 — ~A98~RGB： `a98-rgb^v ~keyword

~keyword `a98-rgb@v は、 ~A98【 Adobe® RGB (1998) 】色~空間を指示する。この色~空間は： ◎ a98-rgb • The a98-rgb color space＼

色の［ ~red, ~green, ~blue ］成分を表現する 3 個の数量-~parameterを受容する — `色域~内$にあるならば，いずれの成分も範囲 0 以上 1 以下に入る。 ◎ accepts three numeric parameters, representing the red, green, and blue components of the color. In-gamut colors have all three components in the range [0, 1].＼
その伝達t曲線は、 ( 1 ~DIV 2.2 ) に近い（が正確には異なる）~gammaを伴う~gamma符号化【！~gamma関数】である。 ◎ The transfer curve is a gamma function, close to but not exactly 1/2.2.

この色~空間は、次に挙げる特性を有する： ◎ It has the following characteristics:

~red純色度	x = 0.6400, y = 0.3300
~green純色度	x = 0.2100, y = 0.7100
~blue純色度	x = 0.1500, y = 0.0600
~white純色度	`~D65$
伝達t関数	【~gamma】 256 ~DIV 563
~white輝度	160.0 cd/m2
~black輝度	0.5557 cd/m2
画像~状態	`display-referred^en
百分率	R, G, B に許容される
百分率t基準~範囲（ R, G, B ）	0% = 0.0, 100% = 1.0

◎ ｜x｜y Red chromaticity｜0.6400｜0.3300 Green chromaticity｜0.2100｜0.7100 Blue chromaticity｜0.1500｜0.0600 White chromaticity｜D65 Transfer function｜256/563 White luminance｜160.0 cd/m2 Black luminance｜0.5557 cd/m2 Image state｜display-referred Percentages｜Allowed for R, G and B Percent reference range｜for R,G,B: 0% = 0.0, 100% = 1.0

~OkLChにおける~A98色~空間 `a98-rgb$v の視覚-化。原色と二次色が示されている（が、~sRGB内であり，正しい色ではない）。比較~用に，~sRGBの原色と二次色も破線で示されている。 `a98-rgb^v 原色の色度は、他より，とりわけ［ ~yellow, ~green, ~cyan ］において高い。 ◎ Visualization of the A98 color space in Oklch. The primaries and secondaries are shown (but in sRGB, not in the correct colors). For comparison, the sRGB primaries and secondaries are also shown, as dashed circles. a98 primaries have higher Chroma, especially the yellow, green and cyan.

10.7. 定義済み色~空間 — ~ProPhoto~RGB： `prophoto-rgb^v ~keyword

~keyword `prophoto-rgb@v は、 ~ProPhoto~RGB色~空間を指示する。この色~空間は： ◎ prophoto-rgb • The prophoto-rgb color space＼

色の［ ~red, ~green, ~blue ］成分を表現する 3 個の数量-~parameterを受容する — `色域~内$にあるならば，いずれの成分も範囲 0 以上 1 以下に入る。 ◎ accepts three numeric parameters, representing the red, green, and blue components of the color. In-gamut colors have all three components in the range [0, 1].＼
伝達t曲線は、 ~gamma ( 1 ~DIV 1.8 ) を伴う~gamma符号化【！~gamma関数】である — が，~blackにごく近い所では線形になる。 ◎ The transfer curve is a gamma function with a value of 1/1.8, and a small linear portion near black.＼
白色点は、 ~CIE~Labと同じ`~D50$である。したがって，~CIE~Labへの変換は、 `有彩色~順応$段を要さない。 ◎ The white point is D50, the same as is used by CIE Lab. Thus, conversion to CIE Lab does not require the chromatic adaptation step.
物理的には実現-不能な，超~彩度な原色を利用する。それらは、［色調の操作-時に色相のズレを最小限にする］ように選ばれている。 ◎ The ProPhoto RGB space uses hyper-saturated, non physically realizable primaries. These were chosen to allow a wide color gamut and in particular, to minimize hue shifts under tonal manipulation.＼
写真-画像の~archive用~version用の広-色域な色~空間として， ~digital写真撮影に利用されることが多く、 ~CSSにおいて［そのような画像~内の色に合致する色を同じ~RGB値で指定する］ことを許容する。 ◎ It is often used in digital photography as a wide gamut color space for the archival version of photographic images.＼ The prophoto-rgb color space allows CSS to specify colors that will match colors in such images having the same RGB values.
元々は Kodak により開発され， `Wolfe$r にて述べられ， ISO により `ROMM$r, `ROMM-RGB$r として標準~化された。 ◎ The ProPhoto RGB space was originally developed by Kodak and is described in [Wolfe]. It was standardized by ISO as [ROMM],[ROMM-RGB].
その~white輝度は、範囲として与えられ，その 0.5% 〜 1.0% が観視~flare~FN（したがって，~black輝度）になる。【~FN 元の画像に無かった光（~monitor表面の反射など）— 観視~条件に左右される。】 ◎ The white luminance is given as a range, and the viewing flare (and thus, the black luminance) is 0.5% to 1.0% of this.

この色~空間は、次に挙げる特性を有する： ◎ It has the following characteristics:

~red純色度	x = 0.734699, y = 0.265301
~green純色度	x = 0.159597, y = 0.840403
~blue純色度	x = 0.036598, y = 0.000105
~white純色度	`~D50$
伝達t関数	下（光に線形な成分）を見よ
~white輝度	160.0 〜 640.0 cd/m2
~black輝度	~textを見よ
画像~状態	`display-referred^en
百分率	R, G, B に許容される
百分率t基準~範囲（ R, G, B ）	0% = 0.0, 100% = 1.0

◎ ｜x｜y Red chromaticity｜0.734699｜0.265301 Green chromaticity｜0.159597｜0.840403 Blue chromaticity｜0.036598｜0.000105 White chromaticity｜D50 Transfer function｜see below White luminance｜160.0 to 640.0 cd/m2 Black luminance｜See text Image state｜display-referred Percentages｜Allowed for R, G and B Percent reference range｜for R,G,B: 0% = 0.0, 100% = 1.0

~gamma符号化された［ ~red／~green／~blue ］成分 %C に対応する光に線形な成分は：

%符号 ~LET ［ %C ~LT 0 ならば −1 ／ ~ELSE_ 1 ］
%C ~SET %C の絶対値
%結果 ~LET %C に応じて ⇒＃ %C ~LTE 16 ~DIV 512 ならば %C ~DIV 16 ／ ~ELSE_ %C の 1.8 乗
~RET %符号 ~MUL %結果

◎ const E = 16/512; let sign = c < 0? -1 : 1; let abs = Math.abs(c); if (abs <= E) { cl = c / 16; } else { cl = sign * Math.pow(c, 1.8); } ◎ c is the gamma-encoded red, green or blue component. cl is the corresponding linear-light component.

~OkLChにおける `protphoto-rgb^v 色~空間の視覚-化。原色と二次色が示されている（が、~sRGB内であり，正しい色ではない）。比較~用に，~sRGBの原色と二次色も破線で示されている。 `prophoto-rgb^v の原色と二次色の色度は，ずっと高く、この超広-色域を成すかなりの部分は，物理的に実現-可能な色には対応しない。 ◎ Visualization of the prophoto-rgb color space in Oklch. The primaries and secondaries are shown (but in sRGB, not in the correct colors). For comparison, the sRGB primaries and secondaries are also shown, as dashed circles. prophoto-rgb primaries and secondaries have much higher Chroma, but much of this ultrawide gamut does not correspond to physically realizable colors.

10.8. 定義済み色~空間 — ~Rec2020： `rec2020^v ~keyword

~keyword `rec2020@v は、 `ITU Reference 2020^cite `Rec.2020$r 色~空間を指示する。この色~空間は： ◎ rec2020 • The rec2020 [Rec.2020] color space＼

色の［ ~red, ~green, ~blue ］成分を表現する 3 個の数量-~parameterを受容する — `色域~内$にあるならば，いずれの成分も範囲 0 以上 1 以下に入る（動画~用語における “`full-range^en【全-範囲】” ）。 ◎ accepts three numeric parameters, representing the red, green, and blue components of the color. In-gamut colors have all three components in the range [0, 1], ("full-range", in video terminology).＼
`Ultra High Definition, 4k and 8k television^en 【いわゆる~~超高精細テレビ】用に利用される。 ◎ ITU Reference 2020 is used for Ultra High Definition, 4k and 8k television.
その原色は，物理的に実現-可能ではあるが、それらは分光軌跡（ `the spectral locus^en 【 “可視色度図” のへり】）の近くにあり，困難さを伴う。 ◎ The primaries are physically realizable, but with difficulty as they lie very close to the spectral locus.
現在の~displayは、その全部的な色域を再現-不能である — 時を経て~displayが向上するに伴い，再現-可能な~~範囲は増大するものと期待されるが。 ◎ Current displays are unable to reproduce the full gamut of rec2020. Coverage is expected to increase over time as displays improve.

この色~空間は、次に挙げる特性を有する： ◎ It has the following characteristics:

~red純色度	x = 0.708, y = 0.292
~green純色度	x = 0.170, y = 0.797
~blue純色度	x = 0.131, y = 0.046
~white純色度	`~D65$
伝達t関数	~gamma 2.40 `REC_BT.1886$r
画像~状態	`display-referred^en
百分率	R, G, B に許容される
百分率t基準~範囲（ R, G, B ）	0% = 0.0, 100% = 1.0

◎ ｜x｜y Red chromaticity｜0.708｜0.292 Green chromaticity｜0.170｜0.797 Blue chromaticity｜0.131｜0.046 White chromaticity｜D65 Transfer function｜gamma 2.40, from [REC_BT.1886] Image state｜display-referred Percentages｜Allowed for R, G and B Percent reference range｜for R,G,B: 0% = 0.0, 100% = 1.0

~OkLChにおける `rec2020$v 色~空間の視覚-化。原色と二次色が示されている（が、~sRGB内であり，正しい色ではない）。比較~用に，~sRGBの原色と二次色も破線で示されている。 `rec2020$v 原色の色度は、ずっと高い。 ◎ Visualization of the rec2020 color space in Oklch. The primaries and secondaries are shown (but in sRGB, not in the correct colors). For comparison, the sRGB primaries and secondaries are also shown, as dashed circles. rec2020 primaries have much higher Chroma.

10.9. 定義済み色~空間 — ~CIE~XYZ： `xyz-d50^v, `xyz-d65^v, `xyz^v ~keyword

~keyword［ `xyz-d50@v ／ `xyz-d65@v ／ `xyz@v ］は、 ~CIE~XYZ `COLORIMETRY$r 色~空間を指示する。この色~空間は、［ X, Y, Z ］値を表現している 3 個の数量-~parameterを受容する — 拡散~whiteの`輝度$（ Y ）が 1.0 になるよう拡縮され、必要yなら，基準~whiteへの`有彩色~順応~変形$も適用する下で。 ◎ xyz-d50 xyz-d65 xyz • The xyz color space accepts three numeric parameters, representing the X,Y and Z values. It represents the CIE XYZ [COLORIMETRY] color space, scaled such that diffuse white has a luminance (Y) of 1.0. and, if necessary, chromatically adapted to the reference white.

`xyz$v は `xyz-d65$v の別名であり，［ `xyz-d50$v ／ `xyz-d65$v ］用の基準~whiteは［ `~D50$／`~D65$ ］である。 ◎ The reference white for xyz-d50 is D50, while the reference white for xyz-d65 and xyz is D65.

［ 1.0 ／ 100% ］より大きい値も許容される — それらは、切詰めないモノトスル。 `輝度$（ Y ）が 1.0 を超える色は、拡散~whiteより明るい色を表現する。［ 0 ／ 0% ］未満の値は、 ~~普通はないが，`有彩色~順応$の結果として生じ得る — それらも、同様に切詰めないモノトスル。 ◎ Values greater than 1.0/100% are allowed and must not be clamped; colors where Y is greater than 1.0 represent colors brighter than diffuse white. Values less than 0/0% are uncommon, but can occur as a result of chromatic adaptation, and likewise must not be clamped.

この色~空間は、次に挙げる特性を有する： ◎ It has the following characteristics:

百分率	X, Y, Z に許容される
百分率t基準~範囲（ X, Y, Z ）	0% = 0.0, 100% = 1.0

◎ Percentages｜Allowed for X,Y,Z Percent reference range｜for X,Y,Z: 0% = 0.0, 100% = 1.0

次に挙げるものは、正確に等価 `#7654CD^swatch になる： ◎ These are exactly equivalent:

#7654CD
rgb(46.27% 32.94% 80.39%)
lab(44.36% 36.05 -58.99)
color(xyz-d50 0.2005 0.14089 0.4472)
color(xyz-d65 0.21661 0.14602 0.59452)

次に挙げるものは、正確に等価 `white^swatch になり，~whiteを表現する： ◎ These colors are exactly equivalent, and represent white:

#FFFFFF
color(xyz-d50 0.9643 1 0.8251)
color(xyz-d65 0.9505 1 1.089)

10.10. 定義済み色~空間から~Lab／~Oklabへの変換-法

どの［定義済み~RGB色~空間］も、 ~Labへの変換には，何~段か要する — 最初の段を除くすべては、線形な計算であり，実施においては結合できるが： ◎ For all predefined RGB color spaces, conversion to Lab requires several steps, although in practice all but the first step are linear calculations and can be combined.

~gamma符号化された~RGBから光に線形な~RGBへ変換する（~gamma符号化を外す） ◎ Convert from gamma-encoded RGB to linear-light RGB (undo gamma encoding)
線形~RGBから~CIE~XYZへ変換する ◎ Convert from linear RGB to CIE XYZ
必要なら、線形~Bradford変形で，（［ `srgb$v【！sRGB】／ `display-p3$v ／ `a98-rgb$v ／ `rec2020$v ］が利用する）`~D65$白色点から（~Labが利用する）`~D50$白色点へ変換する — `prophoto-rgb$v は、すでに~D50白色点である【ので，この段は不要になる】 ◎ If needed, convert from a D65 whitepoint (used by sRGB, display-p3, a98-rgb and rec2020) to the D50 whitepoint used in Lab, with the linear Bradford transform. prophoto-rgb already has a D50 whitepoint.
（ ~D50に順応された）~XYZから~Labへ変換する ◎ Convert D50-adapted XYZ to Lab

~Oklabへの変換は類似するが、 `有彩色~順応$段が必要になるのは `prophoto-rgb$v 用に限られる： ◎ Conversion to Oklab is similar, but the chromatic adaptation step is only needed for prophoto-rgb.

~gamma符号化された~RGBから光に線形な~RGBへ変換する（~gamma符号化を外す） ◎ Convert from gamma-encoded RGB to linear-light RGB (undo gamma encoding)
線形~RGBから~CIE~XYZへ変換する ◎ Convert from linear RGB to CIE XYZ
必要なら、線形~Bradford変形で，（ `prophoto-rgb$v が利用する）`~D50$白色点から（ ~Oklabが利用する）`~D65$白色点へ変換する ◎ If needed, convert from a D50 whitepoint (used by prophoto-rgb) to the D65 whitepoint used in Oklab, with the linear Bradford transform.
（~D65に順応された）~XYZから~Oklabへ変換する ◎ Convert D65-adapted XYZ to Oklab

`§ 色~変換~codeの見本$に，この変換~用の見本~JS~codeがある。 ◎ There is sample JavaScript code for these conversions in § 19 Sample code for Color Conversions.

10.11. ~Lab／~Oklabから定義済み~RGB色~空間への変換-法

~Labから［ `display-p3$v ／ `rec2020$v ］の様な定義済み色~空間への変換もまた、何~段か要する — これも，最後の段を除くすべては、線形な計算であり，実施においては結合できるが： ◎ Conversion from Lab to predefined spaces like display-p3 or rec2020 also requires multiple steps, and again in practice all but the last step are linear calculations and can be combined.

（ ~D50に順応された）~Labから~XYZへ変換する ◎ Convert Lab to (D50-adapted) XYZ
必要なら、線形~Bradford変形で，（ ~Labが利用する）`~D50$白色点から（ ~sRGBその他のほとんどの~RGB空間が利用する）`~D65$白色点へ変換する — `prophoto-rgb$v には、この段は要求されない ◎ If needed, convert from a D50 whitepoint (used by Lab) to the D65 whitepoint used in sRGB and most other RGB spaces, with the linear Bradford transform. prophoto-rgb' does not require this step.
（ ~D65に順応された）~CIE~XYZから線形~RGBへ変換する ◎ Convert from (D65-adapted) CIE XYZ to linear RGB
光に線形な~RGBから~RGBへ変換する（~gamma符号化を施す） ◎ Convert from linear-light RGB to RGB (do gamma encoding)

~Oklabからの変換は類似するが、 `有彩色~順応$段が必要になるのは `prophoto-rgb$v 用に限られる： ◎ Conversion from Oklab is similar, but the chromatic adaptation step is only needed for prophoto-rgb.

~Oklabから（~D65に順応された）~XYZへ変換する ◎ Convert Oklab to (D65-adapted) XYZ
必要なら、線形~Bradford変形で，（~Oklabが利用する）`~D65$白色点から（ `prophoto-rgb$v が利用する）`~D50$白色点へ変換する ◎ If needed, convert from a D65 whitepoint (used by Oklab) to the D50 whitepoint used in prophoto-rgb, with the linear Bradford transform.
（ ~D65に順応された）~CIE~XYZから線形~RGBへ変換する ◎ Convert from (D65-adapted) CIE XYZ to linear RGB
光に線形な~RGBから~RGBへ変換する（~gamma符号化を施す） ◎ Convert from linear-light RGB to RGB (do gamma encoding)

`§ 色~変換~codeの見本$に，この変換~用の見本~JS~codeがある。 ◎ There is sample JavaScript code for these conversions in § 19 Sample code for Color Conversions.

実装は、［変換源, 行先］両`色域~内$にある色に対し同じ結果が得られる限り，この手続きを他の仕方で実装してもヨイ（例えば、描画~意図に`相対~色計量~意図$を伴う~ICC~profileを利用して）。 ◎ Implementations may choose to implement these steps in some other way (for example, using an ICC profile with relative colorimetric rendering intent) provided the results are the same for colors inside both the source and destination gamuts.

10.12. 定義済み~RGB色~空間どうしの変換-法

定義済み~RGB色~空間（ `src^em ）から別の定義済み~RGB色~空間（ `dest^em ）への変換には、何~段か要する — うち一つの段は、白色点が相違するときに限り，必要になる： ◎ Conversion from one predefined RGB color space to another requires multiple steps, one of which is only needed when the whitepoints differ. To convert from src to dest:

~gamma符号化された~RGB（ `src^em ）から光に線形な~RGB（ `src^em ）へ変換する（~gamma符号化を外す） ◎ Convert from gamma-encoded srcRGB to linear-light srcRGB (undo gamma encoding)
光に線形な~RGB（ `src^em ）から~CIE~XYZへ変換する ◎ Convert from linear srcRGB to CIE XYZ
`src^em と `dest^em の白色点は異なる場合 ⇒ 線形~Bradford変形で，~XYZ値を白色点（ `src^em ）から白色点（ `dest^em ）へ変換する ◎ If src and dest have different whitepoints, convert the XYZ value from srcWhite to destWhite with the linear Bradford transform.
~CIE~XYZから光に線形な~RGB（ `dest^em ）へ変換する ◎ Convert from CIE XYZ to linear destRGB
光に線形な~RGB（ `dest^em ）から~RGB（ `dest^em ）へ変換する（~gamma符号化を施す） ◎ Convert from linear-light destRGB to destRGB (do gamma encoding)

`§ 色~変換~codeの見本$にて，定義済み~RGB色~空間~用のこの変換~用の見本~JS~codeがある。 ◎ There is sample JavaScript code for this conversion for the predefined RGB color spaces, in § 19 Sample code for Color Conversions.

10.13. 単純~alpha組成-法

実装は、色を描くときには，~alphaを［ `Compositing$r `§ 単純~alpha組成-法＠~COMPOSITING#simplealphacompositing$ における規則］に則って取扱うモノトスル。 ◎ When drawing, implementations must handle alpha according to the rules in Section 5.1 Simple alpha compositing of [Compositing].

11. 色の変換-法

所与の色~空間~内の色は、別の色~空間へ変換できる — 結果の色は、［色域~対応付けを施さない］かつ［どちらの色~空間も【出力~機器の】`色域~外$にある色を表現できる］ならば~FN1，元と同じ~FN2［見かけ, 感覚］を表現することになる。（~FN1 このことは、 ~RGB空間においては［伝達t関数は、拡張された範囲にまで定義される］ことを意味する。）（~FN2 数量的な精度と丸誤差を除けば。） ◎ Colors may be converted from one color space to another and, provided that there is no gamut mapping and that each color space can represent out of gamut colors, (for RGB spaces, this means that the transfer function is defined over the extended range) then (subject to numerical precision and round-off error) the two colors will look the same and represent the same color sensation.

`色を変換~用に準備する@ ~algoは、所与の ( 色 %~source色 ) に対し： ◎ To prepare a color col1 for conversion:

%~source色を成す各`無力$な成分を`欠落~成分$に変更する ◎ Change any powerless components in src to missing components
~IF［ %~source色が属する色~空間は`円柱な極-座標$で表現される］ ⇒ %~source色 ~SET %~source色を対応する`矩形な直交-座標$で表現される色~空間へ変換した結果 ◎ If src is in a cylindrical polar color representation, convert col1 to the corresponding rectangular orthogonal color representation and let this be the new col1.
~RET %~source色 ◎ ↑

`色を変換する@ ~algoは、所与の ( 色 %~source色, `色~空間$ %行先 ) に対し： ◎ To convert a color col1 in a source color space src with white point src-white to a color col2 in destination color space dest with white point dest-white, where src and dest are different:

%~source ~LET %~source色が属する色~空間 ◎ ↑
~Assert： %~source と %行先は異なる色~空間である。 ◎ ↑
%~source色 ~SET `色を変換~用に準備する$( %~source色 ) ◎ prepare col1 for conversion
%~source色を成す各`欠落~成分$を 0 に置換する ◎ Replace any missing component with zero.
~IF［ %~source は光に線形でない］ ⇒ %~source色 ~SET %~source色を光に線形な表現へ変換した結果（~gamma符号化を外す） ◎ If src is not a linear-light representation, convert it to linear light (undo gamma-encoding) and let this be the new col1.
%~XYZ ~LET %~source色を %~source 用の`白色点$を伴う~CIE~XYZへ変換した結果 ◎ Convert col1 to CIE XYZ with a given whitepoint src-white and let this be xyz.
~IF［ %行先用の`白色点$ ~NEQ %~source 用の`白色点$ ］ ⇒ %~XYZ ~SET ［線形~Bradford`有彩色~順応~変形$ `Bradford-CAT$r ］を利用して， %~XYZ を %行先用の`白色点$に順応した結果 ◎ If dest-white is not the same as src-white, chromatically adapt xyz to dest-white using a linear Bradford chromatic adaptation transform, and let this be the new xyz.
%矩形な行先 ~LET %行先に応じて ⇒＃ `円柱な極-座標$で表現されるならば %行先に対応する`矩形な直交-座標$で表現される色~空間／ `矩形な直交-座標$で表現されるならば %行先 ◎ If dest is a cylindrical polar color representation, let dest-rect be the corresponding rectangular orthogonal color representation. Otherwise, let dest-rect be dest.
%行先~色 ~LET %~XYZ を %矩形な行先【！dest】へ変換してから伝達t関数（~gamma符号化）を適用した結果 ◎ Convert xyz to dest, followed by applying any transfer function (gamma encoding), producing col2.
~IF［ %行先は~displayなどの物理的な出力~色~空間である］ ⇒ %行先~色 ~SET %行先~色を`表示し得る$ように`~CSS色域~対応付け$を施した結果 ◎ If dest is a physical output color space, such as a display, then col2 must be css gamut mapped so that it can be displayed.
~IF［ %行先は`円柱な極-座標$である］ ⇒ %行先~色 ~SET %行先~色を %矩形な行先から %行先へ変換した結果

この段は、 `欠落~成分$を生産し得る【例：無~彩度な色の色相~成分】。
◎ If dest-rect is not the same as dest, in other words dest is a cylindrical polar color representation, convert from dest-rect to dest, and let this be col2. This may produce missing components.

【色の変換-法は， `§ 定義済み色~空間＠#predefined$内のいくつかの下位節でも，特定の色~空間~用に定義されているが、この~algoは，それらを包摂する（この~algoが規範的とされる）ように思われる。】【原文の~algoでは，入力として白色点も色~空間とは別々に与えられているが、白色点は，どの`定義済み色~空間$にも定義されているので、この訳では，白色点を色~空間の一部を成すと見做す。】

12. `color$t 値の比較-法

2 個の `color$t 値は、以下の~algoを利用して比較したとき等しくなるならば，`等価な色$とされる。この比較は、例えば，［ `style^f 容器~query【`容器~style~query$】 `CSS-CONDITIONAL-5$r ／ ~CSS遷移 `CSS-TRANSITIONS-1$r ］により，［色~値が変化したかどうかを決定する］ために利用される~FN。 ◎ Two <color> values are equivalent colors when they compare as equal using the algorithm below. This comparison is used, for example, by style() container queries [CSS-CONDITIONAL-5] and by CSS Transitions [CSS-TRANSITIONS-1] to determine whether a color value has changed.

【~FN この比較は、推移律を満たさないので，変化を検出すること以外の用途には適切にならないであろう。】

所与の 2 つの色 — `color$t 値 — が `等価な色@ であるとは、次の~algoが ~T を返すことをいう： ◎ Given two <color> values C1 and C2, they are equivalent colors if and only if the following algorithm returns true:

双方の色を成す`無力$な成分たちを`欠落~成分$で置換する ◎ For each of C1 and C2, convert any powerless components to missing components.
~IF［双方の色は同じ `color-space$t 内で表出されている］ ⇒ ~RET ~IS［どの成分（~alphaも含む）に対しても，双方の色を成す対応する成分どうしは ~OR↓ を満たす］：
- どちらも`欠落~成分$である
- それらの差は、 `実装定義$な微小数を超えない
【この微小数は、 `無力$な成分~用に定義される`微小数$とは別物であり，当の色~空間や成分に応じて異なることもあろう。】
◎ If C1 and C2 share the same <color-space>: • Compare their components one by one, including the alpha channel. A missing component is only equal to another missing component. Two numeric components are considered equal if they differ by no more than a small implementation-defined ε. • Return true if and only if all components compare as equal.
~IF［どちらかの色は`欠落~成分$を有する］ ⇒ ~RET ~F ◎ Otherwise, C1 and C2 are in different <color-space>s. If either color has at least one missing component, return false.
双方の色を `oklab$v へ変換する ◎ Otherwise, neither color has any missing component. Convert both C1 and C2 to oklab,＼
~RET ~IS［どの成分（~alphaも含む）に対しても，［双方の色を成す対応する成分どうしの差］は［ ~Oklab用に標準~化された微小数 0.00001 ］を超えない］ ◎ then return true if and only if all components (including alpha) of the converted colors compare as equal, using a standardized Oklab ε of 0.00001.

注記： 2 つの色は、異なる `color-space$t 内で表出されていても，色計量において一致するならば（例： `red$vN と `color(srgb 1 0 0)^v ）、同じ `oklab$v 値へ変換されるので，`等価な色$になる。 ◎ Note: Two colors that are expressed in different <color-space>s but are colorimetrically identical—for example, red and color(srgb 1 0 0)—are equivalent colors by step 4 of this algorithm, since they convert to the same oklab value.

この比較の目的においては、次に挙げるものは， `srgb$v 内で表出されているものと見なされる ⇒＃ `rgb$f, `rgba$f, `hsl$f, `hsla$f, `hwb$f, `~hex色$, `有名~色$, `~system色$ ◎ For the purposes of this comparison, rgb(), rgba(), hsl(), hsla(), hwb(), hex colors, named colors, and system colors are all considered to be in the srgb <color-space>.

13. 色~補間

色~補間は、次に挙げる所で起こる ⇒＃ ~gradient, 組成-法【`単純~alpha組成-法＠~COMPOSITING#simplealphacompositing$】 ~filter, 遷移, ~animation, 色を混合する関数, 色を改変する関数 ◎ Color interpolation happens with gradients, compositing, filters, transitions, animations, and color mixing and color modification functions.

【これらの具体例は、下の § 13.1 に挙げられている。】

2 個の `color$t 値どうしの補間は、所与の色~空間 — 以下では `補間~色~空間@ と称される — の下で，次の手続きを実行することにより行われる： ◎ Interpolation between two <color> values takes place by executing the following steps: ◎ ↓

各~色に対し： ◎ ↓
1. 【`補間~色~空間$と】［ `相似的な成分$, `相似的な集合$ ］のうちどれが`先へ運ばれ$【！@】ることになるか検査する。 ◎ checking the two colors for analogous components and analogous sets which will be carried forward
2. 当の色を成す各`無力$な成分を`欠落~成分$へ変更する。 ◎ changing any powerless components to missing values
3. `補間~色~空間$へ変換する。 ◎ converting them both to a given color space＼ ↑ which will be referred to as the interpolation color space below.
4. 変換された色に`先へ運ばれ$た成分【！値】たちを（もしあれば）挿入し直す。 ◎ (if required) re-inserting carried forward values in the converted colors
5. （必要なら）色相を修復する — 選定された `hue-interpolation-method$t に依存して。 ◎ (if required) fixing up the hues, depending on the selected <hue-interpolation-method>
6. 各~成分を`乗算済み$な形に変更する。 ◎ changing the color components to premultiplied form
両~色を線形に補間する — 算出d値【`補間~色~空間$における算出d値の型】を成す各~成分に対し，別々に。 ◎ linearly interpolating each component of the computed value of the color separately
補間した結果を`非乗算済み$化する。 ◎ undoing premultiplication

`currentcolor$v との補間もアリであり、その使用~値がその目的に利用される数量的な値を与える。 ◎ Interpolating to or from currentcolor is possible. The numerical value used for this purpose is the used value.

13.1. 補間~用の色~空間

~CSSには、色の補間-法に依存する様々な特能がある。 ◎ Various features in CSS depend on interpolating colors.

例えば、次が挙げられる ⇒＃ `gradient$t, `filter$p, `transition$p, `animation$p, `color-mix$f, `相対~色~構文$ ◎ Examples include: • <gradient> • filter • animation • transition • color-mix() • relative color syntax

色を混合した結果, あるいは結合した結果は、利用される`補間~色~空間$に依存する。したがって、補間に適切な色~空間は，利用事例に応じて異なり得る： ◎ Mixing or otherwise combining colors has different results depending on the interpolation color space used. Thus, different color spaces may be more appropriate for each interpolation use case.

一部の事例では、 2 つの有色な光を物理的に混合した結果が欲される。その事例では、光~強度に線形な，［ `xyz$v【！~CIE~XYZ】／ `display-p3-linear$v ／ `srgb-linear$v ］色~空間が適切になる。 ◎ In some cases, the result of physically mixing two colored lights is desired. In that case, the CIE XYZ, display-p3-linear or srgb-linear color spaces are appropriate, because they are linear in light intensity.
色が知覚的に均等に~~分布する必要がある場合（~gradient内など）、 `oklab$v【！~Oklab】色~空間（および，より旧い `lab$v【！~Lab】）が，知覚的に一様になるよう設計されている。 ◎ If colors need to be evenly spaced perceptually (such as in a gradient), the Oklab color space (and the older Lab), are designed to be perceptually uniform.
色の混合-時に退色（ `greying out^en ）を避ける — すなわち、遷移の至る所で色度を最大化する【保つ？】 — よう欲される場合、 `oklch$v【！~OkLCh】（および，より旧い `lch$v【！~LCH】）が，きちんと働く。 ◎ If avoiding graying out in color mixing is desired, i.e. maximizing chroma throughout the transition, OkLCh (and the older LCH) work well for that.
最後に，旧来の~Web内容との互換性が最も重要な考慮になることもあろう。その場合、光に線形でも知覚的に一様でもない `srgb$v【！~sRGB】色~空間を選ぶことになる — 他より拙い混合-結果を生産する（暗になり過ぎる／~grayがかる）としても。 ◎ Lastly, compatibility with legacy Web content may be the most important consideration. The sRGB color space, which is neither linear-light nor perceptually uniform, is the choice here, even though it produces poorer results (overly dark or greyish mixes).

上に挙げた特能は、 `~host構文@ と総称される。 ◎ These features are collectively termed the host syntax.

`補間~色~空間$を指示することを`~host構文$に許可するため、この仕様は， `color-interpolation-method$t 生成規則を~exportする。この生成規則は、この仕様では利用されないが，他の仕様が容易に参照して【！↓ for easy reference from】利用できるよう【ここに】公開される — 例えば、 `CSS-IMAGES-4$r `§ 線型~gradient＠~CSSIMAGE4#linear-gradients$ における利用を見よ。 ◎ To permit a host syntax to indicate the interpolation color space, this specification exports a color-interpolation-method production. It is not used by this specification itself, only exposed so that other specifications can use it; see e.g. use in CSS Images 4 § 3.1 Linear Gradients: the linear-gradient() notation.

`~host構文$は、各~事例に対し，どれを既定の`補間~色~空間$とするべきか定義するベキである — そうする場合、この既定を上書きする作者~用の構文も供する方が好ましい。そのような構文が，ある~prop用の値の一部を成す場合、以下に定義される `color-interpolation-method$t 生成規則を利用するベキである。これは、［ ~CSSにまたがる一貫性を確保する］ことに加え，［色~補間の遂行-法に対する~custom化が，自動的にすべての~CSSに浸透できる］ようにする。 ◎ The host syntax should define what the default interpolation color space should be for each case, and preferably provide syntax for authors to override this default. If such syntax is part of a property value, it should use the color-interpolation-method production, defined below for easy reference from other specifications. This ensures consistency across CSS, and that further customizations on how color interpolation is performed can automatically percolate across all of CSS.

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

［ `rectangular-color-space$t ／ `polar-color-space$t ］の定義を成す各~keywordは、各自に対応する色~空間を参照rする — ~CSSにおいては、［同じ名前を伴う関数-構文, あるいは（そのような関数は無い場合は） `color$f 関数~内の対応している `ident$t ］により表現される。 ◎ The keywords in the definitions of <rectangular-color-space> and <polar-color-space> each refer to their corresponding color space, represented in CSS either by the functional syntax with the same name, or (if no such function is present), by the corresponding <ident> in the color() function.

`~host構文$が［ `補間~色~空間$として何が場を占めるべきか］を定義しない場合の既定は、 `~Oklab$になるとする。 ◎ If the host syntax does not define what color space interpolation should take place in, it defaults to Oklab.

`polar-color-space$t 用に `hue-interpolation-method$t が指定されなかった場合の既定は、 `shorter$v になるとする。 ◎ For a <polar-color-space> if the <hue-interpolation-method> is not specified, it defaults to shorter.

しかしながら，~UAは、［旧来の~sRGB色~形式（ `~hex色$, `有名~色$, `rgb$f, `hsl$f, `hwb$f, あるいは，これらに等価な~alphaを含んでいる形）どうしの補間］を［ ~gamma符号化された~sRGB空間］内で取扱う`モノトスル^em。これは、 ~Web互換性を供するためである — 旧来の~sRGB内容は、既定では~sRGB空間~内で補間される。 ◎ However, user agents must handle interpolation between legacy sRGB color formats (hex colors, named colors, rgb(), hsl() or hwb() and the equivalent alpha-including forms) in gamma-encoded sRGB space. This provides Web compatibility; legacy sRGB content interpolates in the sRGB space by default.

このことは、作者は，~sRGB色どうしでも［次のいずれかにより，より良い補間を選べる］ことを意味する ⇒＃どちらかの色に旧来でない `color(srgb r g b)^v 形を利用する／ `補間~色~空間$を明示的に指定する ◎ This also means that authors can choose to opt-in to better interpolation, even between sRGB colors, by using the non-legacy color(srgb r g b) form for at least one of their colors, or by explicitly specifying an interpolation color space.

補間される色が`補間~色~空間$の色域の外側にある場合、その空間へ変換した結果は，範囲~外の値を包含することになる。そのような値は、 ~clipすることなく，そのまま補間するモノトスル。 ◎ If the colors to be interpolated are outside the gamut of the interpolation color space , then once converted to that space, they will contain out of range values. ◎ These are not clipped; the values must be interpolated as-is.

13.2. 欠落~成分との補間-法

2 つの色を`補間~色~空間$へ変換するに伴い、 `欠落~成分$は，値 0 に置換されることになる。 ◎ In the course of converting the two colors to the interpolation color space, any missing components would be replaced with the value 0.

しかしながら、［入力~色において`欠落~成分$ ］のうち［ `補間~色~空間$のある成分と`相似的な成分$であると分類されるもの］は， `先へ運ばれ@【！$】る（ `carried forward^en ） — すなわち、［線形な補間, 【それに伴われる】`乗算済み$化］が場を占める前に，変換した結果の色に挿入し直される~FN ことになる。 ◎ Thus, the first stage in interpolating two colors is to classify any missing components in the input colors, and compare them to the components of the interpolation color space. If any analogous components which are missing components are found, they will be carried forward and re-inserted in the converted color before premultiplication, and before linear interpolation takes place.

【ある成分が欠落な事実は、 `補間~色~空間$における補間に必要になるので。】【~FN 具体的には、［変換した結果の色を成す相似的な成分］は，［ 0 に代えて，欠落なことを表現する値 `none$v ］に設定される。】

類似に，元の色における`相似的な集合$を成すどの成分も`欠落~成分$である場合、それらすべては`先へ運ばれ$， `補間~色~空間$における対応する`相似的な集合$へ挿入し直される。 ◎ Similarly, if every component of an analogous set (defined below) in the original color is a missing component, they are all carried forward and re-inserted in the corresponding analogous set of the interpolation color space.

~alphaが`欠落~成分$である場合も，他の欠落~成分と正確に同じ仕方で`先へ運ばれ$る — ~alphaにz`相似的な成分$は~alphaである。 ◎ Alpha is its own analogous component (alpha is analogous to alpha), so a missing alpha is carried forward in exactly the same way as any other missing component.

`相似的な成分@ （ `analogous component^en ）は、以下に従う： ◎ The analogous components are as follows:

分類y	成分
~red	r, x
~green	g, y
~blue	b, z
明度	L
色彩度~FN1	C, S
色相	H
`opponent^en a ~FN2	a
`opponent^en b ~FN2	b
~alpha	~alpha

◎ Category｜Components ◎ Reds｜r,x Greens｜g,y Blues｜b,z Lightness｜L Colorfulness｜C, S Hue｜H Opponent a｜a Opponent b｜b

【表tの 2 列目に挙げられる成分どうしが、 “互いに相似的である” とされ，表tの 1 列目に挙げられる分類yに属する。】【~FN1 色彩度（ `colorfulness^en ）とは、［彩度, 色度］の総称を意味する。】【~FN2 この文脈における “`opponent^en” が何を意味するのか（何に対し `opponent^en であるか）は不明。】

注記：この分類の目的においては、 ~XYZ空間は，超~彩度な~RGB空間と見なされる。また，彩度は明度に依存しているにもかかわらず、ここでは，色度と同じ分類yに入る。 ~HWBの［白度, 黒度］成分には、他の色~空間における相似物は無い。 ◎ Note: for the purposes of this classification, the XYZ spaces are considered super-saturated RGB spaces. Also, despite Saturation being Lightness-dependent, it falls in the same category as Chroma here. The Whiteness and Blackness components of HWB have no analogs in other color spaces.

加えて、所与の 2 つの色~空間に対し，両者から`相似的な成分$をすべて除去した後に残る成分たちは、 `相似的な集合@ （ `analogous set^en ）を形成する。 ◎ Additionally, for any two color spaces, the components that remain after removing all analogous components form an analogous set of components.

【もっと冗漫に述べるなら、 “互いに相似的である” とされるもの以外の成分たちが成す “個別にではなく，全体として互いに相似的である” とされる集合。】

注記：個々の`相似的な成分$が無いときは，`相似的な集合$は［すべての色~成分たちが成す全部的な集合］になるので、ある色の成分~すべてが`欠落~成分$である場合，それらすべてが`補間~色~空間$においても`欠落~成分$になる。 ◎ Note: Because the full set of all color components is the analogous set that remains when there are no individual analogous components, a color with all color components missing will have all color components missing in the interpolation color space as well.

`lab(50% none none)^v を補間~用に~LCHへ変換するとき、明度は個別に`相似的な成分$になり，残りの成分たち（~Labにおける a, b ／ ~LCHにおける C, H ）は`相似的な集合$を形成する。 a, b はどちらも`欠落~成分$なので、 C, H はどちらも`欠落~成分$として`先へ運ばれ$， `lch(50% none none)^v を与える — `lch(50% 0 0)^v ではなく。 ◎ When converting lab(50% none none) to LCH for interpolation, Lightness is individually analogous. The remaining components (a and b in Lab; C and H in LCH) form an analogous set. Since both a and b are missing, both C and H are carried forward as missing, giving lch(50% none none) rather than lch(50% 0 0).

類似に， `rgb(none none none / 50%)^v を補間~用に~Oklabへ変換した結果は、 `oklab(none none none / 50%)^v になる — 3 個の色~成分は`相似的な集合$を形成するので（~sRGBと~Oklabの間には，`相似的な成分$は【~alphaしか】無い）。 ◎ Similarly, rgb(none none none / 50%) converted to OKLab for interpolation yields oklab(none none none / 50%), because the three color components form the analogous set (there are no individual analogous components between sRGB and OKLab).

例えば、次の 2 つの色が~OkLCh内で補間される場合 ⇒＃ `46.647% 46.628% 46.633%^rgb `lch(50% 0.02 none)^v, `71.559% 49.813% 0%^rgb `color(display-p3 0.7 0.5 none)^v ◎ For example, if these two colors are to be interpolated in OkLCh,＼

1 個目の色（~CIE~LCH）において欠落~色相は、 ~OkLChの色相~成分に相似的であり，`先へ運ばれ$ることになる。一方で， 2 個目の色において欠落~blue成分は、相似的な~OkLCh成分は無いので，`先へ運ばれ$ないことになる ◎ the missing hue in the CIE LCH color is analogous to the hue component of OkLCh and will be carried forward while the missing blue component in the second color is not analogous to any OkLCh component and will not be carried forward: • lch(50% 0.02 none) • color(display-p3 0.7 0.5 none)

これらを変換した結果は ⇒＃ `46.647% 46.628% 46.633%^rgb `oklch(56.897% 0.0001 0)^v, `71.559% 49.813% 0%^rgb `oklch(63.612% 0.1522 78.748)^v ◎ which convert to • oklch(56.897% 0.0001 0) • oklch(63.612% 0.1522 78.748)

`欠落~成分$のうち`先へ運ばれ$るものは、挿入し直される — その結果，補間される 2 つの色は ⇒＃ `46.647% 46.628% 46.633%^rgb `oklch(56.897% 0.0001 none)^v, `71.559% 49.813% 0%^rgb `oklch(63.612% 0.1522 78.748)^v ◎ and with carried forward missing component re-inserted, the two colors to be interpolated are: • oklch(56.897% 0.0001 none) • oklch(63.612% 0.1522 78.748)

補間される一方の色は［ `先へ運ばれ$た`欠落~成分$ ］を伴うが，他方の色はそうでない場合、当の`欠落~成分$は，`他方の色^emの成分~値をとるものと扱われる。 ◎ If a color with a carried forward missing component is interpolated with another color which is not missing that component, the missing component is treated as having the other color’s component value.

したがって、 `先へ運ばれ$る成分の識別は，`無力$な成分の取扱いよりも前に遂行するモノトスル — その値が 0 へ変換されることを防止するため。 ◎ Therefore, the identification of carried-forward components must be performed before any powerless component handling; to prevent conversion of that value to zero.

例えば、次の 2 つの色が補間される場合 ⇒＃ `86.6% 62.7% 86.7%^rgb `oklch(78.3% 0.108 326.5)^v, `48.4% 0% 22.8%^rgb `oklch(39.2% 0.4 none)^v ◎ For example, if these two colors are interpolated, the second of which has a missing hue: • oklch(78.3% 0.108 326.5) • oklch(39.2% 0.4 none)

後者の色の色相は欠落なので、補間される実際の色は，次になる ⇒＃ `86.6% 62.7% 86.7%^rgb `oklch(78.3% 0.108 326.5)^v, `39% 0% 39.4%^rgb `oklch(39.2% 0.4 326.5)^v ◎ Then the actual colors to be interpolated are • oklch(78.3% 0.108 326.5) • oklch(39.2% 0.4 326.5)

`ex-oklch-missing-hue-1^dgm

次ではなく ⇒＃ `86.6% 62.7% 86.7%^rgb `oklch(78.3% 0.108 326.5)^v, `48.4% 0% 22.8%^rgb `oklch(39.2% 0.4 0)^v ◎ and not • oklch(78.3% 0.108 326.5) • oklch(39.2% 0.4 0)

`ex-oklch-missing-hue-2^dgm

`先へ運ばれ$た`欠落~成分$が~alphaである場合、当の色は，この［ `先へ運ばれ$た値］で`乗算済み$化するモノトスル — 色~変換から得られる結果の値 0 ではなく。 ◎ If the carried forward missing component is alpha, the color must be premultiplied with this carried forward value, not with the zero value that would have resulted from color conversion.

例えば、次の 2 つの色が補間される場合 ⇒＃ `86.6% 62.7% 86.7% / 0.5^rgb `oklch(0.783 0.108 326.5 / 0.5)^v, `48.4% 0% 22.8% / 0^rgb `oklch(0.392 0.4 0 / none)^v ◎ For example, if these two colors are interpolated, the second of which has a missing alpha: • oklch(0.783 0.108 326.5 / 0.5) • oklch(0.392 0.4 0 / none)

後者の色の~alphaは欠落なので、補間されることになる実際の色は ⇒＃ `86.6% 62.7% 86.7% / 0.5^rgb `oklch(78.3% 0.108 326.5 / 0.5)^v, `48.4% 0% 22.8% / 0.5^rgb `oklch(39.2% 0.4 0 / 0.5)^v ◎ Then the actual colors to be interpolated are • oklch(78.3% 0.108 326.5 / 0.5) • oklch(39.2% 0.4 0 / 0.5)

になり，`乗算済み$な~OkLCh値として，次を与える ⇒＃ [ 0.3915, 0.054, 326 ], [ 0.196, 0.2, 0 ] ◎ giving the premultiplied OkLCh values [0.3915, 0.054, 326] and [0.196, 0.2, 0].

`ex-oklch-missing-alpha^dgm

どちらの色も所与の成分が`欠落~成分$である場合、補間された色を成す当の成分も`欠落~成分$になる。 ◎ If both colors are missing a given component, the interpolated color will also be missing that component.

13.3. ~alphaを伴う色の補間-法

補間される色 %色は、【補間する前に】次に従って `乗算済み@ な色にされる — %色を成す【~alpha以外の】各~成分~値 %成分に対し，乗算済みな色の成分~値は：

%~alpha ~LET %色の~alpha値
~IF［ ~OR↓ ］…
- %~alpha ~EQ `none$v
- %成分 ~EQ `none$v
- %色は`円柱な極-座標$で表現されていて， %成分は色相~成分である
…ならば ⇒ ~RET %成分
~RET %成分 ~MUL %~alpha

【結果の`乗算済み$な色には、 ~alpha成分は無い — それらは補間~用の値であり、それらの補間に~alphaは関わらないので。】

◎ When the colors to be interpolated are not fully opaque, they are first premultiplied as follows: • If the alpha value is none, the premultiplied value is the un-premultiplied value. Otherwise, • If any component value is none, the premultiplied value is also none. • For rectangular orthogonal color coordinate systems, all component values are multiplied by the alpha value. • For cylindrical polar color coordinate systems, the hue angle is not premultiplied, but the other two axes are premultiplied.

【乗算済みな色~値どうしを補間した結果の】 `乗算済み$な色~値 %色から `非乗算済み@ な色~値を得する ~algoは、次に従う — %色を成す各~成分~値 %成分に対し，`非乗算済み$な色の成分~値は：

%~alpha ~LET 補間された~alpha値
~IF［ ~OR↓ ］…
- %~alpha ~IN { 0, `none$v }
- %成分 ~EQ `none$v
- %色は`円柱な極-座標$で表現されていて， %成分は色相~成分である【この条件は、この訳による補完。】
…ならば ⇒ ~RET %成分
~RET %成分 ~DIV %~alpha

◎ To obtain a color value from a premultiplied color value, • If the interpolated alpha value is zero or none, the un-premultiplied value is the premultiplied value. Otherwise, • If any component value is none, the un-premultiplied value is also none. • otherwise, each component which had been premultiplied is divided by the interpolated alpha value.

注記： ~alpha乗算済み化は、なぜ有用か？ ◎ Why is premultiplied alpha useful?

乗算済み表現を利用する色の補間は、乗算済みでない表現より美麗な遷移を生産する傾向にある — 特に，色が全に不透明から全に透明へ遷移するときには。 ◎ Interpolating colors using the premultiplied representations tends to produce more attractive transitions than the non-premultiplied representations, particularly when transitioning from a fully opaque color to fully transparent.

透明度または色が一定に保持される遷移（例： `rgb(255 0 0 / 100%)^v （不透明な `red^v ）から `rgb(0 0 255 / 100%)^v （不透明な `blue^v ）への遷移／ `rgb(255 0 0 / 100%)^v （不透明な `red^v ）から `rgb(255 0 0 / 0%)^v （透明な `red^v ）への遷移）による結果は、色の補間が［乗算済みな色~空間, 乗算済みでない色~空間］どちらで行われても，一致することに注意。相違が発生するのは、両~端点の［色, 透明度］が`どちらも^em相違するときに限られる。 ◎ Note that transitions where either the transparency or the color are held constant (for example, transitioning between rgba(255, 0, 0, 100%) (opaque red) and rgba(0,0,255,100%) (opaque blue), or rgba(255,0,0,100%) (opaque red) and rgba(255,0,0,0%) (transparent red)) have identical results whether the color interpolation is done in premultiplied or non-premultiplied color-space. Differences only arise when both the color and transparency differ between the two endpoints.

次の例に，［ `乗算済み$な値を介して遷移している~gradient, （不正に）乗算済みでない値を介して遷移している~gradient ］の相違を図解する（この事例では、旧来の色~しか孕まれないので，~sRGBに~~収まる）。どちらの~gradientも，~whiteな背景~越しに描かれるとする。どちらの~gradientも，次の値で書ける： ◎ The following example illustrates the difference between a gradient transitioning via pre-multiplied values (in this case sRGB, since all colors involved are legacy colors) and one transitioning (incorrectly) via non-premultiplied values. In both of these examples, the gradient is drawn over a white background. Both gradients could be written with the following value:

linear-gradient(90deg, red, transparent, blue)

乗算済みな色は、 “透明” から, あるいは “透明” へ遷移し，どこでも良好な見かけになる： ◎ With premultiplied colors, transitions to or from "transparent" always look nice:

他方，不正な［乗算済みでない空間~内の遷移］であった場合、 ~gradientの中央の色は，目立って~grayがかることになる — “透明” は、実際には `rgba(0,0,0,0)^v — 透明な`~black^em — の略記なので。すなわち、 `red^v は不透明度を失うに伴い~blackへ遷移し， `blue^v の遷移も類似になる： ◎ On the other hand, if a gradient were to incorrectly transition in non-premultiplied space, the center of the gradient would be a noticeably grayish color, because "transparent" is actually a shorthand for rgba(0,0,0,0), or transparent black, meaning that the red transitions to a black as it loses opacity, and similarly with the blue’s transition:

例えば、 ~sRGBに属する 2 個の色 `24% 12% 98% / 0.4^rgb `rgb(24% 12% 98% / 0.4)^v, `62% 26% 64% / 0.6^rgb `rgb(62% 26% 64% / 0.6)^v を~sRGB色~空間~内で補間するときは、それに先立って，`乗算済み$な形 ( 9.6%, 4.8%, 39.2% ), ( 37.2%, 15.6%, 38.4% ) へ変換する。 ◎ For example, to interpolate, in the sRGB color space, the two sRGB colors rgb(24% 12% 98% / 0.4) and rgb(62% 26% 64% / 0.6) they would first be converted to premultiplied form [9.6% 4.8% 39.2% ] and [37.2% 15.6% 38.4%] before interpolation.

これらの色を線形に補間した結果の中点は、 ~alpha値 0.5 を伴う ( 23.4%, 10.2%, 38.8% ) になり，非乗算済み化した結果は `46.8% 20.4% 77.6% / 0.5^rgb `rgb(46.8% 20.4% 77.6% / 0.5)^v になる。 ◎ The midpoint of linearly interpolating these colors would be [23.4% 10.2% 38.8%] which, with an alpha value of 0.5, is rgb(46.8% 20.4% 77.6% / 0.5) when premultiplication is undone.

【異なる色~空間に属する】 2 個の色 `76% 62% 03% / 0.4^rgb `rgb(76% 62% 03% / 0.4)^v, `91.56% 3.87% 74.09% / 0.6^rgb `color(display-p3 0.84 0.19 0.72 / 0.6)^v を~Lab色~空間~内で補間するためには、それに先立って，まず~Labへ変換して `lab(66.927% 4.873 68.622 / 0.4)^v, `lab(53.503% 82.672 -33.901 / 0.6)^v を得た上で， ( L, a, b ) 座標を`乗算済み$な ( 26.771%, 1.949, 27.449 ), ( 32.102%, 49.603, -20.341 ) にする。 ◎ To interpolate, in the Lab color space, the two colors rgb(76% 62% 03% / 0.4) and color(display-p3 0.84 0.19 0.72 / 0.6) they are first converted to lab lab(66.927% 4.873 68.622 / 0.4) lab(53.503% 82.672 -33.901 / 0.6) then the L, a and b coordinates are premultiplied before interpolation [26.771% 1.949 27.449] and [32.102% 49.603 -20.341].

これらの色を線形に補間した結果の中点は、 ~alpha値 0.5 を伴う ( 29.4365%, 25.776, 3.554 ) になり，非乗算済み化した結果は `87.604%, 38.956%, 51.753%, 0.5^rgb `lab(58.873% 51.552 7.108 / 0.5)^v になる。 ◎ The midpoint of linearly interpolating these would be [29.4365% 25.776 3.554] which, with an alpha value of 0.5, is lab(58.873% 51.552 7.108) / 0.5) when premultiplication is undone.

上の例と同じ 2 個の色 `76% 62% 03% / 0.4^rgb `rgb(76% 62% 03% / 0.4)^v, `91.56% 3.87% 74.09% / 0.6^rgb `color(display-p3 0.84 0.19 0.72 / 0.6)^v を色度を保全する~LCH色~空間~内で補間するためには、まず~LCHへ変換して `76% 62% 03% / 0.4^rgb `lch(66.93% 68.79 85.94 / 0.4)^v, `91.56% 3.87% 74.09% / 0.6^rgb `lch(53.5% 89.35 337.7 / 0.6)^v を得てから，（ H を除く） L, C 座標を補間の前に`乗算済み$な ( 26.771%, 27.516, 85.94 ), ( 32.102%, 53.61, 337.7 ) にする。 ◎ To interpolate, in the chroma-preserving LCH color space, the same two colors rgb(76% 62% 03% / 0.4) and color(display-p3 0.84 0.19 0.72 / 0.6) they are first converted to LCH lch(66.93% 68.79 85.94 / 0.4) lch(53.5% 89.35 337.7 / 0.6) then the L and C coordinates (but not H) are premultiplied before interpolation [26.771% 27.516 85.94] and [32.102% 53.61 337.7].

これらの色を — `shorter$v な【短い方の】色相~弧（既定）に沿って — 線形に補間した結果の中点は、 ~alpha値 0.5 を伴う ( 29.4365%, 40.563, 31.82 ) になり，非乗算済み化した結果は `99.344% 28.029% 28.277% / 0.5^rgb `lch(58.873% 81.126 31.82) / 0.5)^v になる。 ◎ The midpoint of linearly interpolating these, along the shorter hue arc (the default) would be [29.4365% 40.563 31.82] which, with an alpha value of 0.5, is lch(58.873% 81.126 31.82) / 0.5) when premultiplication is undone.

`§ 色~変換~codeの見本$に， ~alphaによる［乗算済み化, 非乗算済み化］用の見本~JS~codeがある — `円柱な極-座標$用にも, `矩形な直交-座標$用にも。 ◎ There is sample JavaScript code for alpha premultiplication and un-premultiplication, for both polar and rectangular color spaces, in § 19 Sample code for Color Conversions.

13.4. 色相の補間

色相~角度を伴う色~関数（ ~LCH, ~HSL, ~HWB 等々）用に補間する仕方は、複数ある。 360° を超える弧は，稀にしか欲されないので、色相~角度は，補間に先立って［成分ごとの補間が， 360° 未満 — 多くの場合 180° 未満 — に対し行われる］よう修復される。 ◎ For color functions with a hue angle (LCH, HSL, HWB etc), there are multiple ways to interpolate. As arcs greater than 360° are rarely desirable, hue angles are fixed up prior to interpolation so that per-component interpolation is done over less than 360°, often less than 180°.

`~host構文$は、色相~補間~用に次に挙げる~algoを指定できる（以下における角度は度数（ `deg$u ）によるが、どう指定されようが，~logicは同じになる）。色相~補間~策の指定-法は、 `hue-interpolation-method$t ~tokenを介して，すでに `color-interpolation-method$t 構文の一部を成している。 ◎ Host syntax can specify any of the following algorithms for hue interpolation (angles in the following are in degrees, but the logic is the same regardless of how they are specified). Specifying a hue interpolation strategy is already part of the <color-interpolation-method> syntax via the <hue-interpolation-method> token.

他が指定されない限り、 `~host構文$が特定の色相~補間~algoを選定しない場合の既定は， `shorter$v とする。 ◎ Unless otherwise specified, if no specific hue interpolation algorithm is selected by the host syntax, the default is shorter.

注記：補間に先立って，補間される色を`補間~色~空間$へ変換する必要がある場合、【！As a reminder, if the interpolating colors were not already in the specified】それらの色の`無力$な成分は，`欠落~成分$に転換されることになる。 ◎ Note: As a reminder, if the interpolating colors were not already in the specified interpolation color space, then converting them will turn any powerless components into missing components.

【色相は、以下に述べる調整に先立って， 0 以上 360 未満に正規化-済みであることに注意。】

`shorter@v ◎ 13.4.1. shorter

色相~角度は、結果が［ 2 つの色相の合間を成す 2 つの弧のうち`短い方^em ］に乗るよう補間される。 ◎ Hue angles are interpolated to take the shorter of the two arcs between the starting and ending hues.

例えば， ~OkLCh内で ~red `93.22% 7.98% 0.485%^rgb `oklch(0.6 0.24 30)^v から ~yellow `89.07% 72.28% 19.23%^rgb `oklch(0.8 0.15 90)^v へ補間するときの中点は、 2 つの色の合間を成す短い方の弧に沿って色相~角度 ( 30 ~PLUS ( 90 ~MINUS 30 ) ~MUL 0.5 ) = 60° の所にあり，濃い~orange `87.66% 51.96% 0%^rgb `oklch(0.7 0.195 60)^v を与える。 ◎ For example, the midpoint when interpolating in OkLCh from a red oklch(0.6 0.24 30) to a yellow oklch(0.8 0.15 90) would be at a hue angle of 30 + (90 - 30) * 0.5 = 60 degrees, along the shorter arc between the two colors, giving a deep orange oklch(0.7 0.195 60)

`ex-shorter^dgm

角度は［ %θ₂ ~MINUS %θ₁ の絶対~値が 180 以下になる］よう調整される。疑似-~JSでは： ◎ Angles are adjusted so that θ₂ - θ₁ ∈ [-180, 180]. In pseudo-Javascript:

if (%θ₂ - %θ₁ > 180) {
  %θ₁ += 360;
}
else if (%θ₂ - %θ₁ < -180) {
  %θ₂ += 360;
}

`longer@v ◎ 13.4.2. longer

色相~角度は、結果が［ 2 つの色相の合間を成す 2 つの弧のうち`長い方^em ］に乗るよう補間される。 ◎ Hue angles are interpolated to take the longer of the two arcs between the starting and ending hues.

例えば，~OkLCh内で ~red `93.22% 7.98% 0.485%^rgb `oklch(0.6 0.24 30)^v から ~yellow `89.07% 72.28% 19.23%^rgb `oklch(0.8 0.15 90)^v へ補間するときの中点は、 2 つの色の合間を成す長い方の弧に沿って色相~角度 ( 30 ~PLUS 360 ~PLUS 90 ) ~MUL 0.5 = 240° の所にあり，薄い~blue `0% 66.25% 100%^rgb `oklch(0.7 0.195 240)^v を与える。 ◎ For example, the midpoint when interpolating in OkLCh from a red oklch(0.6 0.24 30) to a yellow oklch(0.8 0.15 90) would be at a hue angle of (30 + 360 + 90) * 0.5 = 240 degrees, along the longer arc between the two colors, giving a sky blue oklch(0.7 0.195 240)

`ex-longer^dgm

角度は［ %θ₂ ~MINUS %θ₁ の絶対~値が 180 以上 360 以下になる］よう調整される。疑似-~JSでは： ◎ Angles are adjusted so that θ₂ - θ₁ ∈ {(-360, -180], [180, 360)}. In pseudo-Javascript:

if (0 < %θ₂ - %θ₁ < 180) {
  %θ₁ += 360;
}
else if (-180 < %θ₂ - %θ₁ <= 0) {
  %θ₂ += 360;
}

`increasing@v ◎ 13.4.3. increasing

色相~角度は、［ 1 個目の色から 2 個目の色へ進捗するに伴い，角度が常に`増大する^em ］よう補間される。角度が 360 まで増大したときは、 0 に設定し直されてから増大し続ける。 ◎ Hue angles are interpolated so that, as they progress from the first color to the second, the angle is always increasing. If the angle increases to 360 it is reset to zero, and then continues increasing.

結果が［短い方, 長い方］どちらの弧に乗るかは、 2 つの角度の差に依存する。しかしながら、［一方の色相~角度が~animateされていて，色相~角度の差が 180° を通過した場合］でも，補間が他方の弧に乗るよう移転することはない。 ◎ Depending on the difference between the two angles, this will either look the same as shorter or as longer. However, if one of the hue angles is being animated, and the hue angle difference passes through 180 degrees, the interpolation will not flip to the other arc.

例えば，~OkLCh内で濃い~brown `57.92% 29.44% 25.11%^rgb `oklch(0.5 0.1 30)^v から ~turquoise `26.29% 69.89% 67.49%^rgb `oklch(0.7 0.1 190)^v へ補間するとき、中点は色相~角度 ( 30 ~PLUS 190 ) ~MUL 0.5 = 110° の所にあり， ~khaki `51.73% 52.26% 22.03%^rgb `oklch(0.6 0.1 110)^v を与える。 ◎ For example, the midpoint when interpolating in OkLCh from a deep brown oklch(0.5 0.1 30) to a turquoise oklch(0.7 0.1 190) would be at a hue angle of (30 + 190) * 0.5 = 110 degrees, giving a khaki oklch(0.6 0.1 110).

`ex-increasing-1^dgm

しかしながら， 2 個目の色の色相が `33.09% 66.63% 81.81%^rgb `oklch(0.7 0.1 230)^v へ~animateされた場合、角度は，~animationの途中で反対~色へ移転することなく増大し続けていく — その結果、補間の中点は ( 30 ~PLUS 230 ) ~MUL 0.5 = 130° になり，別の~green `42.44% 54.95% 28.93%^rgb `oklch(0.6 0.1 130)^v を与える。 ◎ However, if the hue of the second color is animated to oklch(0.7 0.1 230), the midpoint of the interpolation will be (30 + 230) * 0.5 = 130 degrees, continuing in the same increasing direction, giving another green oklch(0.6 0.1 130) rather than flipping to the opponent color part-way through the animation.

`ex-increasing-2^dgm

角度は［ %θ₂ ~MINUS %θ₁ が 0 以上 360 未満になる］よう調整される。疑似-~JSでは： ◎ Angles are adjusted so that θ₂ - θ₁ ∈ [0, 360). In pseudo-Javascript:

if (%θ₂ < %θ₁) {
  %θ₂ += 360;
}

`decreasing@v ◎ 13.4.4. decreasing

色相~角度は、［ 1 個目の色から 2 個目の色へ進捗するに伴い，角度が常に`減少する^em ］よう補間される。角度が 0 まで減少したときは、 360 に設定し直されてから減少し続ける。 ◎ Hue angles are interpolated so that, as they progress from the first color to the second, the angle is always decreasing. If the angle decreases to 0 it is reset to 360, and then continues decreasing.

例えば，~OkLCh内で濃い~brown `57.92% 29.44% 25.11%^rgb `oklch(0.5 0.1 30)^v から ~turquoise `26.29% 69.89% 67.49%^rgb `oklch(0.7 0.1 190)^v へ補間するとき、中点は色相~角度 ( 30 ~PLUS 360 ~PLUS 190 ) ~MUL 0.5 = 290° の所にあり， ~purple `49.98% 46.03% 72.08%^rgb `oklch(0.6 0.1 290)^v を与える。 ◎ For example, the midpoint when interpolating in OkLCh from a deep brown oklch(0.5 0.1 30) to a turquoise oklch(0.7 0.1 190) would be at a hue angle of (30 + 360 + 190) * 0.5 = 290 degrees, giving a purple oklch(0.6 0.1 290).

`ex-decreasing-1^dgm

しかしながら， 2 個目の色の色相が `33.09% 66.63% 81.81%^rgb `oklch(0.7 0.1 230)^v へ~animateされた場合、角度は，~animationの途中で反対~色へ移転することなく減少し続けていく — その結果、補間の中点は ( 30 ~PLUS 360 ~PLUS 230 ) ~MUL 0.5 = 310° になり，別の~purple `57.47% 43.44% 67.8%^rgb `oklch(0.6 0.1 310)^v を与える — ~animationの途中で反対~色へ移転することなく。 ◎ However, if the hue of the second color is animated to oklch(0.7 0.1 230), the midpoint of the interpolation will be (30 + 360 + 230) * 0.5 = 310 degrees, continuing in the same decreasing direction, giving another purple oklch(0.6 0.1 310) rather than flipping to the opponent color part-way through the animation.

`ex-decreasing-2^dgm

角度は［ %θ₁ ~MINUS %θ₂ が 0 以上 360 未満になる］よう調整される。疑似-~JSでは： ◎ Angles are adjusted so that θ₂ - θ₁ ∈ (-360, 0]. In pseudo-Javascript:

if (%θ₁ < %θ₂) {
  %θ₁ += 360;
}

14. 色域~対応付け

14.1. 色域~対応付け序論

注記：この節は、［この文書~内の他所に述べられる特有な要件］用に重要な文脈を供する。 ◎ Note: This section provides important context for the specific requirements described elsewhere in the document.

◎非規範的

ある変換元~色~空間~内の色が［別の，より色域が狭い行先~色~空間］へ変換されるとき、一部の色は，行先~色域の外側に出ることになる。 ◎ When a color in an origin color space is converted to another, destination color space which has a smaller gamut, some colors will be outside the destination gamut.

これら色域~外の値は、色の中間~計算においては保全される。しかしながら，行先が~display機器（~screenや印刷機）である場合、色域~外の値は`色域~内$にある色へ変換されなければならない。 ◎ For intermediate color calculations, these out of gamut values are preserved. However, if the destination is the display device (a screen, or a printer) then out of gamut values must be converted to an in-gamut color.

色域~対応付けは、 `色域~内$にある色のうち［視覚的な外観において，その変化に最も異論が少ない色］を見出す処理nである。 ◎ Gamut mapping is the process of finding an in-gamut color with the least objectionable change in visual appearance.

色域~外の色には、現実世界の色に対応するものも（物理的に再現できる），物理的に実現し得ない想像上の色もある（分光軌跡の外側にあるので、単-波長の 100% 超が必要になる【？】）。色域~外の色は、 “この色の彩度を 100 倍する” などの計算から生じる傾向にある。 ◎ Some out of gamut colors correspond to real-world colors (they could be physically reproduced) while others are imaginary colors (they lie outside the spectral locus and thus would need more than 100% of a single wavelength) and could never be physically realized. Those colors tend to come from calculations such as "make this color 100x as saturated".

例えば，~CIE~Labの ( a, b ) 平面は、理論的には~~限界は無いが，［［ %a, %b ］どちらも −127 以上 127 以下までの範囲に拘束される］よう実装されることが多い。 ◎ For example, while theoretically unbounded, the CIE Lab (a,b) plane is often implemented such that a and b are constrained to the range ±127.

その 4 隅 ( ±127, ±127 ) のうち 3 個は、分光軌跡の外側にあるので，想像上の色に対応する。 ◎ Three of those four corners are outside the spectral locus and thus correspond to imaginary colors.

~UCS純色度~図式~上の (a, b) 平面の (±127, ±127) に~~位置する 4 隅。外縁な図形は分光軌跡。大きい三角形は `rec2020$v 色域, 小さい三角形は `srgb$v 色域。 ◎ The four corners of the ±127 (a,b) plane, on a UCS chromaticity diagram. The outer shape is the spectral locus. The larger triangle is the rec2020 gamut, while the smaller is sRGB.

14.1.1. ~clip法

最も単純かつ最も受容-可能でない手法は、単純に［各~成分~値を表示-可能な範囲に~clipする］ことである。 ◎ The simplest and least acceptable method is simply to clip the component values to the displayable range.

この手法は，速さが動機にあるので、光に線形な色~空間へ変換することなく，~gamma符号化された値に対し共通的に行われる。 ◎ Since the motivation for this method is speed, clipping is commonly done on gamma-encoded values rather than converting them to linear-light.

これは、（~RGB~display用の） 3 原色の相対比を変化させるので，結果の色相がズレる。 ◎ This changes the proportions of the three primary colors (for an RGB display), resulting in a hue shift.

例えば，色 `color(srgb-linear 0.5 1 3)^v を考える。これは，光に線形な色~空間なので、 3 成分の強度を比較できる — この色の各~成分の光の量は［ ~blueは~greenの 3 倍, ~redは~greenの半分］になるので、原色~blueは~redの 6 倍ある。 ~OkLChにおいては、この色の色相~角度は 265.1° になる。 ◎ For example, consider the color color(srgb-linear 0.5 1 3). Because this is a linear-light color space, we can compare the intensities of the three components and see that the amount of blue light is three times the amount of green, while the amount of red light is half that of green. There is six times as much blue primary as red. In OkLCh, this color has a hue angle of 265.1°

この色を~clipして~sRGB用の色域の中に持ち込んだとすると、 `color(srgb-linear 0.5 1 1)^v が得られ， ~blueと~greenの光の量は同じになる。 ~OkLChにおいては、この色の色相~角度は 196.1° になり， 69° も変化する。 ◎ If we now clip this color to bring it into gamut for sRGB, we get color(srgb-linear 0.5 1 1). The amount of blue light is the same as green. In OkLCh, this color has a hue angle of 196.1°, a substantial change of 69°.

色域~外にある色でも、色域に近いならば， ~clipした結果は受容-可能になり得る — 特に，より暗な（あるいは負な）成分~値においては。 ◎ When colors are not too far out of gamut, clipping can give acceptable results. This is particularly true for darker (or negative) component values.

例えば， `color(rec2020 0.54 0.9 0)^v を~gamma符号化された~P3色~空間へ変換した結果は、 `color(display-p3 0.3265 0.9165 -0.1262)^v （光に線形な色~空間においては、 `color(display-p3-linear 0.0871 0.8205 -0.0146)^v ）になる — 負な~blue成分は、結果の色は色域~外にあることを示す。 ◎ For example, consider the color color(rec2020 0.54 0.9 0) which is oklch(80.72% 0.3296 141.6). ◎ Converting to p3 colorspace, the negative blue value shows the color is out of gamut: color(display-p3 0.3265 0.9165 -0.1262) which in linear-light is color(display-p3-linear 0.0871 0.8205 -0.0146).

それを~P3色域へ~clipした結果は、 `color(display-p3 0.3265 0.9165 0)^v （光に線形な色~空間においては、 `color(display-p3-linear 0.0871 0.8205 0)^v ）になる。比較~用に，~OkLChにおいては、元の色は `oklch(80.72% 0.3296 141.6)^v, ~clipされた色は `oklch(80.79% 0.3221 142.3)^v になる。 ◎ Clipping the gamma-encoded p3 color to the p3 gamut gives color(display-p3 0.3265 0.9165 0) which in linear-light is color(display-p3-linear 0.0871 0.8205 0) which, for comparison, is oklch(80.79% 0.3221 142.3).

これは、良い結果になる — 色相と明度は，ほとんど変化しないが、色度は，期待されるとおりいくぶん抑制される。 ◎ This is a good result; the hue angle and lightness have barely changed but the chroma is somewhat reduced, as expected.

光に線形な色~空間において百分率に~~換算するなら、［ ~red, ~green ］は一致する一方で， ~blueは −1.46% 高くなる。 ◎ In terms of percentages of linear-light red green and blue, the red and green are identical while the blue is -1.46% higher.

例えば， `color(prophoto-rgb 0.2 1.0 0.1)^v を~gamma符号化された~P3色~空間へ変換した結果は、 `color(display-p3 -0.5782 1.067 -0.2363)^v （光に線形な色~空間においては、 `color(display-p3-linear -0.2937 1.158 -0.0456)^v ）になる — それは、色域から有意に外れる。 ◎ For example, consider the color color(prophoto-rgb 0.2 1.0 0.1) which is oklch(85.07% 0.4873 151.4) ◎ Converting to p3 colorspace, the color is significantly out of gamut: color(display-p3 -0.5782 1.067 -0.2363) which in linear-light is color(display-p3-linear -0.2937 1.158 -0.0456).

それを~P3色域へ~clipした結果は、 `color(display-p3 0 1 0)^v になる（光に線形な色~空間においても `color(display-p3-linear 0 1 0)^v になる — ［ 0 ／ 1 ］に等しい成分~値は、 ~gamma符号化により影響されないので）。比較~用に，~OkLChにおいては、元の色は `oklch(85.07% 0.4873 151.4)^v, ~clipされた色は `oklch(84.88% 0.3685 145.6)^v になる。 ◎ Clipping the gamma-encoded p3 color to the p3 gamut gives color(display-p3 0 1 0) which in linear-light is, again, color(display-p3-linear 0 1 0) (component values of exactly 0 or 1 are unaffected by gamma encoding) which, for comparison, is oklch(84.88% 0.3685 145.6).

これは，さほど良くないが、それでも，視覚的に受容-可能な結果を得る。ここでは、色相はもっと影響され， 5.8° 変化する。 ◎ A less good but still visually acceptable result. Here the hue is more affected, a 5.8° change.

光に線形な色~空間において百分率に~~換算するなら、 ~redは 57% 高くなり, ~greenは 6.7% 低くなり, ~blueは 23% 高くなる。 ◎ In terms of percentages of linear-light red green and blue, red is 57% higher, green is 6.7% lower and blue is 23% higher.

14.1.2. 最も近い色（最小~DeltaE）

もっと良い手法は、 `最小~DeltaE@ （略称 `MINDE^en ~FN） — 知覚的に一様な色~空間~内で，その`色域~内$にある最も近い色を見出すこと — により，色を対応付けることである。この技法の成否は、明瞭に［色域~対応付け色~空間の一様~度, 利用される~DeltaE関数の予測上の正確度］に依存する。 ◎ A better method is to map colors, in a perceptually uniform color space, by finding the closest in-gamut color (so-called minimum ΔE or MINDE). Clearly, the success of this technique depends on the degree of uniformity of the gamut mapping color space and the predictive accuracy of the deltaE function used.

【~FN 原文の表記は “MINDE” （ `MIN^en + `Delta E^en ）が主だが、この訳では “最小~DeltaE” を選好する。】

しかしながら，色域~対応付けを行うとき、色相における変化は，`特に^em異論が出易い — 色度における変化の方が，大目に見られ得る。あるいは、明度における小さな変化も — とりわけ、そうした方が色度~抑制が小さくなる場合には — 受容-可能になり得る。 `最小~DeltaE$は、各~次元における変化が等しくなることを重視するので，最適とは言えない結果を与える。 ◎ However, when doing gamut mapping changes in Hue are particularly objectionable; changes in Chroma are more tolerable, and small changes in Lightness can also be acceptable especially if the alternative is a larger Chroma reduction. MINDE weights changes in each dimension equally, and thus gives suboptimal results.

14.1.3. 色度~抑制

`最小~DeltaE$を実装するためには、所与の色は，知覚的に一様な`極-座標^em色~空間~内で［色相を一定に保持しながら，色が`色域~内$に入るまで色度を抑制する］ことにより対応付けられる。 ◎ To implement MINDE, colors are mapped in a perceptually uniform, polar color space by holding the hue constant, and reducing the chroma until the color falls in gamut.

これは、次のいずれかにより，`~algo的に行う^emこともできる： ◎ This could be done algorithmically by＼

［一定~明度, 一定~色相］が成す射線と色域~境界との幾何的な交点を見出す ◎ finding the geometric intersection of a constant-lightness, constant-hue ray with the gamut boundary;＼
色域~内に入るまで色度を`反復的^emに抑制する ◎ or iteratively, reducing the chroma until it falls in gamut.

注記：処理能の理由から、反復は，概して二分-探索により遂行される。 ◎ Note: For performance reasons, iteration is typically performed by binary search.

この例では、 ~Display-P3の原色~yellow（ `color(display-p3 1 1 0)^v ）が， ~sRGB~displayへ対応付けられる。色域~対応付け色~空間は~OkLChである。この色は、次に等しい ⇒ `color(srgb 1 1 -0.3463)^v — すなわち ⇒ `color(oklch 0.96476 0.24503 110.23)^v ◎ In this example, Display P3 primary yellow (color(display-p3 1 1 0)) is being mapped to an sRGB display. The gamut mapping color space is OkLCh. • color(display-p3 1 1 0) is • color(srgb 1 1 -0.3463) which is • color(oklch 0.96476 0.24503 110.23)

色域~対応付けが施された色は、色度~成分を［結果の色が~sRGB色域の内側に入る（どの成分も 0 以上 1 以下になる）まで，次第に抑制する］ことにより得される。その結果は ⇒ `color(oklch 0.96476 0.21094 110.23)^v — すなわち ⇒ `99.116% 99.733% 0.001%^rgb `color(srgb 0.99116 0.99733 0.00001)^v ◎ By progressively reducing the chroma component until the resulting color falls inside the sRGB gamut (has no components negative, or greater than one) a gamut mapped color is obtained. • color(oklch 0.96476 0.21094 110.23) which is • color(srgb 0.99116 0.99733 0.00001)

~OkLCh色~空間~内の一定な色相による断面。［縦~軸は明度／横~軸は色度］を表現する。 ~greenな線は、 ~sRGBの色域~境界を示す。 ~yellowな円は、対応付けられることになる色を示す — それは、色相と明度を一定に保ちながら色度は抑制される。したがって当の色は、図式~内の~maroonな線に沿って，左端にある中立な軸へ向けて【~greenな線に交差する所まで】移動する。 ◎ A constant-hue slice of OkLCh color space. The vertical axis represents lightness, the horizontal axis is chroma. The color to be mapped, shown as a yellow circle, has the chroma reduced while keeping hue and lightness constant. The color therefore moves along the maroon line in the diagram, towards the neutral axis on the left. The gamut boundary of sRGB is shown in green.

14.1.4. 過度な色度~抑制

この【前節の】単純な［ `最小~DeltaE$用の~approach ］は、ある種の色 — 主に、 ~yellowや~cyanの様な，ごく明な色 — に対しては，色域~境界の上辺が浅い場合に — あるいは少し凹んでいる場合でも — 最適とは言えない結果を与えることになる。それらの事例では、一定な明度が成す線が色域~境界の直上を掬い取り得るので，結果の色度は過度に低くなる。 ◎ Also, this simple MINDE approach will give sub-optimal results for certain colors, principally very light colors like yellow and cyan, if the upper edge of the gamut boundary is shallow, or even slightly concave. The line of constant lightness can skim just above the gamut boundary, resulting in an excessively low chroma in those cases.

どの色~空間を選ぶかは、色域~対応付けが施された色の受容-度に影響することになる。 ◎ The choice of color space will affect the acceptability of the gamut mapped colors.

この例では、 ~Display-P3内の原色~yellow（ `color(display-p3 1 1 0)^v ）の色度が — ~CIE~LCH色~空間~内で — 次第に抑制される。 ◎ In this example, Display P3 primary yellow (color(display-p3 1 1 0) has the chroma progressively reduced in CIE LCH color space.

この図式【横~軸が色度（以下の図式も同様）】の上部では、［ ~sRGB色域の内側にある色は，そのままに／ ~Display-P3色域の内側にある（が~sRGBの外側にある）色は~salmonで／ ~Display-P3色域の外側にある色は~redで］表示される。図式の下部は、 ~Display-P3における［ ~red, ~green, ~blue ］成分の［光に線形な強度］を示す。 ◎ In the upper part of this diagram, colors which are inside the gamut of sRGB are displayed as-is. Colors inside the gamut of Display P3 (but outside sRGB) are in salmon. Colors outside the gamut of Display P3 are in red. The lower part of the diagram shows the linear-light intensities of the Display P3 red, green and blue components.

~CIE~LCHにおける色度~抑制では、 ~red強度~曲線が上げられ，~Display-P3色域の外へ出ることが見てとれる。それが再び入る時点【図の右上隅から左へ~~辿って，曲線が色域を成す矩形に入る所】では、色度はごく低くなる。 ~CIE~LCHにおける単純な色域~対応付けは、不満な結果を与えることになろう。 ◎ It can be seen that reduction in CIE LCH chroma makes the red intensity curve up, out of Display P3 gamut; by the time it falls again the chroma is very low. Simple gamut mapping in CIE LCH would give unsatisfactory results.

この例では、 ~Display-P3内の原色~yellow（ `color(display-p3 1 1 0)^v ）の色度が — 今度は~OkLCh色~空間~内で — 次第に抑制される。 ◎ In this example, Display P3 primary yellow (color(display-p3 1 1 0) has the chroma progressively reduced, but this time in OkLCh color space.

この図式の上部では、［ ~sRGB色域の内側にある色は，そのままに／ ~Display-P3色域の内側にある（が~sRGBの外側にある）色は~salmonで／ ~Display-P3色域の外側にある色は~redで］表示される。図式の下部は、 ~Display-P3における［ ~red, ~green, ~blue ］成分の［光に線形な強度］を示す。 ◎ In the upper part of this diagram, colors which are inside the gamut of sRGB are displayed as-is. Colors inside the gamut of Display P3 (but outside sRGB) are in salmon. Colors outside the gamut of Display P3 are in red. The lower part of the diagram shows the linear-light intensities of the Display P3 red, green and blue components.

~OkLChにおける色度~抑制は、より良く挙動することが見てとれる。色は~Display-P3色域の外側へは行かず、色域~対応付けが施された結果の~yellowの色度は良いものになる。 ~OkLChにおける単純な色域~対応付けは、受容-可能な結果を与えることになろう。 ◎ It can be seen that reduction in OkLCh chroma is better behaved. Colors do not go outside the Display P3 gamut, and the resulting gamut-mapped yellow has good chroma. Simple gamut mapping in OK LCH would give acceptable results.

14.1.5. 局所的な~clip法を伴う色度~抑制

単純な色度~抑制~algoは、各~段にて［現在の対応付けられた色, その色を~clipした結果の色］の色~差を算出することで改善できる。現在の色が色域~境界の外側にあるが， ~clipした結果との色~差は、 `~JND@ （ `just noticeable difference^en, 【ヒトがぎりぎり気付き得る差】）用の閾値を下回る場合、対応付けた結果として，~clipした結果の色が返される。これは実質的には、［各~段階で`最小~DeltaE$による対応付けを行いつつ，色相と明度の変化はごく小さくなるよう拘束する］ので，気付かれ得るものにはならない。 ◎ The simple chroma-reduction algorithm can be improved: at each step, the color difference is computed between the current mapped color and a clipped version of that color. If the current color is outside the gamut boundary, but the color difference between it and the clipped version is below the threshold for a just noticeable difference (JND), the clipped version of the color is returned as the mapped result. Effectively, this is doing a MINDE mapping at each stage, but constrained so the hue and lightness changes are very small, and thus are not noticeable.

この例では、 ~Display-P3内の原色~yellow（ `color(display-p3 1 1 0)^v ）の色度が — ~CIE~LCH色~空間~内で，局所的な~clip改変を伴って — 次第に抑制される。 ◎ In this example, Display P3 primary yellow (color(display-p3 1 1 0) has the chroma progressively reduced in CIE LCH color space, with the local clip modification.

~CIE~LCHにおける色度~抑制でも、 ~redの強度~曲線が上げられ，~Display-P3色域の外へ出ることが見てとれる — とは言え、前よりは少なく，~sRGB境界はずっと素早く見出される。 ~CIE~LCHにおける［局所的な~clipを伴う色域~対応付け］は、受容-可能な結果を与えることになろう。 ◎ It can be seen that reduction in CIE LCH chroma still makes the red intensity curve up, out of Display P3 gamut; but less than before and the sRGB boundary is found much more quickly. Gamut mapping in CIE LCH with local clip would give acceptable results.

この例では、 ~Display-P3内の原色~yellow（ `color(display-p3 1 1 0)^v ）の色度が — 今度は~OkLCh色~空間~内で，局所的な~clipによる改変を伴って — 次第に抑制される。 ◎ In this example, Display P3 primary yellow (color(display-p3 1 1 0) has the chroma progressively reduced, but this time in OkLCh color space and with the local clip modification.

~OkLChにおける色度~抑制は、それだけで，すでに良いものであったが、局所的な~clip改変により，更に改善されることが見てとれる。 ~CIE~LCHにおける［局所的な~clipを伴う単純な色域~対応付け］は、優秀な結果を与えることになろう。 ◎ It can be seen that reduction in OkLCh chroma, which was already good, is further improved by the local clip modification. Simple gamut mapping in CIE LCH with local clip would give excellent results.

14.1.6. 知覚的な一様~性からの逸脱：色相の曲線~性

色域~対応付けを~CIE~LCH色~空間において遂行した結果は、色相~範囲 270° 以上 330° 以下の色に対しては，最適とは言えないことが既知である — ~DeltaE 2000 距離~計量をもってしても，有意な色相ズレを伴うので。 ◎ Performing gamut mapping in the CIE LCH color space even with the deltaE2000 distance metric, is known to give suboptimal results with significant hue shifts, for colors in the hue range 270° to 330°.

~CIE~LCH色~空間~内の一定な色相 — ~sRGB原色~blueに対応している色相~角度 301.37° — による断面。縦~軸は明度, 横~軸は色度。色度 25 〜 75 の間は，色相の~purple化が目立つ — 100 〜 131 の間に，~blue化していく。同じ現象は 131 を過ぎても継続するが、 ~sRGB~displayでは示し得ない。 ◎ A constant-hue slice of CIE LCH color space, at a hue angle of 301.37° corresponding to sRGB primary blue. The vertical axis is Lightness, the horizontal axis is Chroma. Between chroma of 25 and 75, the hue is visibly purple, becoming more blue between 100 and 131. The same phenomenon continues past 131, but cannot be shown on an sRGB display.

この課題は、［ ~OkLCh色~空間と~DeltaE~OK距離~計量］を利用することで，すべての色相~角度において避けられる。 ◎ Using OkLCh color space and the deltaEOK distance metric avoids this issue at all hue angles.

~OkLCh色~空間~内の一定な色相 — ~sRGB原色~blueに対応している色相~角度 264.06° — による断面。縦~軸は明度, 横~軸は色度。すべての — 0.315 （この色相における~sRGBの上限）までの — 色度において、色相は同じ視覚になる。この一定さは，そこを超えても継続するが、 ~sRGB図式では示し得ない。 ◎ A constant-hue slice of OkLCh color space, at a hue angle of 264.06° corresponding to sRGB primary blue. The vertical axis is Lightness, the horizontal axis is Chroma. The hue is visibly the same at all values of chroma, up to 0.315 (the sRGB limit at this hue). It continues to be constant beyond this point, although that cannot be shown on an sRGB diagram.

14.2. ~CSSにおける~RGB行先への色域~対応付け

以下に与える各種 `~CSS色域~対応付け~algo@ は、個々の［ ~SDR（ `Standard Dynamic Range^en, “標準~可動~範囲” ）~CSS色］のうち［ ~RGB~displayの色域~外にあるので `~CSS色域~対応付け@ が要求されるもの］に適用される。 ◎ The three CSS gamut mapping algorithms apply to individual, Standard Dynamic Range (SDR) CSS colors which are out of gamut of an RGB display and thus require to be css gamut mapped.

実装は、次に挙げる 3 種の~algoのうちどれを選んでもヨイ — それらの［品質, 稼働時の効率］の~tradeoffに基づいて。実装は、 ~CSSが色域~対応付けを遂行するよう義務付ける所では，自身が選んだ~algoを【一貫して？】利用するモノトスル。 ◎ Implementations my choose any of the three algorithms based on their quality and runtime efficiency tradeoffs, and must use their chosen algorithm wherever CSS mandates that gamut mapping be performed.

`局所的な最小~DeltaEを伴う二分-探索による色域~対応付け＠#GMA-Binary-local-MINDE$ ◎ Binary Search Gamut Mapping with Local MINDE
`~EdgeSeekerによる色域~対応付け＠#GMA-EdgeSeeker$ ◎ EdgeSeeker Gamut Mapping
`射線~traceによる色域~対応付け＠#GMA-Raytrace$ ◎ Ray Trace Gamut Mapping

これらの~algoは、いずれも： ◎ ↓

`相対~色計量~意図$を実装する — したがって、行先~色域の内側にある色を変更しない。 ◎ They all implement a relative colorimetric intent, thus colors inside the destination gamut are unchanged.

注記：他の状況における色域~対応付けは — 特に、最大~黒~levelが 0 より有意に上にある印刷機の場合は — 異なる~algoが要求されることになる。それは、［黒色点, 白色点］どちらも揃える — その結果は、ごく［明な／暗な］色に対し［色度が抑制されるに伴い，明度の変化も伴う］ことになる。 ◎ Note: other situations, in particular mapping to printer gamuts where the maximum black level is significantly above zero, will require different algorithms which align the respective black and white points, which will result in lightness changes for very light and very dark colors as chroma is reduced..

注記：これらの~algoは、［個々の, 別個な色］用である — 画像に対しては、［隣り合う画素どうしの関係性が重要であり，細部と質感を保全することを目指す］ので，知覚的な描画~意図の方が適切になる【 `perceptual$v を見よ】 — その事例では、行先~色域の内側にある色も変化し得ることになる。 ◎ Note: these algorithms are for individual, distinct colors; for color images, where relationships between neighboring pixels are important and the aim is to preserve detail and texture, a perceptual rendering intent is more appropriate and in that case, colors inside the destination gamut could be changed.
`~OkLCh色~空間$において［一定~明度, 一定~色相］な色度~抑制を目指す。 ◎ All three CSS gamut mapping algorithms aim at constant-lightness, constant-hue chroma reduction in the OkLCh color space.
明度~軸~上で範囲~外にある色に対しては、［明度 ~GTE 1.0 ／明度 ~LTE 0.0 ］ならば，行先~色~空間~内の［ ~white／~black ］を返す。 ◎ For colors which are out of range on the Lightness axis, white is returned in the destination color space if the Lightness is greater than or equal to 1.0, while black is returned in the destination color space if the Lightness is less than or equal to 0.0.

14.2.1. 局所的な最小~DeltaEを伴う二分-探索による色域~対応付け

この二分-探索~algo用には、色~差~公式として`~DeltaE~OK$が利用され， `局所的な最小~DeltaE＠#GM-chroma-local-MINDE$による改善が利用される。探索における各~段においては、［現在の対応付けられた色, その色を~clipした結果］の`~DeltaE~OK$が算出される。 ◎ For this binary search algorithm, the color difference formula used is deltaEOK. The local-MINDE improvement is used. At each step in the search, the deltaEOK is computed between the current mapped color and a clipped version of that color.

現在の色が色域~境界の`外側^emにあるが［現在の色, それを~clipした結果］の`~DeltaE~OK$が`~JND$を下回る場合、 ~clipした結果の色が対応付けられた結果として返される。これは、良い結果を与える — 色相のズレは気付き得ないほど小さく，凹んだ色域~表面に近い所での過度な色度~抑制を避けるが、算出負荷は高くなり得る。 ◎ If the current color is outside the gamut boundary, but the deltaEOK between it and the clipped version is below a threshold for a just noticeable difference (JND), the clipped version of the color is returned as the mapped result. This gives good results with non-notivceable hue shifts, and avoids excessive chroma reduction near concave gamut surfaces, but can be computationally intensive.

1 `~JND$は、 ~OkLCh色~空間~用には，~OkLCh差 0.02 とする。 ◎ For the OkLCh color space, one JND is is an OkLCh difference of 0.02.

注記： ~DeltaE 2000 が利用される~CIE~Lab色~空間においては、明度~成分の範囲は 0 以上 100 以下であり， 1 ~JNDは 2 になる。 ~DeltaE~OKが利用される［ ~Oklab／~OkLCh ］においては、明度の範囲は 0 以上 1 以下なので， 1 ~JNDはその 100 分の 1 になる。 ◎ Note: In CIE Lab color space, where the range of the Lightness component is 0 to 100, using deltaE2000, one JND is 2. Because the range of Lightness in Oklab and OkLCh is 0 to 1, using deltaEOK, one JND is 100 times smaller.

注記：実験nの目的および各~実装を比較する目的で，局所的な最小~DeltaEを伴う二分-探索~色域~対応付け~algoの実装が［ `Coloriade^en ~library（~Python言語） `Coloraide-MINDE$r, `color.js^c ~library（~JS言語） `colorjs-MINDE$r ］において可用である。 ◎ Note: for the purposes of experimentation, and comparing implementations, implementations of the Binary Search with Local MINDE algorithm are available in the Coloriade library (in Python) [Coloraide-MINDE] and the color.js library (in JavaScript) [colorjs-MINDE].

14.2.2. 局所的な最小~DeltaEを伴う二分-探索による色域~対応付け用の見本~疑似-~code

`局所的な最小~DeltaEを伴う二分-探索~色域~対応付け~algo@ は、所与の ( 色~空間 %変換元~色~空間, %変換元~色~空間内の色 %変換元, 行先~色~空間 %行先~色~空間 ) に対し ⇒ ~RET 次の下位-手続きを遂行した結果を %行先~色~空間へ変換した結果 ◎ To Binary Search Gamut Map with Local MINDE a color origin in color space origin color space to be in gamut of a destination color space destination:

下位-手続きは、 ~OkLCh色~空間~内の色を返す： ◎ ↓↑

%行先~色域 ~LET %行先~色~空間の色域（［ ~HSL／~HWB ］の場合は~sRGB色域）に対応する~OkLCh色~空間~内の色域

【この段は、この訳による追加。原文の~algoは、［ ~OkLCh色~空間と行先~色~空間］との間の相互~変換が，至る所で暗黙的に行われている — この訳では、原文における入力 “%行先” を %行先~色~空間と %行先~色域に分けることにより，それを明示的に表現するよう試みる。】
%現在の色 ~LET %変換元を~OkLCh色~空間へ変換した結果 ◎ ↓
~IF［ %行先~色~空間には色域~制限sは無い~FN ］ ⇒ ~RET %現在の色

【~FN すなわち、 %行先~色域は~OkLCh色域に一致する（例：~CIE~XYZ, ~Lab, ~LCH, ~Oklab, ~OkLCh）】
◎ if destination has no gamut limits (XYZ-D65, XYZ-D50, Lab, LCH, Oklab, OkLCh) convert origin to destination and return it as the gamut mapped color ◎ ↑ let origin_OkLCh be origin converted from origin color space to the OkLCh color space
%alpha ~LET %現在の色の~alpha成分 ◎ ↓
~IF［ %現在の色の明度 ~GTE 100% ］ ⇒ ~RET `oklab(1 0 0 / alpha)^v ◎ if the Lightness of origin_OkLCh is greater than or equal to 100%, convert `oklab(1 0 0 / origin.alpha)` to destination and return it as the gamut mapped color
~IF［ %現在の色の明度 ~LTE 0% ］ ⇒ ~RET `oklab(0 0 0 / alpha)^v ◎ if the Lightness of origin_OkLCh is less than than or equal to 0%, convert `oklab(0 0 0 / origin.alpha)` to destination and return it as the gamut mapped color
~IF［ %現在の色は %行先~色域の内側にある］ ⇒ ~RET %現在の色 ◎ ↑↓ let inGamut(color) be a function which returns true if, when passed a color, that color is inside the gamut of destination. For HSL and HWB, it returns true if the color is inside the gamut of sRGB. ◎ if inGamut(origin_OkLCh) is true, convert origin_OkLCh to destination and return it as the gamut mapped color ◎ ↓↓ otherwise, let delta(one, two) be a function which returns the deltaEOK of color one compared to color two
%~JND ~LET 0.02 ◎ let JND be 0.02
%微小数 ~LET 0.0001 【この定数は、以下の算出を速く収束させるためにある。】 ◎ let epsilon be 0.0001
%~clipする ~LET 所与の ( ~OkLCh色~空間~内の色 %色 ) に対し，次を遂行する関数
1. %行先~色 ~LET %色を %行先~色~空間へ変換した結果
2. %行先~色を成す ~EACH( ~alpha以外の %成分 ) に対し ⇒ %行先~色の %成分 ~SET %成分の基準~範囲に切詰めた結果
3. ~RET %行先~色を~OkLCh色~空間へ変換した結果
◎ let clip(color) be a function which converts color to destination, clamps each component to the bounds of the reference range for that component and returns the result
%~clipした色 ~LET %~clipする( %現在の色 ) ◎ ↑↑ set current to origin_OkLCh ◎ set clipped to clip(current)
~IF［ ( %~clipした色, %現在の色 ) の`~DeltaE~OK$ ~LT %~JND ］ ⇒ ~RET %~clipした色 ◎ set E to delta(clipped, current) ◎ if E < JND • return clipped as the gamut mapped color
%最小 ~SET 0 ◎ set min to zero
%最大 ~SET %現在の色の~OkLCh色度 ◎ set max to the OkLCh chroma of origin_OkLCh
%最小は色域~内か ~LET ~T ◎ let min_inGamut be a boolean that represents when min is still in gamut, and set it to true
~WHILE［ %最大 ~MINUS %最小 ~GT %微小数］： ◎ while (max - min is greater than epsilon) repeat the following steps
1. %色度 ~SET ( %最小 ~PLUS %最大 ) ~DIV 2 ◎ set chroma to (min + max) /2
2. %現在の色の色度~成分 ~SET %色度 ◎ set the chroma component of current to chroma
3. ~IF［ %最小は色域~内か ~EQ ~T ］~AND［ %現在の色は %行先~色域の内側にある］：
  1. %最小 ~SET %色度
  2. ~CONTINUE
  ◎ if min_inGamut is true and also if inGamut(current) is true, set min to chroma and continue to repeat these steps ◎ otherwise, carry out these steps:
4. %~clipした色 ~SET %~clipする( %現在の色 ) ◎ set clipped to clip(current)
5. %~DeltaE ~LET ( %~clipした色, %現在の色 ) の`~DeltaE~OK$ ◎ set E to delta(clipped, current)
6. ~IF［ %~DeltaE ~LT %~JND ］：
  1. ~IF［ %~DeltaE ~GT %~JND ~MINUS %微小数］ ⇒ ~BREAK
  2. %最小は色域~内か ~SET ~F
  3. %最小 ~SET %色度
  ◎ if E < JND • if (JND - E < epsilon) return clipped as the gamut mapped color • otherwise, •• set min_inGamut to false •• set min to chroma
7. ~ELSE ⇒ %最大 ~SET %色度 ◎ otherwise, set max to chroma and continue to repeat these steps
~RET %~clipした色 ◎ return clipped as the gamut mapped color

14.2.3. ~EdgeSeekerによる色域~対応付け

~EdgeSeeker~algoは、幾何的な, および検索~表tに基づく~approachであり，元々は `Alexey Ardov^en 氏により `color.js^c ~library `colorjs-EdgeSeeker$r 用に開発された。 ◎ The EdgeSeeker algorithm is a geometric and lookup-table-based approach, originally developed by Alexey Ardov for the color.js library [colorjs-EdgeSeeker].

所与の色相に対し，色域~境界~断面が［曲な上部, 真直な下部］として表現される — 当の色相~用の色度が最も高い点を繋げて。 ◎ For any given hue, the gamut boundary slice is represented as a curved top section and a linear bottom section, joning at the highest chroma point for that hue.

【上部（ `top section^en ／ `upper portion^en）, 下部（ `bottom section^en ／ `lower part^en ）が何を意味するのかはっきりしない。】

この~algo用には、所与の~target~RGB空間~用に，ある検索~表t【！LUT】が構築される — それは、各~色相~断面に対し，色度が最も高い~OkLCh色を包含する。検索~表tを成す最も近い値どうしで線形な補間が利用されてから，色域~対応付けが施される色の正確な色相~用に色度が最も高い色を見積もる。 ◎ To initialize this algorithm, for a given target RGB space, a lookup table (LUT) is constructed containing the highest-chroma Oklch color on each hue slice. Linear interpolation between closest LUT values is used to then estimate the highest-chroma color for the exact hue of each color to be gamut mapped.

次に，一定~明度が成す射線と色域~境界との交点が計算される — それは、境界を成す（真直な）下部~用には高速であり，（曲な）上部でも，それなりに高速になる。 ◎ Intersection of the constant-lightness ray with the gamut boundary is then calculated, which is fast for the lower (linear) part of the boundary and still fairly fast for the upper (curved) portion.

これは、検索~表t用の~memoryと引き換えに，良い結果を与える。 ◎ This gives good results, at the expense of memory for the LUT.

14.2.4. ~EdgeSeekerによる色域~対応付け用の見本~疑似-~code

~EdgeSeeker色域~対応付け~algo用の疑似-~codeを追加する。 ◎ add pseudocode for EdgeSeeker GMA

14.2.5. 射線~traceによる色域~対応付け

射線~trace（ `Ray Trace^en ）~algoは、 ~RGB色域~対応付けへの［一定~明度を伴う高速な色度~抑制］用の幾何的な~approachである。それは、元々は `Isaac Muse^en 氏により， `Coloraide Python Library^en `Coloraide-Ray-Trace$r 用に開発された。 ◎ The Ray Trace algorithm is a geometric approach to RGB gamut mapping, for fast chroma reduction with constant lightness. It was originally developed by Isaac Muse for the Coloraide Python Library [Coloraide-Ray-Trace].

対応付けられる色は、まず，~OkLChへ変換される。次に，結果の色の無彩度な~versionが生成される — それが，中立な軸に乗る~anchorになる。これら 2 個の色は、 ~target~RGB空間を成す光に線形な~versionへ変換される。 ◎ The color to be mapped is first converted to Oklch, and then the achromatic version of that color is generated, which will be the neutral axis anchor. These two colors are then converted to the linear-light version of the target RGB space.

色域~境界は，今や軸に整列された立方なので、交点を見出す方が高速になる。 ◎ Because the gamut boundary is now an axis-aligned cube, finding the intersection is faster.

次に，~RGB立方の内側にある~anchor点から現在の色へ射線が投影され、 ~RGB色域~表面との交点が見出される — これが，当の色域へ対応付けられた色への 1 回目の近似になる。 ◎ A ray is cast from the inside of the RGB cube, from the anchor point to the current color. The intersection along this path with the RGB gamut surface is then found; this is the first approximation to the gamut mapped color.

~RGB空間は知覚的に一様でないので、［一定~色相かつ一定~明度］が成す射線は，~RGB空間においては曲な~pathになる。 ◎ As RGB spaces are not perceptually uniform, a constant hue, constant lightness ray is actually a curved path in RGB space.

1 回目の近似は、［知覚的な~OkLCh色~空間へ戻すよう変換してから，色度~抑制~曲線へ戻すよう射影する【すなわち，色相と明度を元の色と同じに戻す】］ことにより，その色相と明度を正す。正された色が，新たな現在の色になる — それは、色度~抑制~曲線【！the reduced chroma line】~上にある【最終結果に】ずっと近い色になるはずである。 ◎ The first approximation is converted back to Oklch to correct the color in the perceptual color space by projecting the point back onto the chroma reduction path, correcting the color’s hue and lightness. The corrected color becomes the new current color and should be a much closer color on the reduced chroma line.

以上の処理nをあと最大 3 回まで繰返す — 各回は、当の~path上の［より良い, より近い］色を見出すことになる。最後に，単純な~clip法を利用する【！to account for floating point math errors】。 ◎ This process is repeated (a maximum of three more times), each time finding a better, closer color on the path. Finally, simple clipping is used to account for floating point math errors.

その結果は，低い`~JND$を利用している`局所的な最小~DeltaEを伴う二分-探索＠#GMA-Binary-local-MINDE$に比肩するが、より予測-可能かつ一貫した時間の中で，ずっと高速に解決する。 ◎ The results are comparable to binary search with local MINDE using a low JND, but resolves much faster and within more predictable, consistent time.

~sRGB色域への射線~trace色域~対応付け： — 最大 4 回の反復にわたって近似される。画像（ © `Isaac Muse^en ）は、色度~抑制~曲線を示している。 ◎ Ray Trace gamut mpping to the sRGB gamut, showing the curved path of chroma reduction as approximated over a maximum of four iterations. Image copyright Isaac Muse.

注記：実験nの目的および各~実装を比較する目的で，射線~trace~algoの実装が［ `Coloriade^en ~library（~Python言語） `Coloraide-Ray-Trace$r, `color.js^c ~library（~JS言語） `colorjs-RayTrace$r ］において可用である。 ◎ Note: for the purposes of experimentation, and comparing implementations, implementations of the Ray Trace are available in the Coloriade library (in Python) [Coloraide-Ray-Trace] and the color.js library (in JavaScript) [colorjs-RayTrace].

14.2.6. 射線~trace色域~対応付け用の見本~疑似-~code

`射線~trace色域~対応付け~algo@ は、所与の ( 色~空間 %変換元~色~空間, %変換元~色~空間内の色 %変換元, 行先~色~空間 %行先~色~空間 ) に対し ⇒ ~RET 次の下位-手続きを遂行した結果を %行先~色~空間へ変換した結果 ◎ To Ray Trace Gamut Map a color origin in color space origin color space to be in gamut of an RGB destination color space destination:

下位-手続きは、 ~OkLCh色~空間~内の色を返す： ◎ ↓↑

%行先~色域 ~LET %行先~色~空間の色域（［ ~HSL／~HWB ］の場合は~sRGB色域）に対応する~OkLCh色~空間~内の色域

【この段は、この訳による追加（`局所的な最小~DeltaEを伴う二分-探索~色域~対応付け~algo$を見よ）。】
%元の~OkLCh色 ~LET %変換元を~OkLCh色~空間へ変換した結果 ◎ ↓
~IF［ %行先~色~空間には色域~制限sは無い（例：~CIE~XYZ, ~Lab, ~LCH, ~Oklab, ~OkLCh）］ ⇒ ~RET %元の~OkLCh色 ◎ if destination has no gamut limits (XYZ-D65, XYZ-D50, Lab, LCH, Oklab, OkLCh) convert origin to destination and return it as the gamut mapped color ◎ ↑ let origin_OkLCh be origin converted from origin color space to the OkLCh color space
%alpha ~LET %元の~OkLCh色の~alpha成分 ◎ ↓
~IF［ %元の~OkLCh色の明度 ~GTE 100% ］ ⇒ ~RET `oklab(1 0 0 / alpha)^v ◎ if the Lightness of origin_OkLCh is greater than or equal to 100%, convert `oklab(1 0 0 / origin.alpha)` to destination and return it as the gamut mapped color
~IF［ %元の~OkLCh色の明度 ~LTE 0% ］ ⇒ ~RET `oklab(0 0 0 / alpha)^v ◎ if the Lightness of origin_OkLCh is less than than or equal to 0%, convert `oklab(0 0 0 / origin.alpha)` to destination and return it as the gamut mapped color
~Assert： %行先~色~空間は、 ~RGB色~空間である【この段は、この訳による補完。】
%光に線形な~RGB空間 ~LET %行先~色~空間に対応する光に線形な色~空間 ◎ ↓ ◎ ↓ let l_origin be the OkLCh lightness component of origin_OkLCh ◎ ↓ let h_origin be the OkLCh hue component of origin_OkLCh
%~anchor ~LET ［ %元の~OkLCh色を複製して, その色度を 0 に設定した結果］を %光に線形な~RGB空間へ変換した結果 ◎ let anchor be an achromatic OkLCh color formed with l_origin as lightness, 0 as chroma and h_origin as hue, converted to the linear-light form of destination
%結果の~RGB色 ~LET %元の~OkLCh色を %光に線形な~RGB空間へ変換した結果 ◎ let origin_rgb be origin_OkLCh converted to the linear-light form of destination
~IF［ %結果の~RGB色は %光に線形な~RGB空間の色域~内にある］ ⇒ ~RET %元の~OkLCh色 ◎ if origin_rgb is not in gamut
%最低 ~LET 0.0 ~PLUS 1e-12 【 0.000000000001 】 ◎ • let low be 0.0 + 1E-12 1

注記：すべての成分は、同じ最小~値 0 を有すると見做される。 %最低は、単位~型【演算に利用する値~型】において相対的に小さくなるべきである。指定された値 1e-12 は 64 ~bit用であり， 32 ~bit用には 1e-6 を利用するべきである。 ◎ • ↓ #raytrace-footnote-1
%最高 ~LET 1.0 ~MINUS 1e-12 ◎ • let high be 1.0 - 1E-12 2

注記：すべての成分は、同じ値 1.0 で色域~内に入る最大が表現されると見做される。 ◎ • ↓ #raytrace-footnote-2
%i ~LET 0 ◎ • ↓ let last be origin_rgb
~WHILE［ %i ~LT 4 ］ ◎ • for (i=0; i<4; i++)
1. %~RGB色 ~LET %結果の~RGB色 ◎ ↑
2. ~IF［ %i ~NEQ 0 ］： ◎ • if (i > 0)
  1. %~OkLCh色 ~LET %結果の~RGB色を~OkLCh色~空間へ変換した結果 ◎ • let current_OkLCh be origin_rgb converted to OkLCh
  2. %~OkLCh色の明度 ~SET %元の~OkLCh色の明度 ◎ • let the lightness of current_OkLCh be l_origin
  3. %~OkLCh色の色相 ~SET %元の~OkLCh色の色相 ◎ • let the hue of current_OkLCh be h_origin 3
    
    注記：この段は、 %~OkLCh色が色度~抑制~曲線から逸脱した場合に，そこへ戻すよう配置する。 ◎ • ↓ #raytrace-footnote-3
  4. %~RGB色 ~SET %~OkLCh色を %光に線形な~RGB空間へ変換した結果 ◎ • let origin_rgb be current_OkLCh converted to the linear-light form of destination
3. %交点 ~LET `射線を投影する$( %~anchor, %~RGB色 ) ◎ • Cast a ray from start = anchor to end = origin_rgb and let intersection be the intersection of this ray with the gamut boundary
4. ~IF［ %交点 ~EQ ε ］ ⇒ ~BREAK ◎ • if an intersection was not found, let origin_rgb be last and exit the loop 5
  
  注記：これは、破局的な失敗~用に供される — そこでは、特定の, 知覚的な対応付け空間が（可視な波長分布の外側にある）途方もなく広~色域な色に因り完全に崩壊する。 ~CSSにおける色は、想像上のものでないならば，これを決して誘発しないものと期待される。 ◎ • ↓ #raytrace-footnote-5
5. ~IF［ %i ~NEQ 0 ］~AND［ %~RGB色を成すどの成分も %最低以上 %最高以下である］ ⇒ %~anchor ~SET %~RGB色 ◎ • if (i >0) AND (each component of origin_rgb is between low and high) then let anchor be origin_rgb 4
  
  注記：これは， %~RGB色が色域~表面の下にある【色域に入る？】ことを意味するので、それを色域~表面により近い~anchorとして利用する。 ◎ • ↓ #raytrace-footnote-4
  
  【この段は、 2つ前の段より先に遂行するべきに思われる。】
6. %結果の~RGB色 ~SET %交点 ◎ • let origin_rgb be intersection ◎ • ↑ let last be intersection
7. %i ~INCBY 1 ◎ ↑
%~clipする ~LET 所与の ( ~OkLCh色~空間~内の色 %色 ) に対し，次を遂行する関数
1. %行先~色 ~LET %色を %行先~色~空間へ変換した結果
2. %行先~色を成す ~EACH( ~alpha以外の %成分 ) に対し ⇒ %行先~色の %成分 ~SET %成分の基準~範囲に切詰めた結果
3. ~RET %行先~色を~OkLCh色~空間へ変換した結果
◎ let clip(color) be a function which converts color to destination, clamps each component to the bounds of the reference range for that component and returns the result
%~clipした色 ~LET %~clipする( %結果の~RGB色を~OkLCh色~空間へ変換した結果 ) ◎ set clipped to clip(origin_rgb)
~RET %~clipした色 ◎ return clipped as the gamut mapped color

`射線を投影する@ ~algoは、所与の ( %始端, %終端 ) に対し，光に線形な~RGB空間における %始端から %終端への射線と~RGB色域の立方な色域~表面との交点を返す — 以下の演算においては、［ %始端, %終端, %結果］は，順に［ R, G, B ］成分の値が成す`~list$であるものとして扱われる： ◎ To cast a ray through a linear-light RGB space from start to end (in gamut mapping, start is an anchor within the RGB gamut and end is the gamut mapped color, on the cubical gamut surface):

%最小 ~LET 順に，当の色域の［ R, G, B ］成分の下界を与える値たちが成す~list ◎ ↓
%最大 ~LET 順に，当の色域の［ R, G, B ］成分の上界を与える値たちが成す~list ◎ let bmin and bmax be 3-element arrays with the gamut’s lower and upper bounds, respectively 6

注記：代表的な~RGB空間においては、各~成分~用の下界は 0, 上界は 1 なので，［ %最小, %最大］は単独の定数へ単純~化できる。 ◎ ↓ #raytrace-footnote-6
%正な無限大 ~LET 正な無限大（あるいは，何らかの巨大な正な実数） ◎ ↓↓
%遠 ~LET %正な無限大 ◎ let tfar be infinity (or some very large number)
%近 ~LET 負な無限大（あるいは，何らかの巨大な負な実数） ◎ let tnear be -infinity (or some very large, negative number)
%方向 ~LET « » ◎ let direction be a 3-element array
« 0, 1, 2 » を成す ~EACH( %i ) に対し： ◎ for (i = 0; i < 3; i++):
1. %a ~LET %始端[ %i ] ◎ let a be start [i]
2. %b ~LET %終端[ %i ] ◎ let b be end [i]
3. %d ~LET %b ~MINUS %a ◎ let d be b - a
4. %方向に %d を`付加する$ ◎ let direction [i] be d
5. ~IF［ `abs^op( %d ) ~GT 1e-12 ］： ◎ if abs(d) > 1E-12 7 ◎ • let inv_d be 1 / d
  
  注記：値は単位~型【演算に利用する値~型】において相対的に小さくなるべきである。指定された値 1e-12 は 64 ~bit用であり， 32 ~bit用には 1e-6 を利用するべきである。 ◎ ↓ #raytrace-footnote-7
  1. %t1 ~LET ( %最小[ %i ] ~MINUS %a ) ~DIV %d ◎ let t1 be (bmin [i] - a ) * inv_d
  2. %t2 ~LET ( %最大[ %i ] ~MINUS %a ) ~DIV %d ◎ let t2 be (bmax [i] - a ) * inv_d
  3. %近 ~SET `max^op( `min^op( %t1, %t2 ), %近 ) ◎ let tnear be max(min(t1, t2), tnear )
  4. %遠 ~SET `min^op( `max^op( %t1, %t2 ), %遠 ) ◎ let tfar be min(max(t1, t2), tfar )
6. ~ELIF［ %a ~LT %最小[ %i ] ］~OR［ %a ~GT %最大[ %i ] ］ ⇒ ~RET ε ◎ else if (a < bmin[i] or a > bmax[i]) • return INTERSECTION NOT FOUND
~IF［ %近 ~GT %遠］~OR［ %遠 ~LT 0 ］ ⇒ ~RET ε ◎ if (tnear > tfar or tfar < 0) • return INTERSECTION NOT FOUND
~IF［ %近 ~LT 0 ］ ⇒ %近 ~SET %遠 ◎ if tnear < 0 • let tnear be tfar 7

注記： %始端から %終端への方向において最初の交点を~~優先する。 ◎ ↓ #raytrace-footnote-8
~IF［ %近 ~GT %正な無限大］ ⇒ ~RET ε ◎ if tnear is infinite (or matches the initial very large value) • return INTERSECTION NOT FOUND
%結果 ~LET « » ◎ ↓
« 0, 1, 2 » を成す ~EACH( %i ) に対し ⇒ %結果に次の結果を`付加する$ ⇒ %始端[ %i ] ~PLUS %方向[ %i ] ~MUL %近 ◎ for (i =0; i < 3; i++): • let result [i] be start [i] + direction [i] * tnear
~RET %結果 ◎ return result

14.2.6.1. 射線~trace~algo用の脚注

【この節を成す内容は、 `§ 前節の~algo＠#pseudo-raytrace$ 内の各所へ注記として移動した。】

◎ #raytrace-footnote-1 It is assumed the minimum value is 0 and that all channels have the same minimum. The value should be small relative to the unit type. The specifed value of 1e-12 is for 64-bit, but for 32-bit, 1e-6 should be used. ◎ #raytrace-footnote-2 1.0 represents the maximum in-gamut channel value, and it is assumed all channels have the same maximum. ◎ #raytrace-footnote-3 This places the current color back on the chroma reduction curve, if it has deviated. ◎ #raytrace-footnote-4 This means origin_rgb is below the gamut surface, so we use it as an anchor closer to the gamut surface. ◎ #raytrace-footnote-5 This is provided for catastrophic failures where a specific, perceptual mapping space completely breaks down due to ridiculously wide colors (outside the visible spectrum). It is expected that non-imaginary colors in CSS should never trigger this. ◎ #raytrace-footnote-6 For typical RGB spaces where the gamut bounds are 0 and 1 for each component this simplifies to a single constant rather than a 3-element array. ◎ #raytrace-footnote-7 The value should be small relative to the unit type. The specifed value of 1e-12 is for 64-bit, but for 32-bit, 1e-6 should be used. ◎ #raytrace-footnote-8 favoring the first intersection in the direction start -> end .

15. `color$t 値の解決-法

他が指定されない限り，特定0の~propに`指定され$た色は、以下に述べるとおりに， `算出d色@ と呼ばれる`算出d値$に解決され, さらに `使用~色@ と呼ばれる`使用~値$に解決される。 ◎ Unless otherwise specified for a particular property, specified colors are resolved to computed colors and then further to used colors as described below.

`color$t の`解決d値$は、 `使用~値$と同じになる。 ◎ The resolved value of a <color> is its used value.

15.1. ~sRGB値の解決-法

この節は、次に挙げる値に適用される ⇒＃ `~hex色$, `rgb$f, `rgba$f, `hsl$f, `hsla$f, `hwb$f, `named-color$t【！`有名~色$】, ◎ This applies to: • hex colors • rgb() and rgba() values • hsl() and hsla() values • hwb() values • named colors

次に挙げる値には`適用されない^em ⇒ `color$f 値のうち［ `srgb$v ／ `srgb-linear$v ］色~空間を利用するもの ◎ It does not apply to: • color() values using the srgb or srgb-linear color spaces.

作者により明示的に `named-color$t として指定された~sRGB色の： ◎ If the sRGB color was explicitly specified by the author as a named color,＼

`宣言d値$は、当の名前を`~ASCII小文字~化$した結果になる。 ◎ the declared value is that named color, converted to ASCII lowercase.＼
［ `算出d値$／`使用~値$ ］は、次が成す~pairになる：
- 対応する~sRGB色
- 指定された~alpha成分（ 0 以上 1 以下に切詰めた後における） — 未指定な場合の既定は、不透明になるとする。
◎ The computed and used value is the corresponding sRGB color, paired with the specified alpha component (after clamping to [0, 1]) and defaulting to opaque if unspecified).

作者により供された［文字大小が混在した形 `pUrPlE^v ］用の指定d値は、すべて小文字化された `purple^swatch `purple$vN になる。 ◎ The author-provided mixed-case form below has a declared value in all lowercase. • pUrPlE • purple

他の場合の［ `宣言d値$／`算出d値$／`使用~値$ ］は、次が成す~pairになる：

対応する~sRGB色
指定された~alpha成分（ 0 以上 1 以下に切詰めた後における） — 未指定な場合の既定は、不透明になるとする。

◎ Otherwise, the declared, computed and used value is the corresponding sRGB color, paired with the specified alpha component (after clamping to [0, 1]) and defaulting to opaque if unspecified).

歴史的な理由から、 ~sRGB色~内の `calc$f が単独の値に解決されるときは、宣言d値は， `calc(^l と `)^l で包装されずに直列化される。 ◎ For historical reasons, when calc() in sRGB colors resolves to a single value, the declared value serialises without the "calc(" ")" wrapper.

例えば，ある色が `128 127 255^rgb `rgb(calc(64 * 2) 127 255)^v として与えられた場合、宣言d値は `rgb(128 127 255)^v になり， `rgb(calc(128) 127 255)^v にはならない。 ◎ For example, if a color is given as rgb(calc(64 * 2) 127 255) the declared value will be rgb(128 127 255) and not rgb(calc(128) 127 255).

例えば，ある色が `255 165.2 0^rgb `hsl(38.82 calc(2 * 50%) 50%)^v として与えられた場合、宣言d値は `rgb(255 165.2 0)^v になる — ~HSLから~RGBへの変換の間に `calc$f は失われるので。 ◎ For example, if a color is given as hsl(38.82 calc(2 * 50%) 50%) the declared value will be rgb(255 165.2 0) because the calc() is lost during HSL to RGB conversion.

歴史的な理由から、 `calc^f が単独の値に単純~化されるときには， 0.0 以上 255.0 以下に切詰められる。 ◎ Also for historical reasons, when calc() is simplified down to a single value, the color values are clamped to [0.0, 255.0].

例えば，ある色が `255 127 0^rgb `rgb(calc(100 * 4) 127 calc(20 - 35))^v として与えられた場合、宣言d値は `rgb(255 127 0)^v になり， `rgb(calc(400) 127 calc(-15))^v にはならない。 ◎ For example, if a color is given as rgb(calc(100 * 4) 127 calc(20 - 35)) the declared value will be rgb(255 127 0) and not rgb(calc(400) 127 calc(-15)).

この切詰ngは、［ `infinity$v ／ `-infinity$v ／ `NaN$v ］などの値も~careする — これらは［ 255 ／ 0 ／ 0 ］に切詰められることになる。 ◎ This clamping also takes care of values such as Infinity, -Infinity, and NaN which will clamp at 255, 0 and 0 respectively.

例えば， `hsl(38.824 100% 50%)^v の算出d値は ⇒ `255 165 0^rgb `rgb(255 165 0)^v ◎ For example, the computed value of • hsl(38.824 100% 50%) is • rgb(255, 165, 0)

15.2. ~Lab値／~LCH値の解決-法

この節は、次に挙げる値に適用される ⇒＃ `lab$f, `lch$f ◎ This applies to lab() and lch() values.

［ `宣言d値$／`算出d値$／`使用~値$ ］は、次が成す~pairになる：

対応する~CIE［ ~Lab／~LCH ］色（ L, C, H を切詰めた後における）
指定された~alpha成分 ⇒＃ `percentage$t ではなく `number$t になるとする／未指定な場合の既定は、不透明になるとする

◎ The declared, computed and used value is the corresponding CIE Lab or LCH color (after clamping of L, C and H) paired with the specified alpha component (as a <number>, not a <percentage>; and defaulting to opaque if unspecified).

例えば， `lch(52.2345% 72.2 56.2 / 1)^v の算出d値は ⇒ `77.61% 36.34% 2.45%^rgb `lch(52.2345% 72.2 56.2)^v ◎ For example, the computed value of • lch(52.2345% 72.2 56.2 / 1) is • lch(52.2345% 72.2 56.2)

［ a, b, C ］成分の値は、理論的には~~限界は無いが， `無限大へ近付く値~用の実装定義な上限$があり得る。 ◎ Although the values of a, b and C are theoretically unbounded, there may be an implementation-defined limit for values approaching infinity.

15.3. ~Oklab／~OkLCh値の解決-法

この節は、次に挙げる値に適用される ⇒＃ `oklab$f, `oklch$f ◎ This applies to oklab() and oklch() values.

［ `宣言d値$／`算出d値$／`使用~値$ ］は、次が成す~pairになる：

対応する［ ~Oklab／~OkLCh ］色（ L, C, H を切詰めた後における）
指定された~alpha成分（ `percentage$t としてではなく， `number$t として） — 未指定な場合の既定は、不透明になるとする

◎ The declared, computed and used value is the corresponding Oklab or OkLCh color (after clamping of L, C and H) paired with the specified alpha component (as a <number>, not a <percentage>; and defaulting to opaque if unspecified).

例えば， `50.2% 0.7% 49.9%^rgb `oklch(42.1% 0.192 328.6 / 1)^v の算出d値は ⇒ `oklch(42.1% 0.192 328.6)^v ◎ For example, the computed value of • oklch(42.1% 0.192 328.6 / 1) is • oklch(42.1% 0.192 328.6)

15.4. `color$f 関数~値の解決-法

［ `宣言d値$／`算出d値$／`使用~値$ ］は、次が成す~pairになる：

指定された`色~空間$内の色
指定された~alpha成分 ⇒＃ `percentage$t ではなく `number$t になるとする／未指定な場合の既定は、不透明になるとする

◎ The declared, computed and used value is the color in the specified color space, paired with the specified alpha component (as a <number>, not a <percentage>; and defaulting to opaque if unspecified).

例えば， `color(display-p3 0.823 0.6554 0.2537 / 1)^v の算出d値は ⇒ `goldenrod^swatch `color(display-p3 0.823 0.6554 0.2537)^v ◎ For example, the computed value of • color(display-p3 0.823 0.6554 0.2537 /1) is • color(display-p3 0.823 0.6554 0.2537)

`xyz$v `色~空間$ （それは、 `xyz-d65$v 色~空間の別名である）内に指定された色~用の［算出d値, 使用~値］は、どちらも， `xyz-d65$v `色~空間$内になる。 ◎ For colors specified in the xyz color space, which is an alias of the xyz-d65 color space, the computed and used value is in the xyz-d65 color space.

例えば， `95.1% 53.3% 33%^rgb `color(xyz 0.472 0.372 0.131)^v の算出d値は ⇒ `95.1% 53.3% 33%^rgb `color(xyz-d65 0.472 0.372 0.131)^v ◎ For example, the computed value of • color(xyz 0.472 0.372 0.131) is • color(xyz-d65 0.472 0.372 0.131)

［ r, g, b, x, y, z ］成分の値は、理論的には~~限界は無いが， `無限大へ近付く値~用の実装定義な上限$があり得る。 ◎ Although the values of r, g, b, x, y and z are theoretically unbounded, there may be an implementation-defined limit for values approaching infinity.

15.5. その他の色の解決-法

この節は、次に挙げる値に適用される ⇒＃ `system-color$t【！`~system色$】, `deprecated-color$t【！非推奨にされた~system色】, `transparent$v, `currentcolor$v ◎ This applies to • system colors, • deprecated system colors • transparent • currentcolor.

作者により明示的に［ `system-color$t ／ `deprecated-color$t ］として指定された色の： ◎ If the color was explicitly specified by the author as a system color or as a deprecated system color,＼

`宣言d値$は、当の名前を`~ASCII小文字~化$した結果になる。 ◎ the declared value is itself, converted to ASCII lowercase.
例えば，次の~HTMLにおいては： ◎ For example, in this html:
```
<mark style="color: `MarkText^swatch MarkText; background: `Mark^swatch Mark">example</mark>
```
`background-color^p 用の宣言d値は "`mark^v" になる。 ◎ The declared value for background-color is "mark".
［ `算出d値$／`使用~値$ ］は、次が成す~pairになる：
- 当の色 — `deprecated-color$t の色は、 `§ 非推奨にされた~CSS~system色＠#deprecated-system-colors$にて挙げられたとおり，それに対応する `system-color$t の色 — が属する色~空間~内の対応する色
- 指定された~alpha成分（ 0 以上 1 以下に切詰めた後における）
◎ For system colors, the computed and used value is the corresponding color in its color space, paired with the specified alpha component (after clamping to [0, 1]). ◎ For deprecated system colors, the computed and used value is the color of the corresponding system color (as listed in Appendix A: Deprecated CSS System Colors) in its color space, paired with the specified alpha component (after clamping to [0, 1]).
例えば，次の~CSSが与えられたなら： ◎ For example, given this css:
```
.foo {
  color: `InfoText^swatch InfoText;
}
```
`InfoText$vD に対応している`~system色$は， `CanvasText$vS であり、その色が `#333^v と同じ色であったとするなら， `InfoText^v 用の算出d値も `#333^v の算出d値と同じになる。 ◎ The corresponding system color for InfoText is CanvasText. Suppose that CanvasText is #333; then the computed value for InfoText will also be #333;

例えば，次の~HTMLにおいては： ◎ For example, in this html:

<button style="color: `ButtonText^swatch ButtonText; background: `ButtonFace^swatch ButtonFace"></button>

`color^p ~propの宣言d値は `buttontext^l になる一方、算出d値は，例えば `#000^swatch `rgb(0, 0, 0)^v にもなり得る。 ◎ The declared value of the color property is "buttontext" while the computed value could be, for example, rgb(0, 0, 0).

しかしながら、［ `system-color$t ／ `deprecated-color$t ］による色は，`強制d色~mode$により改められないモノトスル。 ◎ However, system colors and deprecated system colors must not be altered by forced colors mode.

`transparent$v ~keywordの：

`宣言d値$は、 "`transparent^v" になる。
［ `算出d値$／`使用~値$ ］は、 `透明な黒$になる。

◎ The declared value of transparent is "transparent" while the computed and used value is transparent black.

`currentcolor$v ~keywordの： ◎ ↓

`算出d値$は、それ自身になる。 ◎ The currentcolor keyword computes to itself.
`使用~値$は：
- `color$p ~propにおいては、解決-済みな`継承d値$になる。
- 他の~propにおいては、同じ要素~上の `color$p ~propの使用~値になる。
◎ In the color property, the used value of currentcolor is the resolved inherited value. In any other property, its used value is the used value of the color property on the same element.

注記：すなわち， `currentcolor$v 値は、継承されるならば，~keywordとして継承される — `color$p ~propの値としてではなく。なので，子孫は、自前の `color$p ~propを利用して，それを解決することになる。 ◎ Note: This means that if the currentcolor value is inherited, it’s inherited as a keyword, not as the value of the color property, so descendants will use their own color property to resolve it.

次の~HTMLと： ◎ For example, given this html:

<div>
  <p>
    この例の~textは、長いので複数~行lに
    折返されることになると見做す。
  </p>
</div>

次の~CSSが与えられた下では： ◎ and this css:

div {
  color: `forestgreen^swatch forestgreen;
  text-shadow: currentcolor;
}
p {
  color: `mediumseagreen^swatch mediumseagreen;
}
p::firstline {
  color: `yellowgreen^swatch yellowgreen;
}

`整形される最初の行l$を成す断片に継承される~prop `text-shadow$p の使用~値は、 `yellowgreen^v になる。 ◎ The used value of the inherited property text-shadow on the first line fragment would be yellowgreen.

16. `color^t 値の直列化-法

この節は、 `CSSOM-1$r `§ ~CSS値の直列化-法＠~CSSOM1#serializing-css-values$の［ `color$t 値の直列化-法に関係する部分］を更新して置換する。 ◎ This section updates and replaces that part of CSS Object Model, section Serializing CSS Values, which relates to serializing <color> values.

この節に利用される文字列のうち： ◎ In this section, the strings used in the specification and the corresponding characters are as follows.

次に挙げるものに対応する文字は ⇒＃ ` ^l： `0020^U `SPACE^cn, `#^l： `0023^U `NUMBER SIGN^cn, `,^l： `002C^U `COMMA^cn, `-^l： `002D^U `HYPHEN-MINUS^cn, `.^l： `002E^U `FULL STOP^cn, `/^l： `002F^U `SOLIDUS^cn ◎ String｜Character " "｜U+0020 SPACE "#"｜U+0023 NUMBER SIGN ","｜U+002C COMMA "-"｜U+002D HYPHEN-MINUS "."｜U+002E FULL STOP "/"｜U+002F SOLIDUS
`none^l に対応する文字たちは ⇒ `006E^U `LATIN SMALL LETTER N^cn `006F^U `LATIN SMALL LETTER O^cn `006E^U `LATIN SMALL LETTER N^cn `0065^U `LATIN SMALL LETTER E^cn ◎ "none"｜U+006E LATIN SMALL LETTER N U+006F LATIN SMALL LETTER O U+006E LATIN SMALL LETTER N U+0065 LATIN SMALL LETTER E

~localeを問わず、小数点文字には `.^l を利用するものとする。また、桁を分離する~~記号（英語における `,^l など）は利用しないものとする。 ◎ The string "." shall be used as a decimal separator, regardless of locale, and there shall be no thousands separator.

`欠落~成分$を~supportする構文-形に対しては、値 `none$v （ `NONE^v, `nOnE^v, 等々も等価）は，すべて小文字~化した文字列 `none^l に直列化するモノトスル。 ◎ For syntactic forms which support missing color components, the value none (equivalently NONE, nOnE, etc), shall be serialized in all-lowercase as the string "none".

この節において実数で表現される~alpha値は、常に等価な百分率も包摂する（~alpha値 1 は、 1 または 100% が指定されたことを意味する）。【この規約は、この訳による追加（以下を簡潔に述べるため）。】

実数をある精度（十進記数法における小数部を成す桁数）までに `丸める@ ときは、 2 数に等しく近い場合には，正な無限大に近い方を選ぶとする。

【この段落は、この訳による補完（原文が参照している`丸める＠~CSSVAL#combine-integers$は、整数への丸ngを指していて正確aでないので）。また，原文では “+∞ へ向けて丸める（ `rounded towards +∞^en ）” と記されているが、一律な切り上げと紛らわしいので，単に “丸める” と記すことにする。】

16.1. ~alpha値の直列化-法

この節は、［ `color$t 値のうち，省略可能な~alpha値をとり得るもの］に適用される。この節は、 `opacity$p ~propには適用されない。 ◎ This applies to any <color> value which can take an optional alpha value. It does not apply to the opacity property.

~alphaは、 0 以上 1 以下に切詰めた後において，その値が：

1 ならば、 ~alphaは直列化した結果から省略される — それは、暗黙的な既定の値 1 （全に不透明）を表す。 ◎ If, after clamping to the range [0, 1] the alpha is 1, it is omitted from the serialization; an implicit value of 1 (fully opaque) is the default.
他の場合、直列化した結果に明示的に含まれる — 以下に述べるとおり。 ◎ If the alpha is any other value than 1, it is explicitly included in the serialization as described below.

歴史的な理由から、 ~alphaの直列化は，当の色が［ `旧来の色~構文$, `現代の色~構文$ ］どちらを利用して指定されたかに依存する。 ◎ For historical reasone, the serialization of alpha depends on whether the color was specified using legacy color syntax or modern color syntax.

16.1.1. 旧来の~alpha値の直列化-法

所与の~alpha値 %~alpha を直列化するときは、次の手続きを遂行した結果（ 0 以上 1 未満の実数）を — 現代の~alpha値の直列化-法と同じく — （ `percentage$t ではなく） `number$t として直列化するとする。 ◎ ↓

手続きは： ◎ ↓

~IF［ %~alpha は［ 0 以上 255 以下の整数（すなわち 8 ~bit 無符号~整数）］として内部的に表現される］： ◎ If the value is internally represented as an integer between 0 and 255 inclusive (i.e. 8-bit unsigned integer), follow these steps: • Let alpha be the given integer.
1. ~IF［次を満たす整数 %N が存在する］…
  - %N ~IN { 0 〜 100 }
  - ( %N ~MUL 2.55 ) を最も近い整数へ丸めた結果（ 2 つの値に等しく近い場合は切り上げる） ~EQ %~alpha
  …ならば ⇒ ~RET %N ~DIV 100
  ◎ If there exists an integer between 0 and 100 inclusive that, when multiplied with 2.55 and rounded to the closest integer (rounding up if two values are equally close), equals alpha, let rounded be that integer divided by 100.
2. ~RET 次の結果 ~DIV 1000 ⇒ ( %~alpha ~DIV 0.255 ) を最も近い整数へ丸める（ 2 つの値に等しく近い場合は切り上げる） ◎ Otherwise, let rounded be alpha divided by 0.255 and rounded to the closest integer (rounding up if two values are equally close), divided by 1000. ◎ ↑↑ Return the result of serializing rounded as a <number>.
~RET %~alpha ◎ Otherwise, return＼ ↑↑ the result of serializing the given value (as a <number>, not a <percentage>), the same as the modern alpha serialization.

~alphaが 8 ~bitな無符号~整数として格納される下では： ◎ ↓

~alpha値 237 に対しては、整数 93 が上の判定基準を満たす — `Math.round(93 * 2.55)^c の結果は 237 になるので。なので、 ~alphaは `0.93^l として直列化される。 ◎ For example, if the alpha is stored as the 8-bit unsigned integer 237, the integer 93 satisfies the criterion because Math.round(93 * 2.55) is 237, and so the alpha is serialized as "0.93".
~alpha値 236 に対しては、上の判定基準を満足する整数は無い（ 92 は 235 へ, 94 は 240 へ対応付けられる）。 236 ~DIV 0.255 は 925.490196078 になるので、 ~alphaは， `0.92549^l として直列化される（小数部は 6 桁までになり【その根拠は以下の記述を見よ】，尾部を成す 0 たちは省略される）。 ◎ However, if the alpha is stored as the 8-bit unsigned integer 236, there is no such integer (92 maps to 235 while 94 maps to 240), and so since 236 ÷ 0.255 = 925.490196078 the alpha is serialized as "0.92549" (no more than 6 figures, trailing zeroes omitted).

`旧来の色~構文$用には、 `alpha-value$t と伴に維持される精度は，少なくとも［整数をとる百分率~値が往復する］に足るようにするモノトスル。したがって、直列化した結果における小数部は — 尾部を成す 0 たちが除去された場合を除き — 2 桁以上になるモノトスル。値は、切捨てるのではなく，`丸める$モノトスル。 ◎ For legacy color syntax, the precision with which alpha values are retained, and thus the number of decimal places in the serialized value, must at least be sufficient to round-trip integer percentage values. Thus, the serialized value must contain at least two decimal places (unless trailing zeroes have been removed). Values must be rounded towards +∞, not truncated.

例えば，~alpha値 `12.3456789%^v は、次に挙げるどの文字列にも直列化され得る ⇒＃ `0.12^l ／ `0.123^l ／ `0.1234^l ／ `0.12346^l （ 5 は後続する数字が 6 なので 6 に切り上げられる）／もっと長い丸められた形 ◎ For example, an alpha value of 12.3456789% could be serialized as the strings "0.12" or "0.123" or "0.1234" or "0.12346" (rounding the value of 5 towards +∞ because the following digit is 6) or any longer, rounded serialization of the same form.

16.1.2. 現代の~alpha値の直列化-法

所与の~alpha値 %~alpha を直列化するときは、 %~alpha を（ `percentage$t ではなく） `number$t として直列化した結果を返す。 ◎ Return the result of serializing the given value (as a <number>, not a <percentage>).

`number$t 値を直列化するときは、次に従うモノトスル ⇒＃基数 10 で表出する。小数点文字には `002E^U （ `.^l ）を利用する。先頭の 0 は省略しない。尾部を成す 0 たちは省略する。 ◎ The <number> value is expressed in base ten, with the "." character as decimal separator. The leading zero must not be omitted. Trailing zeroes must be omitted.

例えば，~alpha値 70% は、文字列 `0.7^l に直列化されることになる。小数点文字は、現在の~localeが他の文字 — `002C^U （ `,^l ）など — を利用する場合でも， `002E^U （ `.^l ）になる。小数点文字の前には 1 個の 0 があり、 `7^l より後の数字は，すべて `0^l なので省略される。 ◎ For example, an alpha value of 70% will be serialized as the string "0.7" which has a leading zero before the decimal separator, "." as decimal separator (even if the current locale would use some other character, such as ","), and all digits after the "7" would be "0" and are omitted.

`現代の色~構文$用には、 `alpha-value$t と伴に維持される精度は，少なくとも［ 16 ~bitな値が往復する］に足るようにすることが要求される。直列化した結果における小数部は — 尾部を成す 0 たちが除去された場合を除き — 6 桁【6 桁以上？】になるモノトスル。値は、切捨てるのではなく，`丸める$モノトスル。 ◎ For modern color syntax, the precision with which <alpha-value>s are retained, and thus the number of decimal places in the serialized value, is required to be sufficient to round-trip 16-bit decimal values. ◎ The serialized value must contain six decimal places (unless trailing zeroes have been removed). ◎ Values must be rounded towards +∞, not truncated.

例えば，~alpha値 `12.3456789%^v は、丸められ，文字列 `0.123457^l に直列化されることになる。 ◎ For example, an alpha value of 12.3456789% will be serialized as the string "0.123457" (rounding the value towards +∞).

例えば，色 `color(srgb 1 0 0 / 0.5)^v の~alpha値は、文字列 `0.5^l に直列化されることになる。精度 10 ~bitでしか格納されなかった場合、内部的な値は 512 ~DIV 1023 （約 0.50048875855, 有効数字 6 桁においては 0.500489 ）になる — それは、欲される値に近いが，正確ではない。 12 ~bitで格納した場合でも、 2048 ~DIV 4095 （約 0.50012210012, 有効数字 6 桁においては 0.500122 ）になり，依然として正確ではない。 ◎ For example, given the color color(srgb 1 0 0 / 0.5), the alpha value is to be serialized as the string "0.5". If it were stored at only 10-bit precision, the internal value would be 512/1023 which is 0.50048875855, or "0.500489" to six significant figures, close to the desired value but not exact. At 12-bit that would be 2048/4095 which is 0.50012210012, which is 0.500122 to six significant figures, still not exact.

それを 128 ~DIV 255 （約 0.50196078431, 有効数字 6 桁においては 0.501960 ）として格納することも，不正である。 ◎ It would also be incorrect to store it as 128/255 which is 0.50196078431, or 0.501960 to six significant figures.

累積的な丸誤差を避けるため、 ~alpha成分の内部~storage用には，［半精度（ 16 ~bit）／単精度］浮動小数点数が推奨される。 ◎ To avoid cumulative round-off errors, 16bit, half-float, or float per alpha component is recommended for internal storage.

妥当な範囲の外側に指定された `alpha-value$t は，構文解析-時に切詰められるので、その`宣言d値$は，切詰められることになる。しかしながら， `calc^f 【より一般には`~math関数$】を利用して指定された `alpha-value$t は、 `CSS-VALUES-4$r `§ 範囲の検査-法＠~CSSVAL#calc-range$ に従って ⇒＃宣言d値【！specified form】が直列化されるときは切詰められない。算出d値は切詰められる。 ◎ Because <alpha-value>s which were specified outside the valid range are clamped at parse time, the declared value will be clamped. However, per CSS Values 4 § 10.12 Range Checking, <alpha-value>s specified using calc() are not clamped when the specified form is serialized; but the computed values are clamped.

例えば，~alpha値が直に `120%^v として指定された場合、文字列 `1^l に直列化される。一方で， `calc(2*60%)^v として指定された場合、宣言d値は文字列 `calc(1.2)^l に直列化される。 ◎ For example an alpha value which was specified directly as 120% would be serialized as the string "1". However, if it was specified as calc(2*60%) the declared value would be serialized as the string "calc(1.2)".

16.2. ~sRGB値の直列化-法

次に挙げる~sRGB値を直列化したときの形は、 `宣言d値$から導出される：

`~hex色$
`rgb$f, `rgba$f
`hsl$f, `hsla$f
`hwb$f
`named-color$t【！`有名~色$】
`system-color$t【！`~system色$】
`deprecated-color$t【！§#deprecated-system-colors】
`transparent$v

◎ The serialized form of the following sRGB values: • hex colors • rgb() and rgba() values • hsl() and hsla() values • hwb() values • named colors • system colors • deprecated-colors • transparent ◎ is derived from the declared value.

作者によりこれらの値が設定された~propの値を直列化するときは：

`宣言d値$用には：
- 当の値が［ `named-color$t【！`有名~色$】／ `system-color$t【！`~system色$】／ `deprecated-color$t【！#deprecated-system-colors】／ `transparent$v ］である場合 ⇒ `~ASCII小文字~化$された~keyword値が維持される。
- 他の場合 ⇒ 対応する~sRGB値が利用される~FN。
［ `算出d値$／`使用~値$ ］用には ⇒ 対応する~sRGB値が利用される~FN。

【~FN `§ ~sRGB値の~CSS直列化$ に従う。】

したがって， `transparent$v を直列化した結果は ⇒＃宣言d値であったなら `transparent^l になる。算出d値であったなら `rgba(0, 0, 0, 0)^l になる。

◎ When serializing the value of a property which was set by the author to a CSS named color, a system color, a deprecated-color, or transparent therefore,＼ for the declared value, the ASCII lowercase keyword value is retained.＼ For the computed and used value, the corresponding sRGB value is used. ◎ Thus, the serialized declared value of transparent is the string "transparent", while the serialized computed value of transparent is the string "rgba(0, 0, 0, 0)". ◎ For all other sRGB values, the declared, computed and used value is the corresponding sRGB value.

`欠落~成分$が在る場合、直列化においては： ◎ During serialization,＼

直列化に選ばれた形が~keyword `none$v を表現し得ない場合（`旧来の色~構文$や`~sRGB値の~HTMLに互換な直列化＠#HTML-compatible-serialization-of-srgb$など）には、 `欠落~成分$は 0 へ変換される。 ◎ any missing values are converted to 0 if the chosen serialization form (such as the legacy color syntax with comma separators, or the HTML-compatible serialization of sRGB values) cannot represent the none keyword.＼
他の場合、 `欠落~成分$が `none$v として保全されるよう， `none$v を~supportする形が `§ ~sRGB値の~CSS直列化$ にて述べられるとおりに選ばれる。 ◎ When at least one component is missing and the value can be serialized in a form which supports none, the form is chosen as described in § 16.2.2 CSS serialization of sRGB values so that missing color components are preserved as none.

16.2.1. ~sRGB値の~HTMLに互換な直列化

~sRGB色~空間~内の ~AND↓ を満たす値に対し： ◎ If the following conditions are all true: • The color space is sRGB

~alpha ~EQ 1 ◎ The alpha is 1
~RGB成分~値は、内部的に，整数 ~IN { 0 〜 255 }（すなわち， 8 ~bitな無符号~整数）として表現される ◎ The RGB component values are internally represented as integers between 0 and 255 inclusive (i.e. 8-bit unsigned integer)

…に対し， `~HTMLに互換な直列化が要請され@ た場合、結果は，次に従う 6 桁の`~hex色$になるとする ⇒ 文字 `#^l に［ ~red, ~green, ~blue ］成分が順に後続する 7 文字からなる文字列 — 各~成分は、 2 桁で表現され，`~ASCII~hex数字（小文字）$を利用するとする。 ~spaceは許可されない。 ◎ • HTML-compatible serialization is requested ◎ Then corresponding sRGB values are serialized in 6-digit hex color notation as follows: ◎ A seven-character string consisting of the character "#", followed immediately by the two-digit hexadecimal representations of the red component, the green component, and the blue component, in that order, using ASCII lower hex digits. No spaces are permitted.

例えば、【 `CanvasRenderingContext2D＠~HEcanvas#canvasrenderingcontext2d$c ~APIにより，】 ~fill~styleが `255 0 255^rgb ~magentaに設定された場合： ◎ For example, fill style is set to magenta:

%context.fillStyle = "rgb(255, 0, 255)"
console.log(%context.fillStyle); // "#ff00ff"

これは ⇒＃色~空間は~sRGB, 表現は成分ごとに 8 ~bit, `none$v 値を生産しない, ~data形式は拡張された範囲による値を~supportしない, ~alpha ~EQ 1 ◎ The color space is sRGB, the representation is 8 bits per component, the data format does not produce none values nor does it support extended range values, and the alpha is 1.

よって、 ~HTMLに互換な直列化は，文字列 `#ff00ff^l になる（ `#FF00FF^l ではなく）。 ◎ The HTML-compatible serialization is the string "#ff00ff" (not "#FF00FF").

他の場合、 `color$t 値の直列化は ⇒＃ ~sRGB用には `§ ~sRGB値の~CSS直列化$に従う。他の色~空間~用には関連な`直列化＠#serializing-color-values$に従う。 ◎ Otherwise, for sRGB the CSS serialization of sRGB values is used and for other color spaces, the relevant serialization of the <color> value.

例えば、 ~fill~styleが~CIE~Lab内の `48.63% 13.85% 15.73%^rgb 暗な~brownに設定された場合： ◎ For example, fill style is set to a dark brown, in CIE Lab:

%context.fillStyle = "lab(29% 39 20)";
console.log(%context.fillStyle); // "lab(29 39 20)"

~CSS直列化は、文字列 `lab(29 39 20)^l になる。 ◎ The CSS serialization is the string "lab(29 39 20)".

例えば、 ~fill~styleが `#ff00ffed^swatch 半~透明な~magentaに設定された場合： ◎ For example, fill style is set to semi-transparent magenta:

%context.fillStyle = "#ff00ffed";
console.log(%context.fillStyle); // "rgba(255, 0, 255, 0.93)"

~alpha ~NEQ 1 なので、 ~CSS直列化は，文字列 `rgba(255, 0, 255, 0.93)^l になる。 ◎ The alpha is not 1, so the CSS serialization is the string "rgba(255, 0, 255, 0.93)".

16.2.2. ~sRGB値の~CSS直列化

~sRGB値は、 `欠落~成分$を有さない場合には，（切詰められた結果の）~alphaが正確に 1 になるか否かに依存して［ `rgb$f, `rgba$f ］いずれかの形を利用する — 関数の名前は、 `~ASCII小文字~化$される。 ◎ If the value has no missing color components, corresponding sRGB values use either the rgb() or rgba() form (depending on whether the (clamped) alpha is exactly 1, or not), with all ASCII lowercase letters for the function name.

互換性を得るため、この場合の~sRGBの直列化においては： ◎ ↓

各~色~成分は、 `number$t になるとする — `percentage$t ではなく。 ◎ For compatibility, the sRGB component values are serialized in <number> form, not <percentage>.＼
各~色~成分は、基数 10 で範囲 0 以上 255 以下になるとする — どの~bit深度で格納されたかに関わらず。 ◎ Also for compatibility, the component values are serialized in base 10, with a range of [0-255], regardless of the bit depth with which they are stored.
~alpha値 1 は、 `§ ~alpha値の直列化-法$に注記したとおり，明示的に直列化されない。 ~alpha値に応じて，次の形を利用するとする ⇒＃ 1 ならば `rgb$f （~alphaは暗黙的）／ ~ELSE_ `rgba$f （明示的な~alpha値を伴う） ◎ As noted earlier, unitary alpha values are not explicitly serialized. Also, for compatibility, if the alpha is exactly 1, the rgb() form is used, with an implicit alpha; otherwise, the rgba() form is used, with an explicit alpha value.
`旧来の色~構文$ — ~comma（ `002C^U （ `,^l ））で分離される形 — を利用するとする。したがって， `rgba$f の~blue成分と~alpha値も（~slashではなく）~commaで分離するとする。各~commaには， `0020^U `SPACE^cn が 1 個だけ後続するとする。 ◎ For compatibility, the legacy form with comma separators is used; exactly one ASCII space follows each comma. This includes the comma (not slash) used to separate the blue component of rgba() from the alpha value.

しかしながら，`旧来の色~構文$は、 `none$v を表現し得ない。 ~sRGB値に`欠落~成分$が在る場合、直列化には，［欠落~成分を~keyword `none$v として保全する形］が［ `宣言d値$を成す`色~関数$ ］に基づいて選ばれる。当の値に応じて： ◎ However, the legacy color syntax with comma separators cannot represent none. If the value has at least one missing color component, the serialization form is chosen to preserve those components as the none keyword, based on the color function of the declared value:

`~hex色$

`named-color$t【！`有名~色$】

`system-color$t【！`~system色$】

`deprecated-color$t【！§#deprecated-system-colors】

`transparent$v

これらが`欠落~成分$を有することは決してない — これらには、 ~parameter化された構文は無いので。 ◎ ↓

`rgb$f

`rgba$f

当の値は、 `srgb$v `色~空間$内の `color$f 関数として直列化される — `rgb^f 用の`現代の色~構文$は `none$v を受容するが，その形ではなく。直列化は、次を順に連結した結果になる：

`color(srgb ^l
~alpha以外の 3 個の成分が成す~spaceで分離された~list — 各~成分は、［ `欠落~成分$であるならば `none^l ／ ~ELSE_ 基準~範囲 0 以上 1 以下に入る `number$t ］に直列化される
~alpha成分に応じて ⇒＃ 1 ならば空~文字列／ `欠落~成分$ならば ` / none^l ／ ~ELSE_ ` / ^l と［ `§ ~alpha値の直列化-法$により直列化した結果］を順に連結した結果
`)^l

◎ For rgb() and rgba() values (the only sRGB form in this list whose syntax accepts none; hex colors, named colors, system colors, deprecated-colors, and transparent have no parametric syntax and so never have missing color components), the value is serialized as a color() function in the srgb color space rather than as the modern space-separated form of rgb(), even though that form would also accept none: "color(srgb" followed by a single space, followed by a space-separated list of the three non-alpha components serialized as <number>s in the [0, 1] reference range (or as none if missing), followed (only if the alpha is non-unity or missing) by " / " and the alpha component (serialized per the alpha rules, or as none if missing), followed by ")".

`hsl$f

`hsla$f

当の値は、 `hsl^f 用の`現代の色~構文$を利用して直列化される：

関数~名は `hsl^l になる — `hsla^f を利用して著作された場合でも。
各~成分のうち：
- `欠落~成分$は，~keyword `none$v として直列化される
- 他は，次のとおり直列化される ⇒＃色相は度数に正準-化された `number$t として／彩度, 明度は `percentage$t として／ ~alphaは `§ ~alpha値の直列化-法$に従う
~alpha成分は 1 以外をとる場合に限り含まる — その場合は直前に~slashを伴う

◎ For hsl() and hsla() values, the value is serialized using the modern (whitespace-separated) hsl() syntax, with a slash before the alpha component when present. The function name is "hsl" (in ASCII lowercase) regardless of whether the value was authored using the hsla() alias. The hue is serialized as a canonicalized <number> in degrees, the saturation and lightness as <percentage>s, and the alpha (included only if non-unity or missing) per the alpha rules; any missing component is serialized as the none keyword.

`hwb$f

当の値は、 `hwb^f 用の`現代の色~構文$を利用して直列化される：

関数~名は `hwb^l になる。
各~成分のうち：
- `欠落~成分$は，~keyword `none$v として直列化される
- 他は，次のとおり直列化される ⇒＃色相は度数に正準-化された `number$t として／白度, 黒度は `percentage$t として／ ~alphaは `§ ~alpha値の直列化-法$に従う
~alpha成分は 1 以外をとる場合に限り含まれる — その場合は直前に~slashを伴う

◎ For hwb() values, the value is serialized using the modern (whitespace-separated) hwb() syntax, with a slash before the alpha component when present. The function name is "hwb" in ASCII lowercase. The hue is serialized as a canonicalized <number> in degrees, the whiteness and blackness as <percentage>s, and the alpha (included only if non-unity or missing) per the alpha rules; any missing component is serialized as the none keyword.

注記：すなわち、 `none$v を包含している［ `hsl$f ／ `hwb$f ］値は，［ `rgba$f （それ用の`旧来の色~構文$は `none$v を表現し得ない）へ降格されることなく，自前の色~関数が~~保たれる］よう直列化を通して往復する一方で、 `none$v を包含している［ `rgb$f ／ `rgba$f ］値は， `color(srgb …)^v を介して直列化される。 `rgb^f 用の`現代の色~構文$は `none$v も表現できるが、［他すべての`色~空間$が`現代の色~構文$でどう直列化されるか］との一貫性を得るため， ~sRGB値の`直列化＠#serializing-color-values$は `color(srgb …)^v を利用する【？】。これは、 `~level 5$ にて`相対~色~構文$用に定義される `§ 起点~色の直列化-法＠~CSSCOLOR5#serial-origin-color$ の挙動に並行する。 ◎ Note: this means that an hsl() or hwb() value containing none round-trips through serialization in its own color function, rather than degrading to rgba() (whose legacy form cannot represent none), while an rgb() value containing none is serialized via color(srgb …). The modern space-separated form of rgb() could itself represent none, but the sRGB CSS serialization uses color(srgb …) instead for consistency with how all other color spaces are serialized in their non-legacy form. This parallels the behavior of relative color syntax defined in CSS Color 5 § 11.2 Serializing Origin Colors.

例えば， `rgba(29, 164, 192, 0.95)^swatch `rgb(29 164 192 / 95%)^v を直列化した結果は ⇒ 文字列 `rgba(29, 164, 192, 0.95)^l になる ◎ For example, the serialized value of • rgb(29 164 192 / 95%) is the string "rgba(29, 164, 192, 0.95)"

例えば、作者が給した値 `70% 36.67% 20% / 0.5^rgb `hwb(740deg 20% 30% / 50%)^v は： ◎ For example, an author-supplied value: • hwb(740deg 20% 30% / 50%)

まず，正規化され ⇒ `hwb(20 20% 30% / 50%)^v ◎ Would be normalized first to • hwb(20 20% 30% / 50%)
~sRGBへ変換され ⇒ `rgb(70% 36.67% 20% / 0.5)^v ◎ and then converted to sRGB＼
その結果が直列化される ⇒ `rgba(178.5, 93.5, 51, 0.5)^l ◎ and serialized as • rgba(178.5, 93.5, 51, 0.5)

返される結果の精度は、 `下に述べられる＠#sRGB-precision$。 ◎ The precision of the returned result is described below.

例えば，作者が給した値 `hwb(20 none 30% / none)^v は、 `欠落~成分$を包含するので（白度, ~alphaはどちらも `none$v ）， `rgba$f を通して直列化される`ことはない^em。代わりに，現代の `hwb$f 構文を利用して直列化される — 各 `none$v 値を保全するよう， `hwb(20 none 30% / none)^l として。 ◎ For example, the author-supplied value ◎ hwb(20 none 30% / none) ◎ contains missing color components (both the whiteness and the alpha are none), so it is not serialized through rgba(). Instead, it is serialized using the modern hwb() syntax as ◎ hwb(20 none 30% / none) ◎ preserving each none value.

類似に，作者が給した値 `rgb(none 0 0)^v は、 `color(srgb none 0 0)^l として直列化される — （旧来の~comma形で直列化される） `rgb$f は、 `none$v を表現し得ないので。 ◎ Similarly, the author-supplied value ◎ rgb(none 0 0) ◎ is serialized as ◎ color(srgb none 0 0) ◎ because rgb() (in its serialized legacy comma form) cannot represent none.

注記： `CSS Color 3^cite に反して， `rgb$f 関数の各~parameterの【算出d値における】型は `number$t であり， `integer$t ではない。したがって、 8 ~bitより高い精度は，小数部で指示される。 ◎ Note: contrary to CSS Color 3, the parameters of the rgb() function are of type <number>, not <integer>. Thus, any higher precision than eight bits is indicated with a fractional part.

~sRGBの各~成分~値に維持される精度 — したがって、直列化した結果における有効数字の個数 — は，この仕様では定義されないが、少なくとも［ 8 ~bitな値が往復する］に足るようにするモノトスル。値は、切捨てるのではなく，`丸める$モノトスル。 ◎ The precision with which sRGB 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 eight bit values. Values must be rounded towards +∞, not truncated.

注記： ~scriptの作者には、［ `getComputedStyle()$c から返される色の成分~値が `integer$t になる］ものと期待している場合は， `number$t にも~~対処するよう更新することを勧める。 ◎ Note: authors of scripts which expect color values returned from getComputedStyle to have <integer> component values, are advised to update them to also cope with <number>.

例えば， `rgb(146.064 107.457 131.223)^v は、今や妥当であり，次に等しい ⇒ `57.28% 42.14% 51.46%^rgb `rgb(57.28% 42.14% 51.46%)^v ◎ For example, • rgb(146.064 107.457 131.223) is now valid, and equal to • rgb(57.28% 42.14% 51.46%)

どちらも、適合tな直列化された形は ⇒ `rgb(146.06, 107.46, 131.2)^l ◎ A conformant serialized form for both, is the string "rgb(146.06, 107.46, 131.2)".

どの成分~値に対しても、小数部の尾部を成す 0 たちは省略するモノトスル。小数部がすべて 0 からなる場合、小数点も省略するモノトスル。すなわち、整数~成分~値で指定された~sRGB色は，後方-互換な整数~値に直列化されることになる。 ◎ 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. This means that sRGB colors specified with integer component values will serialize with backwards-compatible integer values.

`goldenrod^swatch `goldenrod$vN の算出d値を直列化した結果は ⇒＃文字列 `rgb(218 165 32)^l になり，文字列 `rgb(218.000, 165.000, 32.000)^l にはならない。 ◎ The serialized computed value of • goldenrod is the string "rgb(218, 165, 32)" and not the string "rgb(218.000, 165.000, 32.000)"

16.3. ~Lab値／~LCH値の直列化-法

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

［ L ／ a ／ b ］成分~値は、基数 10 で `number$t として直列化される。百分率から実数への変換は、［ `~Lab用の百分率~基準~範囲＠#prr-lab$／ `~LCH用の百分率~基準~範囲＠#prr-lch$ ］いずれか適切な方を利用して遂行される — したがって、 L 値［ 0% は 0 ／ 100% は 100 ］に対応付けられる。成分~値どうしは 1 個の `0020^U `SPACE^cn を利用して分離するモノトスル。 ◎ The component values are serialized in base 10; the L, a, b and C component values are serialized as <number>, using the Lab percentage reference ranges or the LCH percentage reference ranges as appropriate to perform percentage to number conversion; thus 0% L maps to 0 and 100% L maps to 100. A single ASCII space character " " must be used as the separator between the component values.

`rgb(60.7% 52.23% 0%)^swatch `lab(56.200% 0.000 83.600)^v を直列化した結果は ⇒ 文字列 `lab(56.2 0 83.6)^l になる ◎ The serialized value of • lab(56.200% 0.000 83.600) is the string "lab(56.2 0 83.6)"

`rgb(60.7% 52.23% 0%)^swatch `lab(56.200% 0.000 66.88%)^v を直列化した結果は ⇒ 文字列 `lab(56.2 0 83.6)^l になる ◎ The serialized value of • lab(56.200% 0.000 66.88%) is the string "lab(56.2 0 83.6)"

どの成分~値に対しても、小数部の尾部を成す 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.

`rgb(41.66% 15.34% 90.66%)^swatch `lch(37% 105.0 305.00)^v を直列化した結果は ⇒＃文字列 `lch(37 105 305)^l になり， `lch(37 105.0 305.00)^l にはならない ◎ The serialized value of • lch(37% 105.0 305.00) is the string "lch(37 105 305)", not "lch(37 105.0 305.00)".

`lab$f の各~成分~値に維持される精度 — したがって，直列化した結果における有効数字の個数 — は，この仕様では定義されないが、広-色域に因り，少なくとも［精度 16 ~bitな［ 0 以上 100 以下の L 値／ −127 以上 127 以下の［ a ／ b ］値］が往復する］に足るようにするモノトスル。したがって，結果における小数部は、尾部を成す 0 たちが省略された場合を除き， 3 桁以上になる。（内部~storage用には、［半精度（ 16 ~bit）／単精度］浮動小数点数が推奨される）。値は、切捨てるのではなく，`丸める$モノトスル。 ◎ The precision with which lab() component values are retained, and thus the number of significant figures in the serialized value, is not defined in this specification, but due to the wide gamut must be sufficient to round-trip L values between 0 and 100, and a and b values between ±127, with at least sixteen bit precision; this will result in at least three decimal places unless trailing zeroes have been omitted. (half float or float, is recommended for internal storage). Values must be rounded towards +∞, not truncated.

注記：超広-色域~空間では、 ±125~FN の外側にある［ a ／ b ］値もアリになる。例えば、 `prophoto-rgb$v の原色と二次色は、 `どれも^em，この範囲を超過する（ ±200 の中に入るが）。【~FN 上の段落に指定された範囲 ±127 となぜ異なるかは不明。】 ◎ Note: a and b values outside ±125 are possible with ultrawide gamut spaces. For example, all of the prophoto-rgb primaries and secondaries exceed this range, but are within ±200.

~alpha値 1 は、 `§ ~alpha値の直列化-法$に注記したとおり，明示的に直列化されない。他の~alpha値は、明示的に直列化するモノトスル — その場合、 b 成分~値と~alpha値は，文字列 ` / ^l （ `0020^U `SPACE^cn, `002F^U （ `/^l ）, `0020^U `SPACE^cn ）を利用して分離するモノトスル。 ◎ As noted earlier, 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 b component value from the alpha value.

`rgba(99.56%, 6.09%, 57.02%, 0.93)^swatch `lch(56.2% 83.6 357.4 / 93%)^v を直列化した結果は ⇒＃文字列 `lch(56.2 83.6 357.4 / 0.93)^l になり， `lch(56.2% 83.6 357.4 / 0.93)^l にはならない ◎ The serialized value of • lch(56.2% 83.6 357.4 /93%) is the string "lch(56.2 83.6 357.4 / 0.93)" not "lch(56.2% 83.6 357.4 / 0.93)"

16.4. ~Oklab／~OkLCh値の直列化-法

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

［ L ／ a ／ b ／ C ］成分~値は、基数 10 で `number$t として直列化される。百分率から実数への変換は、［ `~Oklab用の百分率~基準~範囲＠#prr-oklab$ ／ `~OkLCh用の百分率~基準~範囲＠#prr-oklch$ ］いずれか適切な方を利用して遂行される — したがって、 L 値［ 0% は 0 ／ 100% は 1.0 ］に対応付けられる。成分~値どうしは、 1 個の `0020^U `SPACE^cn を利用して分離するモノトスル。 ◎ The component values are serialized in base 10; the L, a, b and C component values are serialized as <number> using the Oklab percentage reference ranges or the OkLCh percentage reference ranges as appropriate to perform percentage to number conversion; thus 0% L maps to 0 and 100% L maps to 1.0. A single ASCII space character " " must be used as the separator between the component values.

`0% 50.52% 49.07%^rgb `oklab(54.0% -0.10 -0.02)^v を直列化した結果は ⇒＃文字列 `oklab(0.54 -0.1 -0.02)^l になり， `oklab(54 -0.1 -0.02)^l や `oklab(54% -0.1 -0.02)^l にはならない。 ◎ The serialized value of • oklab(54.0% -0.10 -0.02) is the string "oklab(0.54 -0.1 -0.02)" not "oklab(54 -0.1 -0.02)" or "oklab(54% -0.1 -0.02)"

`0% 50.52% 49.07%^rgb `oklab(54.0 -25% -5%)^v を直列化した結果は ⇒＃文字列 `oklab(0.54 -0.1 -0.02)^l になり， `oklab(54 -0.25 -0.05)^l にはならない。 ◎ The serialized value of • oklab(54.0 -25% -5%) is the string "oklab(0.54 -0.1 -0.02)" not "oklab(54 -0.25 -0.05)"

`42.07% 49.6% 25.23%^rgb `oklch(56.43% 0.0900 123.40)^v を直列化した結果は ⇒＃文字列 `oklch(0.5643 0.09 123.4)^l になり， `oklch(0.5643 0.0900 123.40)^l にはならない ◎ The serialized value of • oklch(56.43% 0.0900 123.40) is the string "oklch(0.5643 0.09 123.4)", not "oklch(0.5643 0.0900 123.40)".

`oklab$f の各~成分~値に維持される精度 — したがって、直列化した結果における有効数字の個数 — は，この仕様では定義されないが、広-色域に因り，［ 0 以上 1 以下（ 0% 以上 100% 以下）の L 値, −0.5 以上 0.5 以下の［ a ／ b ／ C ］値］が，［少なくとも精度 16 ~bitの下で，往復するに足る］ようにするモノトスル。したがって，結果における小数部は、尾部を成す 0 たちが省略された場合を除き， 5 桁以上になる。（内部~storage用には、［半精度（ 16 ~bit）／単精度］浮動小数点数が推奨される）。値は、切捨てるのではなく，`丸める$モノトスル。 ◎ The precision with which oklab() component values are retained, and thus the number of significant figures in the serialized value, is not defined in this specification, but due to the wide gamut must be sufficient to round-trip L values between 0 and 1 (0% and 100%), and a, b and C values between ±0.5, with at least sixteen bit precision; this will result in at least five decimal places unless trailing zeroes have been omitted. (half float or float, is recommended for internal storage). Values must be rounded towards +∞, not truncated.

注記：超広-色域~空間においては、 ±0.5 の外側にある［ a ／ b ／ C ］値もアリになる。例えば `prophoto-rgb$v における［ ~green／~blue ］原色は、その C は［ 0.526 ／ 1.413 ］であり，この範囲を超過する。 ◎ Note: a, b and C values outside ±0.5 are possible with ultrawide gamut spaces. For example, the prophoto-rgb green and blue primaries exceed this range, with C of 0.526 and 1.413 respectively.

~alpha値 1 は、 `§ ~alpha値の直列化-法$に注記したとおり，明示的に直列化されない。他の~alpha値は、明示的に直列化するモノトスル — その場合、最後の色~成分（ b または C ）値と~alpha値は，文字列 ` / ^l （ `0020^U `SPACE^cn, `002F^U （ `/^l ）, `0020^U `SPACE^cn ）を利用して分離するモノトスル。 ◎ As noted earlier, 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 final color component (b, or C) value from the alpha value.

`60%, 26.67%, 66.67%, 0.7^rgb `oklch(53.85% 0.1725 320.67 / 70%)^v を直列化した結果は ⇒ 文字列 `oklch(0.5385 0.1725 320.67 / 0.7)^l になる ◎ The serialized value of • oklch(53.85% 0.1725 320.67 / 70%) is the string "oklch(0.5385 0.1725 320.67 / 0.7)"

16.5. `color^f 関数の直列化-法

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

各~成分~値は、 `number$t として基数 10 で直列化される。［成分~値どうし／色~空間~名と 1 個目の色~成分］は 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, and also between the color space name and the first color component.

`rgba(99.56%, 6.09%, 57.02%, 0.93)^swatch `color(dIsPlAy-P3 0.964 0.763 0.787)^v を直列化した結果は、小数部が 2 桁まで維持されるなら ⇒ 文字列 `color(display-p3 0.96 0.76 0.79)^l になる ◎ The serialized value of • color(dIsPlAy-P3 0.964 0.763 0.787) is the string "color(display-p3 0.96 0.76 0.79)", if two decimal places are retained.＼

0.787 は、 0.78 に切捨てるのではなく， 0.79 に切上げることに注意。 ◎ Notice that 0.787 has rounded up to 0.79, rather than being truncated to 0.78.

`15.06% 71.88% 34.64%^rgb `color(rec2020 0.400 0.660 0.340)^v を直列化した結果は ⇒ 文字列 `color(rec2020 0.4 0.66 0.34)^l になる — `color(rec2020 0.400 0.660 0.340)^l ではなく。 ◎ The serialized value of • color(rec2020 0.400 0.660 0.340) ◎ is the string "color(rec2020 0.4 0.66 0.34)", not "color(rec2020 0.400 0.660 0.340)".

色~空間が~sRGBの場合でも、直列化した結果には，色~空間（ `srgb$v ）を明示的に含めることが要求される。 ◎ If the color space is sRGB, the color space is still explicitly required in the serialized result.

`定義済み色~空間$に対し，値が往復するための最小な精度は、次に従う： ◎ For the predefined color spaces, the minimum precision for round-tripping is as follows:

色~空間	最小な~bit数
`srgb$v	10
`srgb-linear$v	12
`display-p3$v	10
`a98-rgb$v	10
`prophoto-rgb$v	12
`rec2020$v	12
`xyz$v	16
`xyz-d50$v	16
`xyz-d65$v	16

（内部~storage用には、成分ごとに，［半精度（ 16 ~bit）／単精度］浮動小数点数が推奨される）。値は、切捨てるのではなく，`丸める$モノトスル。 ◎ (16bit, half-float, or float per component is recommended for internal storage). Values must be rounded towards +∞, not truncated.

注記： `color(srgb)^v に対する最小~精度の要件は、 `rgb$f, `hsl$f 等々の旧来の形に比して高い。したがって，より高い精度を選好する~stylesheet作者には、 `color(srgb)^v 形を利用することが奨励される。 ◎ Note: compared to the legacy forms such as rgb(), hsl() and so on, color(srgb) has a higher minimum precision requirement. Stylesheet authors who prefer higher precision are thus encouraged to use the color(srgb) form.

~alpha値 1 は、 `§ ~alpha値の直列化-法$に注記したとおり，明示的に直列化されない。他の~alpha値は、明示的に直列化するモノトスル — その場合、 ~~最後の色~成分~値と~alpha値は，文字列 ` / ^l （ `0020^U `SPACE^cn, `002F^U （ `/^l ）, `0020^U `SPACE^cn ）を利用して分離するモノトスル。 ◎ As noted earlier, 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 final color component value from the alpha value.

`rgba(0.003%, 50.196%, 50.196%, 0.85)^swatch `color(prophoto-rgb 0.2804 0.40283 0.42259/85%)^v を直列化した結果は、小数部が 3 桁まで維持されるなら ⇒ `color(prophoto-rgb 0.28 0.403 0.423 / 0.85)^l ◎ The serialized value of • color(prophoto-rgb 0.2804 0.40283 0.42259/85%) is the string "color(prophoto-rgb 0.28 0.403 0.423 / 0.85)", if three decimal places are retained.

16.6. 他の色の直列化-法

この節は、 `currentcolor$v に適用される。 ◎ This applies to currentcolor.

この値を直列化した形は、 `算出d値$から導出される — 色~名は、 `~ASCII小文字~化$される。 ◎ The serialized form of this value is derived from the computed value and uses ASCII lowercase letters for the color name.

`currentcolor$v を直列化した結果は ⇒ `currentcolor^l ◎ The serialized form of currentColor is the string "currentcolor".

17. `opacity-value$t の直列化-法

この節は、 `opacity$p ~propに適用される。 ◎ This applies to the opacity property.

【定義~表tにおいて `opacity$p あるいは `opacity-value$t を参照している他の~propにも。】

所与の不透明度~値【 `opacity-value$t 】用の`指定d値$を直列化した結果は、次に従うベキである： ◎ If the specified value for an opacity value＼

当の値は `percentage-token$t に合致する場合（すなわち， `calc$f を利用しない~literalな百分率である） ⇒ 等価な `number$t 値（ 0% は 0, 100% は 1 へ対応付ける） ◎ matches a literal <percentage-token> (i.e. does not use calc()) it should be serialized as the equivalent <number> (0% maps to 0, 100% maps to 1) value. value.＼
他の場合 ⇒ 当の値の文法~用の標準な直列化を利用した結果 ◎ Otherwise, the specified value for an opacity value should serialize using the standard serialization for the grammar.

`number$t 値に直列化するときは、次に従うモノトスル ⇒＃基数 10 で表出する。小数点文字には `002E^U （ `.^l ）を利用する。先頭の 0 は省略しない。尾部を成す 0 たちは省略する。 ◎ This <number> value is expressed in base ten, with the "." character as decimal separator. The leading zero must not be omitted. Trailing zeroes must be omitted.

範囲 0 以上 1 以下に入らない不透明度~値は、直列化された指定d値においても，切詰めることなく保全される。 ◎ Opacity values outside the range [0,1] are preserved, without clamping, in the serialized specified value.

不透明度~値と伴に維持される精度 — したがって、直列化した結果における小数部の桁数 — は，この仕様では定義されないが、少なくとも［整数をとる百分率~値が往復する］に足るようにするモノトスル。したがって，結果における小数部は、尾部を成す 0 たちが省略された場合を除き， 2 桁以上になる。値は、切捨てるのではなく，`丸める$モノトスル。 ◎ The precision with which opacity values are retained, and thus the number of decimal places in the serialized value, is not defined in this specification, but must at least be sufficient to round-trip integer percentage values. Thus, the serialized value must contain at least two decimal places (unless trailing zeroes have been removed). Values must be rounded towards +∞, not truncated.

18. 既定の~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 documents.

/* 
~hyperlink用には、
伝統的な~desktop~UA用の色
◎
traditional desktop user agent colors for hyperlinks
 */
:link { color: LinkText; }
:visited { color: VisitedText; }
:active { color: ActiveText; }

19. 色~変換~用の見本~code

◎非規範的

【この節の内容は、 `この仕様の~repository＠https://github.com/w3c/csswg-drafts/tree/main/css-color-4$にて供される `conversions.js＠~CSSWG/css-color/conversions.js$ に基づく。】

明快にするため、行列の乗算~用には， `ある~library＠~CSSWG/css-color/multiply-matrices.js$が利用される（すべての乗算-と加算-を~inline化するより読易くなる）。行列は、 `column-major order＠https://www.scratchapixel.com/lessons/mathematics-physics-for-computer-graphics/geometry/row-major-vs-column-major-vector$en である【“列主導順” — 行列を与える配列を成す各~要素（入子な配列）は、行列の列を表現する】。 ◎ For clarity, a library is used for matrix multiplication. (This is more readable than inlining all the multiplies and adds). The matrices are in column-major order.

/* 
色~変換~用の見本~code。
変換は、
~ICC~profileと色~管理~systemを利用しても行える。
明快にするため、
行列の乗算には~libraryを利用する。
◎
Sample code for color conversions
Conversion can also be done using ICC profiles and a Color Management System
For clarity, a library is used for matrix multiplication (multiply-matrices.js)
 */

/* 
【！4-figure _dgm-CH-plane-wheel ？】
~CIE x, y 純色度により定義される標準な`白色点$
◎
standard white points, defined by 4-figure CIE x,y chromaticities
 */
const %D50 = [0.3457 / 0.3585, 1.00000, (1.0 - 0.3457 - 0.3585) / 0.3585];
const %D65 = [0.3127 / 0.3290, 1.00000, (1.0 - 0.3127 - 0.3290) / 0.3290];

/* 
~sRGBに関係する関数
◎
sRGB-related functions
 */

function lin_sRGB(%RGB) {
	/* 
~sRGB値の配列
（範囲 [0.0, 1.0] に入る値が色域~内に入る）
を光に線形な形へ変換する。
◎
convert an array of sRGB values where in-gamut values are in the range [0 - 1]
 */
	// https://en.wikipedia.org/wiki/SRGB
	/* 
伝達t関数は、
負な値に対しても，原点に関して対称になるよう拡張される。
◎
Extended transfer function:
for negative values, linear portion is extended on reflection of axis, then reflected power function is used.
 */
	return %RGB.map(function (%val) {
		let %sign = %val < 0? -1 : 1;
		let %abs = Math.abs(%val);

		if (%abs <= 0.04045) {
			return %val / 12.92;
		}

		return %sign * (Math.pow((%abs + 0.055) / 1.055, 2.4));
	});
}

function gam_sRGB(%RGB) {
	/* 
範囲 [0.0, 1.0] に入る光に線形な~sRGB値の配列を~gamma補正された形へ変換する。
◎
convert an array of linear-light sRGB values in the range 0.0-1.0 to gamma corrected form
 */
	// https://en.wikipedia.org/wiki/SRGB
	/* 
伝達t関数は、
負な値に対しても，原点に関して対称になるよう拡張される。
◎
Extended transfer function:
For negative values, linear portion extends on reflection of axis, then uses reflected pow below that
 */
	return %RGB.map(function (%val) {
		let %sign = %val < 0? -1 : 1;
		let %abs = Math.abs(%val);

		if (%abs > 0.0031308) {
			return %sign * (1.055 * Math.pow(%abs, 1/2.4) - 0.055);
		}

		return 12.92 * %val;
	});
}

function lin_sRGB_to_XYZ(%rgb) {
	/* 
光に線形な~sRGB値の配列を~sRGBの自前の~white, ~D65を利用して~CIE~XYZへ変換する（`有彩色~順応$なし）。
◎
convert an array of linear-light sRGB values to CIE XYZ using sRGB's own white, D65 (no chromatic adaptation)
 */
	var %M = [
		[ 506752 / 1228815,  87881 / 245763,   12673 /   70218 ],
		[  87098 /  409605, 175762 / 245763,   12673 /  175545 ],
		[   7918 /  409605,  87881 / 737289, 1001167 / 1053270 ],
	];
	return multiplyMatrices(%M, %rgb);
}

function XYZ_to_lin_sRGB(%XYZ) {
	/* 
~XYZを光に線形な~sRGBへ変換する。
◎
convert XYZ to linear-light sRGB
 */
	var %M = [
		[   12831 /   3959,    -329 /    214, -1974 /   3959 ],
		[ -851781 / 878810, 1648619 / 878810, 36519 / 878810 ],
		[     705 /  12673,   -2585 /  12673,   705 /    667 ],
	];
	return multiplyMatrices(%M, %XYZ);
}

/* 
`display-p3$v に関係する関数
◎
display-p3-related functions
 */


function lin_P3(%RGB) {
	/* 
範囲 [0.0, 1.0] に入る `display-p3$v ~RGB値の配列を光に線形な形へ変換する。
◎
convert an array of display-p3 RGB values in the range 0.0 - 1.0 to linear light (un-companded) form.
 */

	return lin_sRGB(%RGB);	/* 
~sRGBと同じ
◎
same as sRGB
 */
}

function gam_P3(%RGB) {
	/* 
範囲 [0.0, 1.0] に入る光に線形な `display-p3$v ~RGBの配列を~gamma補正された形へ変換する。
◎
convert an array of linear-light display-p3 RGB in the range 0.0-1.0 to gamma corrected form
 */

	return gam_sRGB(%RGB);	/* 
~sRGBと同じ
◎
same as sRGB
 */
}

function lin_P3_to_XYZ(%rgb) {
	/* 
光に線形な `display-p3$v 値の配列を~CIE~XYZ利用して~D65へ変換する（`有彩色~順応$なし）。
◎
convert an array of linear-light display-p3 values to CIE XYZ using D65 (no chromatic adaptation)
 */
	// http://www.brucelindbloom.com/index.html?Eqn_RGB_XYZ_Matrix.html
	var %M = [
		[ 608311 / 1250200, 189793 / 714400,  198249 / 1000160 ],
		[  35783 /  156275, 247089 / 357200,  198249 / 2500400 ],
		[      0 /       1,  32229 / 714400, 5220557 / 5000800 ],
	];

	return multiplyMatrices(%M, %rgb);
}

function XYZ_to_lin_P3(%XYZ) {
	/* 
~XYZを光に線形な~P3へ変換する。
◎
convert XYZ to linear-light P3
 */
	var %M = [
		[ 446124 / 178915, -333277 / 357830, -72051 / 178915 ],
		[ -14852 /  17905,   63121 /  35810,    423 /  17905 ],
		[  11844 / 330415,  -50337 / 660830, 316169 / 330415 ],
	];

	return multiplyMatrices(%M, %XYZ);
}

/* 
`prophoto-rgb$v 関数
◎
prophoto-rgb functions
 */

function lin_ProPhoto(%RGB) {
	/* 
`prophoto-rgb$v 値の配列
（範囲 [0.0, 1.0] に入る値が色域~内に入る）
を光に線形な形へ変換する。
伝達t曲線は、
~gamma 1.8 に従うが，
0 近辺に線形な部位も伴う。
◎
convert an array of prophoto-rgb values where in-gamut colors are in the range [0.0 - 1.0] to linear light (un-companded) form.＼
Transfer curve is gamma 1.8 with a small linear portion
 */
	/* 
伝達t関数は、
負な値に対しても，原点に関して対称になるよう拡張される。
◎
Extended transfer function
 */

	const %Et2 = 16/512;
	return %RGB.map(function (%val) {
		let %sign = %val < 0? -1 : 1;
		let %abs = Math.abs(%val);

		if (%abs <= %Et2) {
			return %val / 16;
		}

		return %sign * Math.pow(%abs, 1.8);
	});
}

function gam_ProPhoto(%RGB) {
	/* 
範囲 [0.0, 1.0] に入る光に線形な `prophoto-rgb$v の配列を~gamma補正された形へ変換する。
伝達t曲線は、
~gamma 1.8 に従うが，
0 近辺に線形な部位も伴う。
◎
convert an array of linear-light prophoto-rgb in the range 0.0-1.0 to gamma corrected form Transfer curve is gamma 1.8 with a small linear portion
 */
	/* 
伝達t関数は、
負な値に対しても，原点に関して対称になるよう拡張される。
◎
TODO for negative values, extend linear portion on reflection of axis, then add pow below that
 */
	const %Et = 1/512;
	return %RGB.map(function (%val) {
		let %sign = %val < 0? -1 : 1;
		let %abs = Math.abs(%val);

		if (%abs >= %Et) {
			return %sign * Math.pow(%abs, 1/1.8);
		}

		return 16 * %val;
	});
}

function lin_ProPhoto_to_XYZ(%rgb) {
	/* 
光に線形な `prophoto-rgb$v 値の配列を~CIE~D50~XYZへ変換する。
行列は、
有理-形では表出し得ないが， 64 ~bitの正確度で計算される。
`7675$issue を見よ。
◎
convert an array of linear-light prophoto-rgb values to CIE D50 XYZ
matrix cannot be expressed in rational form, but is calculated to 64 bit accuracy
see https://github.com/w3c/csswg-drafts/issues/7675
 */
	var %M = [
		[ 0.79776664490064230,  0.13518129740053308,  0.03134773412839220 ],
		[ 0.28807482881940130,  0.71183523424187300,  0.00008993693872564 ],
		[ 0.00000000000000000,  0.00000000000000000,  0.82510460251046020 ]
	];

	return multiplyMatrices(%M, %rgb);
}

function XYZ_to_lin_ProPhoto(%XYZ) {
	/* 
~D50~XYZを光に線形な `prophoto-rgb$v へ変換する。
◎
convert D50 XYZ to linear-light prophoto-rgb
 */
	var %M = [
		[  1.34578688164715830, -0.25557208737979464, -0.05110186497554526 ],
		[ -0.54463070512490190,  1.50824774284514680,  0.02052744743642139 ],
		[  0.00000000000000000,  0.00000000000000000,  1.21196754563894520 ]
	];

	return multiplyMatrices(%M, %XYZ);
}

/* 
`a98-rgb$v 関数
◎
a98-rgb functions
 */

function lin_a98rgb(%RGB) {
	/* 
範囲 [0.0, 1.0] に入る `a98-rgb$v 値の配列を光に線形な形へ変換する。
今や，負な値も受容される。
◎
convert an array of a98-rgb values in the range 0.0 - 1.0 to linear light (un-companded) form.＼
negative values are also now accepted
 */
	return %RGB.map(function (%val) {
		let %sign = %val < 0? -1 : 1;
		let %abs = Math.abs(%val);

		return %sign * Math.pow(%abs, 563/256);
	});
}

function gam_a98rgb(%RGB) {
	/* 
範囲 [0.0, 1.0] に入る光に線形な `a98-rgb$v の配列を~gamma補正された形へ変換する。
今や，負な値も受容される。
◎
convert an array of linear-light a98-rgb in the range 0.0-1.0 to gamma corrected form negative values are also now accepted
 */
	return %RGB.map(function (%val) {
		let %sign = %val < 0? -1 : 1;
		let %abs = Math.abs(%val);

		return %sign * Math.pow(%abs, 256/563);
	});
}

function lin_a98rgb_to_XYZ(%rgb) {
	/* 
光に線形な `a98-rgb$v 値の配列を~CIE~XYZへ変換する。
◎
convert an array of linear-light a98-rgb values to CIE XYZ
 */
	// http://www.brucelindbloom.com/index.html?Eqn_RGB_XYZ_Matrix.html
	/* 
その数量的な精度は，
`Adobe® RGB (1998) Color Image Encoding（色~画像の符号化法）＠https://www.adobe.com/digitalimag/pdfs/AdobeRGB1998.pdf$
§ 4.3.5.3
より高いが、
下の値は，［
R, G, B, W
］の純色度~座標からの
`first principles^en 【？】から計算された。
`matrixmaker.html＠https://github.com/w3c/csswg-drafts/blob/main/css-color-4/matrixmaker.html$
【！~CSSWG/css-color/matrixmaker.html】
を見よ。
◎
has greater numerical precision than section 4.3.5.3 of
https://www.adobe.com/digitalimag/pdfs/AdobeRGB1998.pdf
but the values below were calculated from first principles from the chromaticity coordinates of R G B W see matrixmaker.html
 */
	var %M = [
		[ 573536 /  994567,  263643 / 1420810,  187206 /  994567 ],
		[ 591459 / 1989134, 6239551 / 9945670,  374412 / 4972835 ],
		[  53769 / 1989134,  351524 / 4972835, 4929758 / 4972835 ],
	];

	return multiplyMatrices(%M, %rgb);
}

function XYZ_to_lin_a98rgb(%XYZ) {
	/* 
~XYZを光に線形な `a98-rgb$v へ変換する。
◎
convert XYZ to linear-light a98-rgb
 */
	var %M = [
		[ 1829569 /  896150, -506331 /  896150, -308931 /  896150 ],
		[ -851781 /  878810, 1648619 /  878810,   36519 /  878810 ],
		[   16779 / 1248040, -147721 / 1248040, 1266979 / 1248040 ],
	];

	return multiplyMatrices(%M, %XYZ);
}

/* 
Rec. 2020 に関係する関数
◎
Rec. 2020-related functions
 */

function lin_2020(%RGB) {
	/* 
範囲 [0.0, 1.0] に入る `rec2020$v ~RGB値の配列を光に線形な形へ変換する。
◎
convert an array of rec2020 RGB values in the range 0.0 - 1.0 to linear light (un-companded) form.
 */
	/* 
`REC_BT.1886$r Annex 1 による基準 `electro-optical^en 伝達t関数【電気信号から光信号への伝達t関数】
— ［
%b （ `black lift^en ） = 0,
%a （ `user gain^en ） = 1
］を伴い, 拡張された範囲~越しに定義され, 切詰められない。
◎
Reference electro-optical transfer function from Rec. ITU-R BT.1886 Annex 1 with b (black lift) = 0 and a (user gain) = 1 defined over the extended range, not clamped
 */

	return %RGB.map(function (%val) {
		let %sign = %val < 0? -1 : 1;
		let %abs = Math.abs(%val);
		return %sign * Math.pow(%abs, 2.4);
	});
}

function gam_2020(%RGB) {
	/* 
範囲 [0.0, 1.0] に入る光に線形な `rec2020$v ~RGBの配列を~gamma補正された形へ変換する。
◎
convert an array of linear-light rec2020 RGB in the range 0.0-1.0 to gamma corrected form
 */
	/* 
`REC_BT.1886$r Annex 1 による基準 `electro-optical^en 【 `opto-electronic^en ？】 伝達t関数
— ［
%b （ `black lift^en ） = 0,
%a （ `user gain^en ） = 1
］を伴い, 拡張された範囲~越しに定義され, 切詰められない。
◎
Reference electro-optical transfer function from Rec. ITU-R BT.1886 Annex 1 with b (black lift) = 0 and a (user gain) = 1 defined over the extended range, not clamped
 */

	return %RGB.map(function (%val) {
		let %sign = %val < 0? -1 : 1;
		let %abs = Math.abs(%val);
		return %sign * Math.pow(%abs, 1 / 2.4);
	});
}

function lin_2020_to_XYZ(%rgb) {
	/* 
光に線形な `rec2020$v 値の配列を~D65を利用して~CIE~XYZへ変換する（`有彩色~順応$なし）
◎
convert an array of linear-light rec2020 values to CIE XYZ using D65 (no chromatic adaptation)
 */
	var %M = [
		[ 63426534 / 99577255,  20160776 / 139408157,  47086771 / 278816314 ],
		[ 26158966 / 99577255, 472592308 / 697040785,   8267143 / 139408157 ],
		[        0 /        1,  19567812 / 697040785, 295819943 / 278816314 ],
	];
	/* 
0.00000… は、
実際には 4.994106574466076e-17 に計算される。
◎
0 is actually calculated as 4.994106574466076e-17
 */

	return multiplyMatrices(%M, %rgb);
}

function XYZ_to_lin_2020(%XYZ) {
	/* 
~XYZを光に線形な `rec2020$v へ変換する。
◎
convert XYZ to linear-light rec2020
 */
	var %M = [
		[  30757411 / 17917100, -6372589 / 17917100, -4539589 / 17917100 ],
		[ -19765991 / 29648200, 47925759 / 29648200,   467509 / 29648200 ],
		[    792561 / 44930125, -1921689 / 44930125, 42328811 / 44930125 ],
	];

	return multiplyMatrices(%M, %XYZ);
}

/* 
`有彩色~順応$
◎
Chromatic adaptation
 */

function D65_to_D50(%XYZ) {
	/* 
~D65から~D50への【線形？】~Bradford`有彩色~順応$。
下の行列は、
3 つの演算［
~XYZから網膜錐体~domainへ変換する,
一方の基準~whiteから他方のそれへ成分を拡縮する,
~XYZへ変換して戻す
］による結果を与える。
◎
Bradford chromatic adaptation from D65 to D50 The matrix below is the result of three operations:
- convert from XYZ to retinal cone domain
- scale components from one reference white to another
- convert back to XYZ
 */
	// see http://www.brucelindbloom.com/index.html?Eqn_ChromAdapt.html
	var %M = [
		[  1.0479297925449969,    0.022946870601609652,  -0.05019226628920524  ],
		[  0.02962780877005599,   0.9904344267538799,    -0.017073799063418826 ],
		[ -0.009243040646204504,  0.015055191490298152,   0.7518742814281371   ]
	];

	return multiplyMatrices(%M, %XYZ);
}

function D50_to_D65(%XYZ) {
	/* 
~D50から~D65への【線形？】~Bradford`有彩色~順応$
◎
Bradford chromatic adaptation from D50 to D65
 */
	// See https://github.com/LeaVerou/color.js/pull/360/files
	var %M = [
		[  0.955473421488075,    -0.02309845494876471,   0.06325924320057072  ],
		[ -0.0283697093338637,    1.0099953980813041,    0.021041441191917323 ],
		[  0.012314014864481998, -0.020507649298898964,  1.330365926242124    ]
	];

	return multiplyMatrices(%M, %XYZ);
}

/* 
~CIE~Labと~LCH
◎
CIE Lab and LCH
 */

function XYZ_to_Lab(%XYZ) {
	/* 
~XYZを，~D50に相対的と見做す下で~CIE標準から~CIE~Labへ変換する
— それは今や，これらを有理数として定義する。
◎
Assuming XYZ is relative to D50, convert to CIE Lab from CIE standard, which now defines these as a rational fraction
 */
	var %ε = 216/24389;  /* 6^3/29^3 */
	var %κ = 24389/27;   /* 29^3/3^3 */

	/* 
%xyz を算出する
— 基準~whiteに相対的に~XYZ拡縮される
◎
compute xyz, which is XYZ scaled relative to reference white
 */
	var %xyz = %XYZ.map((%value, %i) => %value / %D50[%i]);

	/* 
%f を算出する
◎
now compute f
 */
	var %f = %xyz.map(%value => %value > %ε ? Math.cbrt(%value) : (%κ * %value + 16)/116);

	return [
		(116 * %f[1]) - 16,   /* L */
		500 * (%f[0] - %f[1]), /* a */
		200 * (%f[1] - %f[2])  /* b */
	];
	/* 
L の範囲は 0 以上 100 以下。
~CSSにて利用するときは、
`%^c を追加すること。
◎
L in range [0,100]. For use in CSS, add a percent
 */
}

function Lab_to_XYZ(%Lab) {
	/* 
~Labを~D50に順応された~XYZへ変換する。
◎
Convert Lab to D50-adapted XYZ
 */
	// http://www.brucelindbloom.com/index.html?Eqn_Lab_to_XYZ.html
	var %κ = 24389/27;   /* 29^3/3^3 */
	var %ε = 216/24389;  /* 6^3/29^3 */
	var %f = [];

	/* 
輝度に関係する項から開始して
%f を算出する。
◎
compute f, starting with the luminance-related term
 */
	%f[1] = (%Lab[0] + 16)/116;
	%f[0] = %Lab[1]/500 + %f[1];
	%f[2] = %f[1] - %Lab[2]/200;

	/* 
%xyz を算出する。
◎
compute xyz
 */
	var %xyz = [
		Math.pow(%f[0],3) > %ε ?   Math.pow(%f[0],3)            : (116*%f[0]-16)/%κ,
		%Lab[0] > %κ * %ε ?        Math.pow((%Lab[0]+16)/116,3) : %Lab[0]/%κ,
		Math.pow(%f[2],3)  > %ε ?  Math.pow(%f[2],3)            : (116*%f[2]-16)/%κ
	];

	/* 
%xyz を基準~whiteにより拡縮して，~XYZを算出する。
◎
Compute XYZ by scaling xyz by reference white
 */
	return %xyz.map((%value, %i) => %value * %D50[%i]);
}

function Lab_to_LCH(%Lab) {
	var %微小数 = 0.0015;
	var %chroma = Math.sqrt(Math.pow(%Lab[1], 2) + Math.pow(%Lab[2], 2)); /* 
色度
◎
Chroma
 */
	var %hue = Math.atan2(%Lab[2], %Lab[1]) * 180 / Math.PI;
	if (%hue < 0) {
		%hue = %hue + 360;
	}
	if (%chroma <= %微小数) {
		%hue = NaN;
	}
	return [
		%Lab[0], /* 
L はそのまま
◎
L is still L
 */
		%chroma, /* 
色度
◎
Chroma
 */
		%hue /* 
色相, 度数で 0 以上 360 未満
◎
Hue, in degrees [0 to 360)
 */
	];
}

function LCH_to_Lab(%LCH) {
	/* 
極-座標~形から変換する。
◎
Convert from polar form
 */
	return [
		%LCH[0], /* 
L はそのまま
◎
L is still L
 */
		%LCH[1] * Math.cos(%LCH[2] * Math.PI / 180), /* a */
		%LCH[1] * Math.sin(%LCH[2] * Math.PI / 180) /* b */
	];
}

/* 
~Oklabと~OkLCh
◎
OKLab and OKLCH
 */
// https://bottosson.github.io/posts/oklab/
/* 
一貫した基準~white用に計算し直された XYZ ↔ LMS 行列
— `6642#issuecomment-943521484$issue
を見よ。
◎
XYZ <-> LMS matrices recalculated for consistent reference white
see https://github.com/w3c/csswg-drafts/issues/6642#issuecomment-943521484
 */
/* 
64 ~bit精度~用に計算し直す
— `color.js pull #357＠https://github.com/color-js/color.js/pull/357$
を見よ。
◎
recalculated for 64bit precision
see https://github.com/color-js/color.js/pull/357
 */

function XYZ_to_OKLab(%XYZ) {
	/* 
所与の~D65に相対的な~XYZを~Oklabへ変換する。
◎
Given XYZ relative to D65, convert to OKLab
 */
	var %XYZtoLMS = [
		[ 0.8190224379967030, 0.3619062600528904, -0.1288737815209879 ],
		[ 0.0329836539323885, 0.9292868615863434,  0.0361446663506424 ],
		[ 0.0481771893596242, 0.2642395317527308,  0.6335478284694309 ]
	];
	var %LMStoOKLab = [
		[ 0.2104542683093140,  0.7936177747023054, -0.0040720430116193 ],
		[ 1.9779985324311684, -2.4285922420485799,  0.4505937096174110 ],
		[ 0.0259040424655478,  0.7827717124575296, -0.8086757549230774 ]
	];

	var %LMS = multiplyMatrices(%XYZtoLMS, %XYZ);
	/* 
~JSの `Math.cbrt^c は、
同じ正負符号を伴う立方~根を返す。
他の言語に~portする場合
— とりわけ，一般な冪乗~関数を利用したくなった場合には —
そのことに留意すること。
◎
JavaScript Math.cbrt returns a sign-matched cube root
beware if porting to other languages especially if tempted to use a general power function
 */
	return multiplyMatrices(%LMStoOKLab, %LMS.map(%c => Math.cbrt(%c)));
	/* 
L の範囲は 0 以上 1 以下。
~CSSにて利用するときは、
100 倍して百分率を追加すること。
◎
L in range [0,1]. For use in CSS, multiply by 100 and add a percent
 */
}

function OKLab_to_XYZ(%OKLab) {
	/* 
所与の~Oklabを~D65に相対的な~XYZへ変換する。
◎
Given OKLab, convert to XYZ relative to D65
 */
	var %LMStoXYZ =  [
		[  1.2268798758459243, -0.5578149944602171,  0.2813910456659647 ],
		[ -0.0405757452148008,  1.1122868032803170, -0.0717110580655164 ],
		[ -0.0763729366746601, -0.4214933324022432,  1.5869240198367816 ]
	];
	var %OKLabtoLMS = [
		[ 1.0000000000000000,  0.3963377773761749,  0.2158037573099136 ],
		[ 1.0000000000000000, -0.1055613458156586, -0.0638541728258133 ],
		[ 1.0000000000000000, -0.0894841775298119, -1.2914855480194092 ]
	];

	var %LMSnl = multiplyMatrices(%OKLabtoLMS, %OKLab);
	return multiplyMatrices(%LMStoXYZ, %LMSnl.map(%c => %c ** 3));
}

function OKLab_to_OKLCH(%OKLab) {
	var %微小数 = 0.000004;
	var %hue = Math.atan2(%OKLab[2], %OKLab[1]) * 180 / Math.PI;
	var %chroma = Math.sqrt(%OKLab[1] ** 2 + %OKLab[2] ** 2);
	if (%hue < 0) {
		%hue = %hue + 360;
	}
	if (%chroma <= %微小数) {
		%hue = NaN;
	}
	return [
		%OKLab[0], /* 
L はそのまま
◎
L is still L
 */
		%chroma,
		%hue
	];
}

function OKLCH_to_OKLab(%OKLCH) {
	return [
		%OKLCH[0], /* 
L はそのまま
◎
L is still L
 */
		%OKLCH[1] * Math.cos(%OKLCH[2] * Math.PI / 180), /* a */
		%OKLCH[1] * Math.sin(%OKLCH[2] * Math.PI / 180)  /* b */
	];
}

/* 
~alpha乗算済み化を行う変換
◎
Premultiplied alpha conversions
 */

function rectangular_premultiply(%color, %alpha) {
/* 
所与の［
矩形な直交-座標による色~空間~内の色 %color,
~alpha値 %alpha
］に対し，乗算済みな形を返す。
◎
given a color in a rectangular orthogonal colorspace and an alpha value return the premultiplied form
 */
	return %color.map((c) => c * %alpha)
}

function rectangular_un_premultiply(%color, %alpha) {
/* 
所与の［
矩形な直交-座標による色~空間~内の色 %color,
~alpha値 %alpha
］に対し，実際の色を返す。
◎
given a premultiplied color in a rectangular orthogonal colorspace and an alpha value return the actual color
 */
	if (%alpha === 0) {
		return %color; /* 
0 で除算するのを避ける
◎
avoid divide by zero
 */
	}
	return %color.map((%c) => %c / %alpha)
}

function polar_premultiply(%color, %alpha, %hueIndex) {
	/* 
所与の［
円柱な極-座標による色~空間~内の色 %color,
~alpha値 %alpha
］に対し，乗算済みな形を返す。
%hueIndex は、
%color 配列~内の どの~entryが色相~角度に対応するかを与える
— 例えば、
~OkLChにおいては 2 になる一方で，~HSLにおいては 0 になる。
◎
given a color in a cylindicalpolar colorspace and an alpha value return the premultiplied form. the index says which entry in the color array corresponds to hue angle for example, in OKLCH it would be 2 while in HSL it would be 0
 */
	return %color.map((%c, %i) => c * (%hueIndex === %i? 1 : %alpha))
}

function polar_un_premultiply(%color, %alpha, %hueIndex) {
	/* 
所与の［
円柱な極-座標による色~空間~内の色 %color,
~alpha値 %alpha
］に対し，実際の（非乗算済み化された）色を返す。
%hueIndex は、
%color 配列~内のどの~entryが色相~角度に対応するかを与える
— 例えば、
~OkLChにおいては 2 になる一方で，~HSLにおいては 0 になる。
◎
given a color in a cylindicalpolar colorspace and an alpha value return the actual color. the hueIndex says which entry in the color array corresponds to hue angle for example, in OKLCH it would be 2 while in HSL it would be 0
 */
	if (%alpha === 0) {
		return %color; /* 
0 で除算するのを避ける
◎
avoid divide by zero
 */
	}
	return %color.map((%c, %i) => %c / (%hueIndex === %i? 1 : %alpha))
}

/* 
便利~関数も容易に定義できる
— 次のように：
◎
Convenience functions can easily be defined, such as
 */
function hsl_premultiply(%color, %alpha) {
	return polar_premultiply(%color, %alpha, 0);
}

20. 色~差の公式

◎非規範的

20.1. 色~差~計量 — 序論

色~差~公式は、 2 つの色の`見え方^emがどれほど異なるかを見積もる。それは、次に挙げる用途に利用され得る： ◎ A color difference formula estimates how different two colors appear. It can be used ＼

品質の確約（色が正しく再現されたかどうかを測定する） ◎ for quality assurance (measuring whether a reproduced color is correct), ＼
ある種の`色域~対応付け$ （色域~外にある色を色域~内にある色へ変換する際に，それらの色~差を最小~化する） ◎ or for some types of gamut mapping, where the color difference between the out of gamut and in-gamut colors is minimized.

歴史的に，各種~色~差~公式が成す一般~classは、 ~DeltaE（ `delta E^en ）と呼ばれる — ~DeltaE の E は、 ~German単語 “Empfindung” の略であり， “感覚（ `sensation^en ）” を表す。 ◎ Historically, the general class of color difference formulae is called ΔE (delta E); where the E is short for Empfindung, the German word for "sensation".

最も単純な色~差~計量 ~DeltaE 76 は、単純に~CIE~Lab色~空間~内の~Euclidean距離であり， 1976年に初めて国際-標準になった。 ◎ The simplest color difference metric, ΔE76, is simply the Euclidean distance in CIE Lab color space, which first became an International Standard in 1976.

~DeltaE 76 は，最初の近似としては良かったが、 ~CIE~Labの制限が~~判明するに伴い，色に~criticalな業界 — 印刷ngや織物染色など — は改善された公式をすぐに開発した。 ◎ While ΔE76 is a good first approximation, color-critical industries such as printing and fabric dyeing soon developed improved formulae as the limitations of CIE Lab became evident.

公式がより複階的になるに伴い，実用的な実装は［予測上の正確度と算出上の複階-度（したがって，速さ）の~tradeoff ］が必要になった。 ◎ As formulae became more complex, practical implementations needed to trade off predictive accuracy against computational complexity (and thus, speed).

20.2. ~DeltaE 2000

現時点で最も広く利用されている公式は、 ~DeltaE 2000 である。それは、 ~DeltaE 76 に比して，いくつかの既知な［非対称性, 非-線形~性］を正す。公式は複階的であり，様々な中間~計算の正負符号に~criticalに依存するので、不正な実装が多い `Sharma$r 。 ◎ Currently, the most widely used formula is ΔE2000. It corrects a number of known asymmetries and non-linearities compared to ΔE76. Because the formula is complex, and critically dependent on the sign of various intermediate calculations, implementations are often incorrect [Sharma].

以下に与える見本~codeは、有効数字 5 桁に対し， `Sharma$r により公表された［一群の~pair ( ~Lab値, 期待される~DeltaE 2000 ) からなる~test一式］に突き合わせた結果、正しいことが`検証-済み＠https://colorjs.io/test/?test=delta$である。 ◎ The sample code below has been validated to five significant figures against the test suite of paired Lab values and expected ΔE2000 published by [Sharma] and is correct.

/* 
~DeltaE 2000は、［
~DeltaE 76, ~DeltaE 94
］に対する統計的に有意な改善であり、
とりわけ，［
~DeltaE 76における色~差 10 未満
］用に［
~CIEと `Idealliance^en~FN
］により推奨されるが、
意地悪で複雑であり，多くの実装には小さな誤りがある。
【~FN おそらく， `IDEAlliance^en （ `International Digital Enterprise Alliance^en の略語）】
◎
deltaE2000 is a statistically significant improvement over deltaE76 and deltaE94, and is recommended by the CIE and Idealliance especially for color differences less than 10 deltaE76 but is wicked complicated and many implementations have small errors!
 */

/**
 * @param {number[]} %reference — ~CIE~Lab値を成す配列： L は 0..100, a と b は -150..150 周辺
 * @param {number[]} %sample — ~CIE~Lab値を成す配列： L は 0..100, a と b は -150..150 周辺
 * @return {number} — %reference から %sample までの色~差
 */
◎
/**
 * @param {number[]} reference - Array of CIE Lab values: L as 0..100, a and b as around -150..150
 * @param {number[]} sample - Array of CIE Lab values: L as 0..100, a and b as around -150..150
 * @return {number} How different a color sample is from reference
 */
function deltaE2000 (%reference, %sample) {

	/* 
所与の［
基準~色 %reference, 見本~色 %sample
］（どちらも~CIE~Lab内）に対し，~DeltaE 2000 を計算する。
◎
Given a reference and a sample color, both in CIE Lab, calculate deltaE 2000.
 */

	/* 
この実装は、
~parameter化された重み付け係数［
%kL, %kC, %kH
］（観視~条件による波及-用）を，すべて 1 と見做す
— それが代表的と見受けられるので。
◎
This implementation assumes the parametric weighting factors kL, kC and kH (for the influence of viewing conditions) are all 1, as seems typical.
 */

	let [%L1, %a1, %b1] = %reference;
	let [%L2, %a2, %b2] = %sample;
	let %C1 = Math.sqrt(%a1 ** 2 + %b1 ** 2);
	let %C2 = Math.sqrt(%a2 ** 2 + %b2 ** 2);

	let %Cbar = (%C1 + %C2)/2; /* 
平均m色度
◎
mean Chroma
 */

	/* 
平均m色度から a 軸~非対称性~係数を計算する。
これは、
中立に近い色~用の`~JND$楕円を真円に戻すよう転じる。
◎
calculate a-axis asymmetry factor from mean Chroma this turns JND ellipses for near-neutral colors back into circles
 */
	let %C7 = Math.pow(%Cbar, 7);
	const %Gfactor = Math.pow(25, 7);
	let %G = 0.5 * (1 - Math.sqrt(%C7/(%C7 + %Gfactor)));

	/* 
a 軸~非対称性~係数により拡縮する
— ちなみに、
 “Lab2000” 色~空間が無いわけは，このことによる。
◎
scale a axes by asymmetry factor this by the way is why there is no Lab2000 color space
 */
	let %adash1 = (1 + %G) * %a1;
	let %adash2 = (1 + %G) * %a2;

	/* 
拡縮した a 軸と元の b 軸から新たな色度を計算する
◎
calculate new Chroma from scaled a and original b axes
 */
	let %Cdash1 = Math.sqrt(%adash1 ** 2 + %b1 ** 2);
	let %Cdash2 = Math.sqrt(%adash2 ** 2 + %b2 ** 2);

	/* 
新たな色相を
— ~radianではなく度数として —
計算する。
真に中立な色~用の色相は 0 にする。
◎
calculate new hues, with zero hue for true neutrals and in degrees, not radians
 */
	const %π = Math.PI;
	const %r2d = 180 / %π;
	const %d2r = %π / 180;
	let %h1 = (%adash1 === 0 && %b1 === 0)? 0: Math.atan2(%b1, %adash1);
	let %h2 = (%adash2 === 0 && %b2 === 0)? 0: Math.atan2(%b2, %adash2);

	if (%h1 < 0) {
		%h1 += 2 * %π;
	}
	if (%h2 < 0) {
		%h2 += 2 * %π;
	}

	%h1 *= %r2d;
	%h2 *= %r2d;

	/* 
明度~差と色度~差
— 正負符号も問われる。
◎
Lightness and Chroma differences; sign matters
 */
	let %ΔL = %L2 - %L1;
	let %ΔC = %Cdash2 - %Cdash1;

	/* 
色相~差
— 正負符号を正しく取得するよう~careする下で。
◎
Hue difference, taking care to get the sign correct
 */
	let %hdiff = %h2 - %h1;
	let %hsum = %h1 + %h2;
	let %habs = Math.abs(%hdiff);
	let %Δh;

	if (%Cdash1 * %Cdash2 === 0) {
		%Δh = 0;
	}
	else if (%habs <= 180) {
		%Δh = %hdiff;
	}
	else if (%hdiff > 180) {
		%Δh = %hdiff - 360;
	}
	else if (%hdiff < -180) {
		%Δh = %hdiff + 360;
	}
	else {
		console.log("the unthinkable has happened");
	}

	/* 
重み付き色相~差
— 色度が大きいほど大きくなる
◎
weighted Hue difference, more for larger Chroma
 */
	let %ΔH = 2 * Math.sqrt(%Cdash2 * %Cdash1) * Math.sin(%Δh * %d2r / 2);

	/* 
平均m明度と平均m色度を計算する
◎
calculate mean Lightness and Chroma
 */
	let %Ldash = (%L1 + %L2)/2;
	let %Cdash = (%Cdash1 + %Cdash2)/2;
	let %Cdash7 = Math.pow(%Cdash, 7);

	/* 
~Labの~blue領域における非-線形~性を補償する。
色相の重み付け係数~用の，角度に依存している 4 つのアリ性に応じて、
正しい正負符号を取得する。
◎
Compensate for non-linearity in the blue region of Lab. Four possibilities for hue weighting factor, depending on the angles, to get the correct sign
 */
	let %hdash;
	if (%Cdash1 * %Cdash2 === 0) {
		%hdash = %hsum;
	}
	else if (%habs <= 180) {
		%hdash = %hsum / 2;
	}
	else if (%hsum < 360) {
		%hdash = (%hsum + 360) / 2;
	}
	else {
		%hdash = (%hsum - 360) / 2;
	}

	/* 
`CIELAB$r における一様~性の欠如に対する位置的な補正。
これらは、
すべての`~JND$楕円体を球体に近づけようと試行する
◎
positional corrections to the lack of uniformity of CIELAB These are all trying to make JND ellipsoids more like spheres
 */

	/* 
%SL 明度 `crispening^en 係数
— 背景は L ~EQ 50 と見做される
◎
SL Lightness crispening factor a background with L=50 is assumed
 */
	let %lsq = (%Ldash - 50) ** 2;
	let %SL = 1 + ((0.015 * %lsq) / Math.sqrt(20 + %lsq));

	/* 
%SC 色度~係数
— ［
CMC~FN や~DeltaE 94
］公式におけるそれらに類似な。
【~FN おそらく， `Colour Measurement Committee^en （ “色~測定~委員会” ）により定義される `CMC l:c＠https://en.wikipedia.org/wiki/Color_difference#CMC_l:c_(1984)$ 】
◎
SC Chroma factor, similar to those in CMC and deltaE 94 formulae
 */
	let %SC = 1 + 0.045 * %Cdash;

	/* 
~blue領域における非-線形~性を織り込むための `cross^en 項~FN %T
【~FN 平たく言えば、 2 つの独立~変数の積】
◎
Cross term T for blue non-linearity
 */
	let %T = 1;
	%T -= (0.17 * Math.cos((     %hdash - 30)  * %d2r));
	%T += (0.24 * Math.cos(  2 * %hdash        * %d2r));
	%T += (0.32 * Math.cos(((3 * %hdash) + 6)  * %d2r));
	%T -= (0.20 * Math.cos(((4 * %hdash) - 63) * %d2r));

	/* 
色相~係数 %SH は、
色度にも，（~DeltaE 94 と同様に）調整した色相~角度にも依存する。
◎
SH Hue factor depends on Chroma, as well as adjusted hue angle like deltaE94.
 */
	let %SH = 1 + 0.015 * %Cdash * %T;

	/* 
色度が高めな~blue領域（色相 225 〜 315）における［
`~JND$楕円, ~Munsell定数~色相~線
］の回転~用に，色相~回転~項 %RT を補償する。
◎
RT Hue rotation term compensates for rotation of JND ellipses and Munsell constant hue lines in the medium-high Chroma blue region (Hue 225 to 315)
 */
	let %Δθ = 30 * Math.exp(-1 * (((%hdash - 275)/25) ** 2));
	let %RC = 2 * Math.sqrt(%Cdash7/(%Cdash7 + %Gfactor));
	let %RT = -1 * Math.sin(2 * %Δθ * %d2r) * %RC;

	/* 
最後に、
~DeltaE を二乗和の平方根として計算する。
◎
Finally calculate the deltaE, term by term as root sum of squares
 */
	let %dE = (%ΔL / %SL) ** 2;
	%dE += (%ΔC / %SC) ** 2;
	%dE += (%ΔH / %SH) ** 2;
	%dE += %RT * (%ΔC / %SC) * (%ΔH / %SH);
	return Math.sqrt(%dE);
	/* 
~~完遂。
◎
Yay!!!
 */
};

20.3. ~DeltaE~OK

~Oklabには、 ~CIE~Labの［色相の線形~性, 色相の一様~性, 色度の非-線形~性］のような難はないので，色~差~計量を正す必要は無い — なので，~DeltaE~OKは、単純に，~Oklab色~空間~内の~Euclidean距離になる。 ◎ Because Oklab does not suffer from the hue linearity, hue uniformity, and chroma non-linearities of CIE Lab, the color difference metric does not need to correct for them and so ΔEOK is simply the Euclidean distance in Oklab color space.

/* 
~DeltaE~OKを計算する。
単純な，二乗和の平方根。
◎
Calculate deltaE OK
simple root sum of squares
 */

/**
 * @param {number[]} %reference — ~Oklab値を成す配列： L は 0..1, a と b は -1..1
 * @param {number[]} %sample — ~Oklab値を成す配列： L は 0..1, a と b は -1..1
 * @return {number} — %reference から %sample までの色~差
 */
◎
/**
 * @param {number[]} reference - Array of OKLab values: L as 0..1, a and b as -1..1
 * @param {number[]} sample - Array of OKLab values: L as 0..1, a and b as -1..1
 * @return {number} How different a color sample is from reference
 */
function deltaEOK (%reference, %sample) {
	let [%L1, %a1, %b1] = %reference;
	let [%L2, %a2, %b2] = %sample;
	let %ΔL = %L1 - %L2;
	let %Δa = %a1 - %a2;
	let %Δb = %b1 - %b2;
	return Math.sqrt(%ΔL ** 2 + %Δa ** 2 + %Δb ** 2);
}

20.4. ~DeltaE~OK2

色~差~計量~DeltaE~OKは、明度における差に比較して，色彩度における差を過小に見積もる。実験nから、［ a 成分どうしの差, b 成分どうしの差］を`係数 2 で拡縮すること＠~CSSissue/6642#issuecomment-945714988$により，［ `~Oklabに基づく~DeltaEの予測上の正確度は、~DeltaE 2000と比較して，大幅に上がる＠https://github.com/svgeesus/deltaE-OK2/tree/main$ ］ことが露わになった。これは、今や広く採用された~Oklabの定義を変更する代わりに，別の距離~計量 ~DeltaE~OK2を生産する。 ◎ As a color difference metric, ΔEOK under-estimates differences in colorfulness, compared to differences in lightness. Experimentation revealed that scaling a and b by a factor of 2, greatly increased the predictive accuracy of an Oklab-based ΔE, when compared to ΔE2000. Instead of changing the definition of Oklab, which is now widely adopted, this produces another distance metric ΔEOK2.

/* 
~DeltaE~OK2を計算する
◎
Calculate deltaE OK2
 */
/* 
［
a どうしの差, b どうしの差
］を 2 倍した上で，二乗和の平方根をとる
◎
root sum of squares, scale a and b by 2
 */
/**
 * @param {number[]} %reference — ~Oklab値を成す配列： L は 0..1, a と b は -1..1
 * @param {number[]} %sample — ~Oklab値を成す配列： L は 0..1, a と b は -1..1
 * @return {number} — %reference から %sample までの色~差
 */
◎
/**
 * @param {number[]} reference - Array of OKLab values: L as 0..1, a and b as -1..1
 * @param {number[]} sample - Array of OKLab values: L as 0..1, a and b as -1..1
 * @return {number} How different a color sample is from reference
 */

function deltaEOK2 (%reference, %sample) {
    let [%L1, %a1, %b1] = %reference;
	let [%L2, %a2, %b2] = %sample;
	let %ΔL = %L1 - %L2;
	let %Δa = 2 * (%a1 - %a2);
	let %Δb = 2 * (%b1 - %b2);
	return Math.sqrt(%ΔL ** 2 + %Δa ** 2 + %Δb ** 2);
}

20.5. ~DeltaE ~OKr2

［明度~軸に，`ある “~toe” を加える＠https://bottosson.github.io/posts/colorpicker/#intermission---a-new-lightness-estimate-for-oklab$ ］よう改変することにより，更に改善できる。これは、特に，有意な明順応（ `white adaptive stimulus^en ）が生じるとき（例えば、ある~web~pageの背景~色が， `明な~mode＠~CSSCOLORADJUST#light-color-scheme$に切り替えたとき~whiteになるとき）に役立つ。また、明度~曲線を~CIE~Labのそれに近付ける。 ◎ A further improvement can be made by modifying the Lightness axis to add a "toe". This is particularly helpful where there is a significant white adaptive stimulus (for example, a light-mode web page with a white background). It also makes the lighness curve more similar to that of CIE Lab.

＊［ ~Oklrab, ~CIE~Lab ］の明度~関数を~Oklabと比較した図。 ◎ Lightness functions of Oklrab and CIE Lab compared to Oklab.

色~差~計量においては、これは，［ a, b ］成分に対する拡縮-法との組合nで利用される。 ◎ In a color difference metric, this is used in combination with the a and b scaling.

これは，元の~DeltaE~OKよりいくぶん複階的になるが、この方が，~DeltaE 2000 との一致度が有意に良くなり、しかも，~DeltaE 2000 よりもずっと複階的でない。 ◎ While this is somewhat more complex than the original ΔEOK, it agrees significantly better with ΔE2000, while still being far less complex than ΔE2000.

処理能に敏感な実装には、色~差~計量として~DeltaE~OKr2を利用することが奨励される。 ◎ Implementations which are performance-sensitive are encouraged to use ΔEOKr2 as a color difference metric.

/* 
~DeltaE~OKr2を計算する
◎
Calculate deltaE OKr2
 */
/* 
［
a の差, b の差
］を 2 倍して, 明度に対し~toeを加えた上で，
二乗和の平方根をとる
◎
root sum of squares, lightness toe, scale a and b by 2
 */
/**
 * @param {number[]} %reference — ~Oklab値を成す配列： L は 0..1, a と b は -1..1
 * @param {number[]} %sample — ~Oklab値を成す配列： L は 0..1, a と b は -1..1
 * @return {number} — %reference から %sample までの色~差
 */
◎
/**
 * @param {number[]} reference - Array of OKLab values: L as 0..1, a and b as -1..1
 * @param {number[]} sample - Array of OKLab values: L as 0..1, a and b as -1..1
 * @return {number} How different a color sample is from reference
 */
function deltaEOKr2 (%reference, %sample) {
    let [%L1, %a1, %b1] = %reference;
	let [%L2, %a2, %b2] = %sample;
	%L1 = toe(%L1);
	%L2 = toe(%L2);
	let %ΔL = %L1 - %L2;
	let %Δa = 2 * (%a1 - %a2);
	let %Δb = 2 * (%b1 - %b2);
	return Math.sqrt(%ΔL ** 2 + %Δa ** 2 + %Δb ** 2);
}

/* 
明度~toeを加える
◎
Add a lightness toe
 */
// https://bottosson.github.io/posts/colorpicker/#intermission---a-new-lightness-estimate-for-oklab
/**
 * @param {number} %x — ~Oklab明度
 * @return {number} ~toeされた明度
 */
◎
/**
 * @param {number} x - Oklab lightness
 * @return {number} Toed lightness
 */
function toe (%x) {
	const %K1 = 0.206;
	const %K2 = 0.03;
	const %K3 = (1.0 + %K1) / (1.0 + %K2);
	return 0.5 * (%K3 * %x - %K1 + Math.sqrt((%K3 * %x - %K1) * (%K3 * %x - %K1) + 4 * %K2 * %K3 * %x));
}

付録 A. 非推奨にされた~CSS~system色

~CSSの早期の~versionは、追加的な~system色をいくつか定義していた。しかしながら、これらの色~keywordは，次に挙げる~~理由から非推奨にされた： ◎ Earlier versions of CSS defined several additional system colors. These color keywords have been deprecated, however,＼

その元々の目的（~web~siteの要素を ~native~OSに~~相当する見かけにする）には不足である。 ◎ as they are insufficient for their original purpose (making website elements look like their native OS counterparts),＼
~web~pageが~native~OSの~dialogを “偽装する” のが容易になり，~security~riskになる。 ◎ represent a security risk by making it easier for a webpage to “spoof” a native OS dialog,＼
指紋収集~表口が広がる結果，利用者の~privacyが弱体化される。 ◎ and increase fingerprinting surface, compromising user privacy.

~UAは，これらの~keywordを~supportするモノトスルが、指紋収集を軽減するため，それらは［以下に挙げるとおり，（非推奨dでない）`~system色$に対応付ける］モノトスル。 作者は、これらの~keywordを利用してはナラナイ。 ◎ User agents must support these keywords, and to mitigate fingerprinting must map them to the (undeprecated) system colors as listed below. Authors must not use these keywords.

非推奨にされた~system色は、下位-型 `deprecated-color@t として表現され，次で定義される（以下に現れる “同対象” は、直前に挙げた~keywordに述べたそれと同じ対象を指すとする）： ◎ The deprecated system colors are represented as the <deprecated-color> sub-type, and are defined as:

【各~keywordの前に示される色見本（この訳による追加）は、利用-中な~UAにおける色（`利用-中な色~scheme＠~CSSCOLORADJUST#used-color-scheme$に依存し得る）。色見本が市松模様に現れるものは、利用-中な~UAが~supportしていない（または本当に透明にされている）。】

`ActiveBorder^swatch `ActiveBorder@vD: ［作動中な~UIwindow ］の~border。 ◎ Active window border.＼; `ButtonBorder$vS の色に算出される。 ◎ Computes to the color of ButtonBorder.
`ActiveCaption^swatch `ActiveCaption@vD: 同対象の~caption。 ◎ Active window caption.＼; `Canvas$vS の色に算出される。 ◎ Computes to the color of Canvas.
`AppWorkspace^swatch `AppWorkspace@vD: 複数の文書~interfaceの背景。 ◎ Background color of multiple document interface.＼; `Canvas$vS の色に算出される。 ◎ Computes to the color of Canvas.
`Background^swatch `Background@vD: ~desktop背景。 ◎ Desktop background.＼; `Canvas$vS の色に算出される。 ◎ Computes to the color of Canvas.
`ButtonHighlight^swatch `ButtonHighlight@vD: ［周囲の~border層に因り立体的に現れる要素］の［光源に近い方にある~border ］。 ◎ The color of the border facing the light source for 3-D elements that appear 3-D due to one layer of surrounding border.＼; `ButtonFace$vS の色に算出される。 ◎ Computes to the color of ButtonFace.
`ButtonShadow^swatch `ButtonShadow@vD: 同対象の［光源から離れた方にある~border ］。 ◎ The color of the border away from the light source for 3-D elements that appear 3-D due to one layer of surrounding border.＼; `ButtonFace$vS の色に算出される。 ◎ Computes to the color of ButtonFace.
`CaptionText^swatch `CaptionText@vD: ［ ~caption／~size~box／~scrollbar矢印~box ］内の~text。 ◎ Text in caption, size box, and scrollbar arrow box.＼; `CanvasText$vS の色に算出される。 ◎ Computes to the color of CanvasText.
`InactiveBorder^swatch `InactiveBorder@vD: ［作動中でない~UIwindow ］の~border。 ◎ Inactive window border.＼; `ButtonBorder$vS の色に算出される。 ◎ Computes to the color of ButtonBorder.
`InactiveCaption^swatch `InactiveCaption@vD: 同対象の~caption。 ◎ Inactive window caption.＼; `Canvas$vS の色に算出される。 ◎ Computes to the color of Canvas.
`InactiveCaptionText^swatch `InactiveCaptionText@vD: 同対象の［ ~caption内の~text ］。 ◎ Color of text in an inactive caption.＼; `GrayText$vS の色に算出される。 ◎ Computes to the color of GrayText.
`InfoBackground^swatch `InfoBackground@vD: ~tooltipの背景。 ◎ Background color for tooltip controls.＼; `Canvas$vS の色に算出される。 ◎ Computes to the color of Canvas.
`InfoText^swatch `InfoText@vD: 同対象の~text。 ◎ Text color for tooltip controls.＼; `CanvasText$vS の色に算出される。 ◎ Computes to the color of CanvasText.
`Menu^swatch `Menu@vD: ~menuの背景。 ◎ Menu background.＼; `Canvas$vS の色に算出される。 ◎ Computes to the color of Canvas.
`MenuText^swatch `MenuText@vD: 同対象の~text。 ◎ Text in menus.＼; `CanvasText$vS の色に算出される。 ◎ Computes to the color of CanvasText.
`Scrollbar^swatch `Scrollbar@vD: ~scrollbarの~gray区画。 ◎ Scroll bar gray area.＼; `Canvas$vS の色に算出される。 ◎ Computes to the color of Canvas.
`ThreeDDarkShadow^swatch `ThreeDDarkShadow@vD: ［周囲の~borderを成す 2 つの同心な層に因り，立体的に現れる要素］の［光源から離れた方にある 2 本の~border ］のうち暗な方（一般に外縁）。 ◎ The color of the darker (generally outer) of the two borders away from the light source for 3-D elements that appear 3-D due to two concentric layers of surrounding border.＼; `ButtonBorder$vS の色に算出される。 ◎ Computes to the color of ButtonBorder.
`ThreeDFace^swatch `ThreeDFace@vD: 同対象の［ ~~表面の背景］。 ◎ The face background color for 3-D elements that appear 3-D due to two concentric layers of surrounding border.＼; `ButtonFace$vS の色に算出される。 ◎ Computes to the color of ButtonFace.
`ThreeDHighlight^swatch `ThreeDHighlight@vD: 同対象の［光源に近い方にある 2 本の~border ］のうち明な方（一般に外縁）。 ◎ The color of the lighter (generally outer) of the two borders facing the light source for 3-D elements that appear 3-D due to two concentric layers of surrounding border.＼; `ButtonBorder$vS の色に算出される。 ◎ Computes to the color of ButtonBorder.
`ThreeDLightShadow^swatch `ThreeDLightShadow@vD: 同対象の［光源に近い方にある 2 本の~border ］のうち暗な方（一般に内縁）。 ◎ The color of the darker (generally inner) of the two borders facing the light source for 3-D elements that appear 3-D due to two concentric layers of surrounding border.＼; `ButtonBorder$vS の色に算出される。 ◎ Computes to the color of ButtonBorder.
`ThreeDShadow^swatch `ThreeDShadow@vD: 同対象の［光源から離れた方にある 2 本の~border ］のうち明な方（一般に内縁） ◎ The color of the lighter (generally inner) of the two borders away from the light source for 3-D elements that appear 3-D due to two concentric layers of surrounding border.＼; `ButtonBorder$vS の色に算出される。 ◎ Computes to the color of ButtonBorder.
`Window^swatch `Window@vD: ~UIwindowの背景。 ◎ Window background.＼; `Canvas$vS の色に算出される。 ◎ Computes to the color of Canvas.
`WindowFrame^swatch `WindowFrame@vD: ~UIwindowの枠。 ◎ Window frame.＼; `ButtonBorder$vS の色に算出される。 ◎ Computes to the color of ButtonBorder.
`WindowText^swatch `WindowText@vD: ~UIwindow内の~text。 ◎ Text in windows.＼; `CanvasText$vS の色に算出される。 ◎ Computes to the color of CanvasText.

付録 B. 非推奨にされた過去互換~用の~hex色

~CSSが`過去互換~mode$の下で構文解析されるときは、以下に挙げる~propに限り， `color$t 型の一種である `quirky-color@t が妥当になる： ◎ When CSS is being parsed in quirks mode, <quirky-color> is a type of <color> that is only valid in certain properties:

`background-color$p
`border-color$p
`border-top-color$p
`border-right-color$p
`border-bottom-color$p
`border-left-color$p
`color$p

`quirky-color$t は： ◎ ↓

次に挙げる所では，`妥当でない^em： ◎ It is not valid＼
- 上に挙げた~propを［内包する／参照する］~prop — 例： `background$p 略式~prop。 ◎ in properties that include or reference these properties, such as the background shorthand,＼
- `color-mix$f などの`関数-記法$の内側。 ◎ or inside functional notations such as color-mix()
上に挙げた~propを `supports$at 規則~内で構文解析するときは、 `color$t として妥当になるモノトスル — `CSS.supports()$c ~methodにて利用されたときは、 `妥当でない^em。 ◎ Additionally, while <quirky-color> must be valid as a <color> when parsing the affected properties in the @supports rule, it is not valid for those properties when used in the CSS.supports() method.

`quirky-color$t は、［ `number-token$t ／ `dimension-token$t ／ `ident-token$t ］として表現され得る — 以下に与える規則に則って： ◎ A <quirky-color> can be represented as a <number-token>, <dimension-token>, or <ident-token>, according to the following rules:

`ident-token$t である場合 ◎ If it’s an <ident-token>,＼: 当の~tokenの .値は、すべて~hex数字, かつ［正確に 3 個または 6 個の文字］を包含しなければナラナイ。【さもなければ、妥当でない。】それは、同じ値を伴う `hex-color$t を表現する。 ◎ the token’s representation must contain exactly 3 or 6 characters, all hexadecimal digits. It represents a <hex-color> with the same value.; 【例：文字列 `ABC^l は、 .値 `ABC^l を伴う `ident-token^t に構文解析され， 3 桁の~hex記法 `#ABC^v に等価と見なされる。】
`number-token$t である場合 ◎ If it’s a <number-token>,＼: 当の~tokenの .型~flag ~EQ `整数^i でなければナラナイ。【さもなければ、妥当でない。】 ◎ it must have its integer flag set.; 当の~tokenの .数値を直列化する — 結果が 6 文字~未満になる場合、 6 文字になるまで，文字 `0^l を前付加する。それは、同じ値を伴う `hex-color$t を表現する。 ◎ Serialize the integer’s value. If the serialization has less than 6 characters, prepend "0" characters to it until it is 6 characters long. It represents a <hex-color> with the same value.; 【例：文字列 `123^l は、 .数値 123 を伴う `number-token^t に構文解析され， 6 桁の~hex記法 `#000123^v に等価と見なされる。】【結果が 7 文字~以上の場合にどうなるかは、述べられていない（ 8 桁の~hex記法として解釈する余地もある — 8 桁~記法は、過去互換の趣旨に沿わないように思われるが）。】
`dimension-token$t である場合 ◎ If it’s a <dimension-token>,＼: 当の~tokenの .型~flag ~EQ `整数^i でなければナラナイ。【さもなければ、妥当でない。】 ◎ it must have its integer flag set.; 当の~tokenの .数値を直列化して，当の~tokenの .単位を付加する — 結果が 6 文字~未満になる場合、 6 文字になるまで文字 `0^l を前付加する。それは、同じ値を伴う `hex-color$t を表現する。 ◎ Serialize the integer’s value, and append the representation of the token’s unit. If the result has less than 6 characters, prepend "0" characters to it until it is 6 characters long. It represents a <hex-color> with the same value.; 【例：文字列 `123FF^l は、 .数値 123, .単位 `FF^u を伴う `dimension-token^t に構文解析され， 6 桁の~hex記法 `#0123FF^v に等価と見なされる。】【 .単位に~hex数字~以外の文字がある場合、妥当でないと見なされよう。】

（言い換えれば，`過去互換~mode$の下では、 ~hex色は，先頭の `#^l を~~省いて書くことも許容される — ~~理解し難い構文解析~規則を伴うが。） ◎ (In other words, Quirks Mode allows hex colors to be written without the leading "#", but with weird parsing rules.)

謝辞

~level 3 に貢献された方々に加えて、次の方々に感謝する： ◎ In addition to those who contributed to CSS Color 3, the editors would like to thank＼

Emilio Cobos Álvarez, Alexey Ardov, Chris Bai, Amelia Bellamy-Royds, Lars Borg, Mike Bremford, Andreu Botella, Dan Burzo, Max Derhak, fantasai, Simon Fraser, Devon Govett, Phil Green, Dean Jackson, Andreas Kraushaar, Pierre-Anthony Lemieux, Tiaan Louw, Cameron McCormack, Romain Menke, Chris Murphy, Isaac Muse, Jonathan Neal, Chris Needham, Björn Ottosson, Christoph Päper, Brad Pettit, Xidorn Quan, Craig Revie, Melanie Richards, Florian Rivoal, Jacob Rus, Joseph Salowey, Simon Sapin, Igor Snitkin, Lea Verou, Mark Watson, James Stuckey Weber, Sam Weinig, and Natalie Weizenbaum.

変更点

`2025年 4月 24日勧告候補~草案＠~TR/2025/CRD-css-color-4-20250424/$ からの変更点 ◎ Changes since the Candidate Recommendation Draft of 24 April 2025

定義済み色~空間［ `srgb$v, `display-p3$v, `a98-rgb$v, `prophoto-rgb$v, `rec2020$v ］用の視覚-化~図式を（~CIE~Labから【！alongside the existing CIE】） ~Oklab a,b 平面の図式に差し替えた。 ◎ Added Oklab a,b plane diagrams for the sRGB, display-p3, a98-rgb, prophoto-rgb, and rec2020 predefined color spaces, alongside the existing CIE Lab diagrams

【`§ 色~補間＠#interpolation$ において】 “`色を変換~用に準備する$” を参照することを避けて，直に言明するようにした。（ `14049$issue ） ◎ Avoid referencing "prepare for conversion", just state directly (Issue 14049)

非推奨にされた~system色の算出d値は、それに対応する（非推奨dでない）`~system色$と同じになることを明確化した。（ `3873$issue, `13459$issue, `13719$issue ） ◎ Clarified that the computed value of a deprecated system color is the color of the corresponding (non-deprecated) system color (Issue 3873, Issue 13459>, Issue 13719)

［ ~system色, 非推奨にされた~system色］の解決-法を~~統合した。（ `13450$issue ） ◎ Consolidated the resolution of system colors and deprecated system colors (Issue 13450)

色~補間における`先へ運ばれ$る成分について，明確化した。（ `14134$issue ） ◎ Clarified carry-forward in color interpolation (Issue 14134)

~alpha値の直列化を［旧来の色~構文, 現代の色~構文］どちらが利用されたかに応じて分割した。【後者における】~alpha成分には 16 ~bitを要求するようにした。（ `13994$issue ） ◎ Split serialization of alpha values by whether legacy and modern syntax was used; require 16bit alpha (Issue 13994)

`color$f の構文において， `display-p3-linear$v を一貫して言及するようにした。（ `PR #14024＠https://github.com/w3c/csswg-drafts/pull/14024$ ） ◎ Consistent mention of display-p3-linear in color(...) syntax (PR 14024)

§ `~system色$【！the color-scheme section】を【！'page color scheme' and】要素の`色~scheme$elの概念を利用するよう作業し直した。（ `PR #13857＠https://github.com/w3c/csswg-drafts/pull/13857$ ） ◎ Rework the color-scheme section to use the concepts of 'page color scheme' and 'element color scheme' (Issue 13857)

~sRGBの直列化~形を `none$v の有無に応じて~~選ぶようにした。（ `10254$issue ） ◎ Pick sRGB serialization form by presence of none (Issue 10254)

~Oklabにおける色の比較~用には、微小数は 0.00001 に標準~化されるものとした。（ `13157$issue ） ◎ For color comparisons in Oklab, standardized ε to be 0.00001 (Issue 13157)

2 つの `color$t 値が`等価な色$か否かを定義するための節を新たに追加した — それは、次を受持つ（ `13157$issue ） ⇒＃同じ色~空間どうしにおける成分~比較, `欠落~成分$の扱い, `oklab$v を介した異なる色~空間どうしにおける比較 ◎ Added a new section defining when two <color> values are equivalent colors, covering same-color-space component comparison, the treatment of missing components, and cross-color-space comparison via oklab. (Issue 13157)

`§ 色~補間＠#interpolation$ において，［色相~補間~methodが指定されなかった場合の既定が `shorter^v になること］を明確化した（これは、 `§ 色相の補間＠#hue-interpolation$ においては，すでに指定されていた）。（ `13788$issue ） ◎ Clarified in the main Color interpolation section that, if the hue interpolaton method is not specified, shorter is the default. (This was already specified in the Hue Interpolation section). (Issue 13788)

`none$v から `0^v への変換を最小限にするため、 `相似的な成分$に加えて`相似的な集合$の概念も定義した。（ `10210$issue ） ◎ Expanded the concept of analogous components to analogous sets of components, to minimize none → 0 conversions (Issue 10210)

色~変換を 2 段階を経るよう分割した。（ `10211$issue ） ◎ Split color conversion into two stages (Issue 10211)

`~system色$が`利用される色~scheme$【要素の`色~scheme$el】にどう反応するかを明確化した。（ `13719$issue ） ◎ Clarified how system colors react to the used color scheme (Issue 13719)

要約aを更新した — 色~補間と色域~対応付けを言及するよう。 ◎ Updated abstract to mention color interpolation and gamut mapping.

~CSS色域~対応付けが目指すものに関する言い回しを明確化した。 ◎ Clarified wording regarding the aims of CSS gamut mapping

射線~trace色域~対応付け~algoにおいて %終端を上書しないよう正した。（ `10579$issue ） ◎ Corrected ray trace algorithm to not overwrite end (Issue 10579)

射線~trace色域~対応付け~algo用の疑似-~codeを追加した。（ `10579$issue ） ◎ Added pseudocode for the ray trace gamut mapping algorithm (Issue 10579)

［ ~EdgeSeeker色域~対応付け~algo, 射線~trace色域~対応付け~algo ］を追加して， 3 種の色域~対応付け~algoから選ぶことを許容した。（ `10579$issue ） ◎ Added EdgeSeeker and Ray Trace Gamut Mapping Algorithms. Allowed choice of three GMA (Issue 10579)

~CIE~Labにおける想像上の色を示している図式を追加した。 ◎ Added a diagram showing imaginary colors in CIE Lab

色域~外にあるが物理的に実現-可能な色と想像上の色とを区別するようにした。 ◎ Differentiated between out of gamut but physically realizable colors, and imaginary colors

【色域~対応付け~algoにおける】~clip法を【処理能に関して】もっと公平に述べて，受容-可能な結果を与える事例を示した。（ `10579$issue ） ◎ More even-handed description of clipping, showing some cases which give acceptable results (Issue 10579)

~DeltaE 2000 の見本~実装における不具合を修正した。（ `13322$issue ） ◎ Fixed discrepency in ΔE2000 sample implementation (Issue 13322)

`AccentColor$vS は［ `強制d色~mode$が可能化されていない限り，その値を `accent-color$p からとる］よう更新した。（ `5900$issue ） ◎ Updated AccentColor to take its value from accent-color, unless in Forced Colors Mode (Issue 5900)

`rec2020$v 色~空間を［ `display-referred^en, ~gamma 2.4 ］を利用するよう定義した。（ `12574$issue ） ◎ Defined rec2020 color space to use display-referred, 2.4 gamma (Issue 12574)

定義済み色~空間として `display-p3-linear$v を追加した。（ `11250$issue ） ◎ Added display-p3-linear to predefined colorspaces (Issue 11250)

`calc$f を伴う不透明度~値の直列化-法を明確化した。（ `10426$issue ） ◎ Clarified serializing opacity values with calc() (Issue 10426)

互換性を得るため、旧来の~sRGB色どうしは， ~sRGB~空間~内で補間されるものとした。（ `7949$issue ） ◎ Interpolation between legacy sRGB colors is (once again) in sRGB space, for compatibility (Issue 7949)

~CIE~Labの［ a, b ］成分~用の［現実世界における範囲］を明確化した。（ `12208$issue ） ◎ Clarified real-world CIE Lab range for a and b (Issue 12208)

不透明度~値は`接触判定$には影響しないことを明確化した。（ `11339$issue ） ◎ Clarified that Opacity value does not affect hit testing (Issue 11339)

`2024年 2月 13日勧告候補~草案＠~TR/2024/CRD-css-color-4-20240213/$ からの変更点 ◎ Changes since the Candidate Recommendation Draft of 13 Feb 2024

【 `currentcolor$v ~keywordの】使用~値は、 `color$p ~propの内側では，解決-済みな`継承d値$になることを明確化した（継承d値~そのままではなく）。 ◎ Clarified that inside the color property, it is the resolved inherited value (not the raw inherited value) that is used

色の分類yとして［ `~sRGB$へ解決されるもの, `旧来の色~構文$を~supportするもの］を挙げた。 ◎ Listed categories of colors, such as those that resolve to sRGB or support legacy color syntax

色相を正規化する例を追加した。 ◎ Added hue normalization examples

`相似的な成分$の表tに~alphaが欠落ったのを正した【！, but described as ...】。 ◎ Corrected table of analogous components, alpha was missing, but described as analogous in prose

`opacity$p 値の直列化を同じ節~内に収集して明確化した。 ◎ Collected together and clarified serialization of opacity values into one section

`color-interpolation-method^t と~host構文に関する言い回しを明確化した。 ◎ Clarified wording around color-interpolation-method and host syntax

返される色相が`欠落~成分$になるための`微小数$を定義した。 ◎ Defined epsilon for returning missing hue

無彩-色（中心-軸に “十分近い” 色）の色相が`欠落~成分$になるための定義をもっと精確にした。 ◎ Used a more precise definition of achromatic colors with missing hues (sufficiently close to the central axis)

“色~channel” ではなく “色~成分” を一貫して利用するようにした（どちらも利用されていたが）。 ◎ Consistently use "color component" rather than "color channel" (both were being used).

定義されず説明されずに利用していた相関d色~温度に規範的でない参照を追加した。 ◎ Correlated Color Temperature was used without being defined or explained. Added informative reference.

用語 `乗算済み$を~exportして，それへ一貫して~linkするようにした。 ◎ Exported term premultiplied, linked to it consistently

非推奨dな~system色とそうでない~system色の等価性は、もはや~risk下でなくなった。 ◎ Equivalence of deprecated and un-deprecated system colors is no longer at-risk

“~CSS `color$t を構文解析する” ~algoに意図される利用を明確化した。 ◎ Clarified intended use of the "parse a CSS <color>" algorithm

~HTMLに互換な直列化~用に正された例を追加した。 ◎ Added corrected examples for HTML-compatible serialization

~HTMLに互換な直列化~用の欠落~値に対する検査を除去した — すでに 0 へ変換-済みになるので。 ◎ Removed check on missing values for HTML-compatible serialization, they will already have been converted to zero

欠落~値が 0 になることについての注記を移動した — それが［ ~HTMLに互換な直列化, ~CSS直列化］どちらにも適用されるよう。 ◎ Moved note about missing values becoming 0, so it applies to both HTML-compatible and CSS serializations

~sRGB用に~HTMLに互換な~hex色の直列化を追加した。 ◎ Added an HTML-Compatible hex serialization for sRGB

`xyz-d65$v, `xyz-d50$v 用の例をもう一つ追加した。 ◎ Added another xyz-d65 and xyz-d50 example

~XYZにおいて明るさに対応する成分は Y であることを明確化した。 ◎ Clarify which component (Y) in XYZ corresponds to brightness

`~CSS色域~対応付け$は、利用されなsい`実際の値$に対し適用されることを明確化した。 ◎ Clarified that CSS gamut mapping applies on actual, not used, values

見本~codeの `hslToRgb^c から色相の正規化を除去した — その入力は、構文解析-時点で正規化-済みなので。 ◎ Removed hue normalization from the hslToRgb sample code, as the input is already normalized at parse time

色域~対応付け~algoの疑似-~code内の段 4 【？】を正した。 ◎ Corrected the pseudo-code for step 4 of the gamut mapping algorithm

2 つの色を組合せる最も共通的な状況は，補間であるが、それだけに限られないことを明確化した。 ◎ Clarified that interpolation is the most common situation which combines two colors, but not the only one.

~DeltaE表tにおける~text用に必要十分な~contrastを確保した。 ◎ Ensured adequate contrast for text in the deltaE table

残っていた `absolute-color-function^t の利用を除去して、代わりに `absolute-color^t 関数【 `color-function$t ？】を一貫して利用するようにした。 ◎ Removed remaining use of the term <absolute-color-function>, use <absolute-color> function instead for consistency

§ 謝辞を更新した。 ◎ Updated acknowledgements section

色域を三次元的な網目で示す図式を追加した。 ◎ Added gamut mesh diagram

~CSSOM直列化を`指定d値$ではなく`宣言d値$で述べるようにした。 ◎ Described CSSOM serialization in terms of declared values rather than specified values

~exportされる輝度の定義を追加した。 ◎ Added exported definition of luminance

`opacity-value$t 用の生成規則~規則を追加した。 ◎ Added production rule for <opacity-value>

見本~codeの `hslToRgb^c の結果がいつ 0 以上 1 以下になるかを明確化した。 ◎ Clarified when results from hslToRgb will be in [0,1]

~RGB空間は、線形~化されたなら加法的になることを明確化した。 ◎ Clarified that once linearized, RGB spaces are additive

`2022年 11月 1日勧告候補~草案＠~TR/2022/CRD-css-color-4-20221101/$ からの変更点 ◎ Changes since the Candidate Recommendation Draft of 1 November 2022

8 ~bitな~alphaを直列化する手続きを追加した（ `CSSOM-1$r から移動した）。 ◎ Added steps for serializing a uint8_t alpha, moved from cssom-1

現在の相互運用可能な挙動である［構文解析-時点における~HSLの負な彩度に対する 0 への切詰ng ］を~level 3 から復旧した。 ◎ Restored parse-time clamping of HSL negative saturation to 0, which is current interop behavior from CSS Color 3

補間するときは、無力な成分が欠落~成分になるよう，常に色~空間を変換するようにした。 ◎ When interpolating, always convert color space, so that powerless components become missing

~alpha 1 はいつ直列化から省略されるのかを明確化した。 ◎ Clarified when alpha 1 is omitted from serialization

色相~角度を 0 以上 360 以下にする拘束-法は、すでに他所にあり，冗長なので除去した。 ◎ Removed redundant constraining of hue angles to [0,360] as this is already done.

`ActiveCaption$vD の記述を正した — それは、背景~用であった。 ◎ Corrected description of ActiveCaption, which is a background.

`opacity^p ~propによる不透明度を~alphaとは別にするよう一義化した。 `opacity$p は、今や `opacity-value$t を利用する（その切詰ngの挙動は `alpha-value$t とは異なる）。 ◎ Disambiguated opacity and alpha. Opacity property now uses opacity-value (which has different clamping behavior to alpha-value)

`先へ運ばれ$るのは、 `乗算済み$化より前に起こることを明確化した。 ◎ Clarified that carrying forward happens before premultiplication

色域~対応付け~algoを更新した。 ◎ Updated gamut mapping algorithm

色相~補間に関する少数の課題を修正した。 ◎ Fixed a few issues regarding hue interpolation

~HWBの［白度／黒度］ 100% は、無彩-色~用の判定基準には足らず，それらの総和が問われることを明確化した。 ◎ Clarified that HWB white or black at 100% is insufficient criterion for an achromatic color; it is the sum which matters.

~sRGBから~HSLへの変換が負な彩度を返すのを避けるようにした — 色相を “反対側” を指すよう調整することにより。 ◎ Avoid returning negative saturation in rgb to hsl conversion; adjust the hue to point to "the other side" instead

~ProPhoto用に利用する有理-形でない行列の正確度を 64 ~bitにした。 ◎ Use 64 bit accurate matrices for ProPhoto, which does not have a rational form

`oklab$v 用の行列を 64bit 精度~用に計算し直すようにした（以前と同じく 32 ~bit精度による結果を返す）。 ◎ Oklab matrices recalculated for 64bit precision (returns same results as before, at 32 bit precision)

色域~対応付け~algoは、一貫して行先~色~空間~内の出力を返すようにした — 行先~色域には~~限界は無いことにより，色域~対応付けが遂行されない場合でも。 ◎ Consistently return output of GMA in the destination color space, even if no mapping is performed because the destination is unbounded

~Oklab用の 1 `~JND$がなぜ 2 ではなく 0.02 になるかについて，説明を追加した。 ◎ Added explanation for why one JND for Oklab is 0.02, not 2

~sRGB値の解決-法は `color$f 関数には適用されないことを明確化した。 ◎ Clarified that resolving sRGB values does not apply to the color() function

~alpha値の定義を `opacity$p ~propへ移動した。 `opacity$p の指定d値は切詰められないことを明確化した。 ◎ Moved alpha value definition up to the opacity property, clarified that opacity specified values are not clamped.

~privacyを保全するため、 ~system色に対しては明示的に偽装を許可するようにした。 ◎ System Colors now explicitly permit spoofing, to preserve privacy

~D50から~D65へ逆変換する有彩色~順応~行列を正した。 ◎ Corrected the inverse chromatic adaptation matrix for D50 to D65

~Bradford`有彩色~順応$~algoを［線形なそれ, より複雑な元のそれ］を一貫して判別するようにした。 ◎ Consistently distinguish linear Bradfrod from the original, more complicated, Bradford chromatic adaptation algorithm

色域~対応付け~algoは、最後に~clipして，不必要な段を避けるようにした。 ◎ In the gamut mapping algorithm, return clipped as the gamut mapped result, avoiding un-necessary steps

有彩色~順応~行列をより高い精度に更新した。 ◎ Updated chromatic adaptation matrices to higher precision

`~CSS色~値を構文解析する$ ~algoを追加した — 色を利用している非~CSS仕様が同じ機構を発明し直さずに済むよう。 ◎ Added Add 'parse a css color' algorithm, so non-CSS specs using colors don’t have to reinvent the machinery here.

幾何的な色域~対応付けは、色度が元の色を超える所へは射影しないモノトスルとすることを明確化した。 ◎ Clarified that geometric gamut mapping must not project chroma back beyond the original color

色域~対応付けの論において，用語 “解析的” に代えて “幾何的” を利用するようにした。 ◎ Use the term "geometric" rather than "analytical" in gamut mapping discussion

~HSL用の注釈文を文法に倣うようにした（百分率, 実数どちらも許容される） ◎ Aligned prose for HSL into line with the grammar (percent and number both allowed)

~LCH~alphaの補間~例を修正した — それは、色相~角度を誤って非乗算済み化していた。 ◎ Fixed an LCH alpha interpolation example, which was erroneously un-premultiplying the hue angle

［ `srgb$v, `display-p3$v ］用の伝達t関数を正した — これは、ある成分の値が正確に ( 10.31475 ~DIV 255 ) をとる場合（成分が 10 ~bit以下の場合はアリでない）に限り，結果に影響する。 ◎ Corrected the sRGB and display-p3 transfer function. (This only affected the result if a component had the exact value 10.31475 / 255, which is not possible at 8 or 10 bits per component)

~system色の指定d値は，依然として自身になることを明確化した。 ◎ Clarified that the specified values of system colors are still themselves

画像を~tag付けるための ~PNG `cICP chunk^en についての言及を追加した。 ◎ Added mention of PNG cICP chunk for tagging images

［ `increasing$v ／ `decreasing$v ］において，色相が［ 360 ／ 0 ］を過ぎたときの挙動を述べた。 ◎ Described behaviour of hue increasing and decreasing when 0/360 is passed

~HSLにおける無力~性の記述を他の極-座標~色~modelと揃えた。 ◎ Aligned description of powerlessnes in HSL with the other polar color models

色~補間~用の演算の順序を明示的に定義した。 ◎ Explicitly defined order of operations for color interpolation

`calc^f における`退化な数量-定数＠~CSSVAL#calc-error-constants$についての言及を追加した。 ◎ Added mention of degenerate numeric constants in calc()

~sRGB内の `calc^f は早期な解決があり，結果を切詰めることを明確化した。 ◎ Clarified that calc() in sRGB has early resolution, and clamps the result

~HWB色相には~HSL色相と同じ不利点があることを明確化した。 ◎ Clarified that HWB hue has the same disadvantages as HSL hue

輝度と明度の比較と図を追加した。 ◎ Added luminance to lightness comparison and figure

各色相~補間~keyword用に記述と例を追加した。 ◎ Added descriptions and examples for hue interpolation keywords

無彩度な~HWB色~用の規範的な注釈文を利用した。 ◎ Use normative prose for achromatic HWB colors

色相~補間~角度の範囲を［ 0 以上 360 以下］から［ 0 以上 360 未満］に正した。 ◎ Corrected hue interpolation angle range; [0,360) not [0,360]

L が［ 0% ／ 100% ］のときに［ ~black／~white ］として表示されるのは、色域~対応付けに因ることを表出した。無力~性についての不正な表明を除去した。 ◎ Expressed that displaying as black or white when L=0% or 100% is due to gamut mapping. Removed incorrect assertions of powerlessness

紛らわしい~comment — “~blackを表現している”, “~whiteを表現している” — を落とした。 ◎ Dropped the confusing "representing black" and "representing white" comments

`opponent^en a, b は相似的であることを明確化した ◎ Clarified that opponent a and b are analogous

一貫性を得るため、 ~RGB成分を［注釈文ではなく，基準~範囲］を利用して指定した。 ◎ Specified RGB components using reference ranges rather than prose, for consistency

［ ~Lab ／ ~LCH ／ ~Oklab ／ ~OkLCh ］色を直列化するときの百分率から実数への変換には、百分率t基準~範囲を明示的に参照するようにした。 ◎ Explicitly referenced percent reference ranges for percentage to number conversion when serializing Lab, LCH, Oklab, OkLCh

補間には~Oklabを要求した — それまでの “`may^en” を除去して。それを明示的に任意で外せることも述べた。 ◎ Required Oklab interpolation, remove previous "may", describe explicit opt-out

［ ~Lab ／ ~LCH ／ ~Oklab ／ ~OkLCh ］の~~説明用の節を規範的でないものとして~labelした。一部の定義を規範的でない節の外へ移動した。 ◎ Labelled the Lab, LCH, Oklab and OkLCh tutorial sections as non-normative. Moved some definitions out of the non-normative section.

補間するときには、相似的な成分に関する検査は，色~空間の変換より前に起こることを明確化した。 ◎ Clarified that, when interpolating, checking for analogous components happens before color space conversion

`hwb^f 構文の［変更点, 基準~範囲］を`~level 5$ から~portし戻した。 ◎ Back-ported hwb() syntax changes and reference ranges from CSS Color 5

`欠落~成分$を先へ運ぶ演算は、 `無力$な成分に対する演算より前に起こるものと定義した。 ◎ Defined carry-forward operations must happen before powerless operations

旧来の構文~用には、各~色~成分は［すべて百分率／すべて実数］どちらかにしなければナラナイことを明確化した。 ◎ 重複）Clarified it is color components which must be all-number or all-percentage, in legacy rgb() syntax ◎ Clarified for legacy syntax that color components must be all-percentage or all-number

範囲~外の~alphaが［ `calc^f で, `calc^f なしで］指定されたときの例を追加した。 ◎ Added examples of specified out of range alpha, with and without calc()

直列化する際に尾部を成す 0 たちが削られることを示す例を関連な~textに近くなる【！colorer】よう配置した。 ◎ Placed examples of serializing with trimmed trailing zeroes colorer to the relevant text

`text-shadow$p の使用~値に関する例を明確化した。 ◎ clarified example, used value of text-shadow

`currentcolor$v の解決-法を明確化した。 ◎ Clarified resolving currentColor

§ 謝辞を更新した。 ◎ Updated acknowledgments

無彩-色の［ a, b, 色度］が欠落であると主張するのをやめた。 ◎ Stop claiming that achromatic colors have missing a,b, or chroma

往復し易くするため、［ ~HSL／~HWB ］色域の~~上限を無くすよう変更した。 ◎ HSL and HWB changed to unbounded gamut, to promote round-tripping

~HSL用の百分率の基準~範囲を定義した。 ◎ Defined percentage reference range for HSL

［ `hsl$f ／ `hsla$f ］用の`現代の色~構文$は、［ `number$t, `percentage$t ］成分の混在を許容するようにした。 ◎ Modern color syntax hsl() and hsla() allow mixed number and percentage components

［ `rgb$f ／ `rgba$f ］用の`現代の色~構文$は、［ `number$t, `percentage$t ］成分の混在を許容するようにした。 ◎ Modern color syntax rgb() and rgba() allow mixed number and percentage components

用語 `現代の色~構文$を定義した（すでに定義した`旧来の色~構文$に加えて）。 ◎ Define the term "modern color syntax" (legacy color syntax already defined).

用語 `相似的な成分$を一貫して利用するようにした。 ◎ Consistently use the term "analogous components"

補間~用には，すべての`定義済み色~空間$が許容されるよう変更した。 ◎ Changed to allow all predefined color spaces for interpolation

`color$f 用には， 3 個の~parameter（ ~RGB ／ ~XYZ ）が要求されることを明確化した。 ◎ Clarified that for color(), three parameters (RGB or XYZ) are required

［ `有名~色$, `~system色$, `transparent$v ］の直列化を明確化した。 ◎ Clarified serialization of named colors, system colors, and transparent

［ ~Lab, ~LCH, ~Oklab, ~OkLCh ］用の指定d値を定義した。 ◎ Define specified value for Lab, LCH, Oklab, OkLCh

~sRGB色（`有名~色$, `~system色$も含む）用の指定d値を定義した。 ◎ Define specified value for other sRGB colors ◎ Define specified values for named and system colors

［ ~alpha, 明度, 色度, 色相］を値に構文解析した時点で切詰めるようにした。 ◎ Clamp alpha, Lightness, Chroma and Hue at parsed-value time

~CIE明度に光沢~white【 L が 100 を超える~Lab色】が渡されたときの言及を除去した。 ◎ Remove passing mention of specular white and CIE Lightness

色相を指定されたとおりに維持することは、もはや要求されない — それは、 0 以上 360 以下に切詰められる。 ◎ No longer require as-specified Hue to be retained; clamp to [0, 360]

各~例における［明度／実数］の直列化が一貫するようにした。 ◎ Consistent serialization of Lightness and number in examples

小さな誤記／編集上の明確化 ◎ Minor typos and editorial clarifications

`2022年 7月 5日勧告候補＠~TR/2022/CR-css-color-4-20220705/$ からの変更点 ◎ Changes since the Candidate Recommendation of 5 July 2022

色相~補間~用の値 `specified^v を除去した。 ◎ Removed hue interpolation "specified" value

色相~角度の補間を差 `360deg^v を保守するようもっと精確に定義した。 ◎ Defined hue interpolation angle more precisely, maintaining differences of 360deg

`乗算済み$化~用に`先へ運ばれ$る~alpha【？】の例を追加した。 ◎ Added example of carried forward alpha for premultiplication

［ a, b ］成分および［ C, h ］成分は、 ~whiteを表現している明度 100% 【！L=100%】においても`無力$になることを明確化した。 ◎ Clarified a,b and C,h powerless at L=100% representing white.

［ ~CIE~Labではなく， `hdr-CIELAB^en【~HDR（ `High Dynamic Range^en ）用の~CIE~Lab】］に適用される［明度 400% 【！L=400】についての~~曖昧な言及］を除去した。 ◎ Removed handwavy mention of L=400 which applies to hdr-CIELAB not CIE Lab

［ ~Oklab／~OkLCh ］の~~文字大小が一貫するようにした。 ◎ Consistent capitalization of Oklab and OkLCh

［妥当な色, 無効な色, 色域~外, 色域~内］の定義を `§ 色の各種用語＠#terminology$へ移動した。 ◎ Moved definitions of valid color, invalid color, out of gamut and in gamut to terminology section

色相~補間における `longer$v の定義を修正した。 ◎ Fixed definition of "longer" hue interpolation

`~host構文$の概念を更に明確化した。 ◎ Further clarified the concept of a host syntax

色見本~用の~accessibilityを改善した。 ◎ Accessibility improvements for color swatches

旧来の形は `none$v を~supportしないことを明示的にした。 ◎ Made explicit that legacy forms do not support "none"

色相の生成規則【 `hue$t 】から `none$v を除去した — それは、旧来の構文においては許容されないので。 ◎ Remove "none" from the hue production, as it is not allowed in legacy syntax

`~level 5$ へ移動された［ ~CMYK, ~CMYKOGV ］への~~余計な参照を除去した。 ◎ Removed some dangling references to CMYK and CMYKOGV, moved to CSS Color5

色の`欠落~成分$が［補間される際に，どう`先へ運ばれ$るか］について明確化した。 ◎ Clarified how missing values in colors to be interpolated are carried forward

`xyz-params$t の構文を — 注釈文に揃えるため —［実数, 百分率］どちらもとれるよう更新した。 ◎ Updated syntax of xyz-params so they take numbers and percentage, to align with prose

すべての［例, 図］に［ ~ID, 自己-~link ］を付与した。 ◎ Ensure all examples and figures have IDs, self-links

実装者が色域~対応付けの序論を読むことの重要度を明確化した。 ◎ Clarified importance to implementors of reading the gamut mapping introduction

`~level 5$ へ移動された~custom色~空間についての言及を除去した。 ◎ Removed left-over mention of custom color spaces (feature was moved to CSS Color 5)

`color$t, `alpha-value$t の構文を~~再編成した。 ◎ Refactor syntax of <color> and <alpha-value>

編集上の~~再編成（順序）。 ◎ Editorial refactoring for better reading order.

色域~対応付け~algo用の疑似-~codeを更新して，不要な~DeltaEの~callを除去した。 ◎ Updated pseudocode for gamut mapping algorithm, remove un-needed deltaE calls

`2022年 6月 28日作業草案＠~TR/2022/WD-css-color-4-20220628/$ からの変更点 ◎ Changes since the Working Draft of 28 June 2022

位置付けを勧告候補に更新した。 ◎ Updated status for Candidate Recommendation

`2022年 4月 28日作業草案＠~TR/2022/WD-css-color-4-20220428/$ からの変更点 ◎ Changes since the Working Draft of 28 April 2022

§ `opacity$p ~propを［詳細に立ち入る前の最初の方, § `color$p ~propの次］へ移動した。 ◎ Moved opacity property up to the top of the module, next to color property, before getting into details.

`color$p ~propの記述を改善した — 特に，他の~propに対する効果について。 ◎ Improved description of the color property, in particular effect on other properties

`longer$v における色相~調整-用の等式を `360deg^v を法とする剰余が等しい場合について正した。 ◎ Corrected longer hue adjust equation, for equal-modulo-360 colors

新たな`~system色$として `AccentColor$vS, `AccentColorText$vS を追加した。 ◎ Added two new System colors: AccentColor and AccentColorText

色~空間の総合的な変換~手続きを新たな節に述べた。 ◎ Described overall color space conversion steps in new section

【`~alphaを伴う色の補間-法＠#interpolation-alpha$における】［ `乗算済み$, 非乗算済み］に［ ~alphaが `none$v をとる場合］を織り込んだ。 ◎ Accounted for none alpha in premultiplication and un-premultiplication

`2021年 12月 15日作業草案＠~TR/2021/WD-css-color-4-20211215/$ からの変更点 ◎ Changes since the Working Draft of 15 December 2021

~system色【の算出d値】は、【~keyword自身ではなく，】全部的に解決するようにしつつ，それらを強制d色~modeにおいて改めることは禁止した。 ◎ Made system colors fully resolve, but forbid their alteration in forced colors mode

`color$f 関数における不正な~parameterの個数に対する~~寛容さを除去した ◎ Removed forgiveness for incorrect number of parameters in color() function

［ ~CIE／~OK ］明度の直列化を百分率から実数に変更した。 ◎ Changed serialization of CIE Lightness and OK Lightness to number rather than percentage.

非推奨にされた`~system色$【とそうでない~system色】の等価性を~risk下とした。【が、今や，そうでなくなった。】 ◎ Marked deprecated system color equivalences as at-risk

次に挙げる成分~用の百分率~値に対する基準~範囲を追加した ⇒＃ ~CIE~Labの［ L, a, b ］ ~Oklabの［ L, a, b ］ ~CIE~LCHの［ L, C ］ ~OkLChの［ L, C ］ ◎ Added reference ranges to percentage values for CIE and OK L,a,b,C

［ `乗算済み$化, その逆］を遂行するための見本~codeが — ［ `矩形な直交-座標$, `円柱な極-座標$ ］どちらの色~空間にも — 在ることを注記した。 ◎ Noted that there is sample code for performing and undoing premultiplication, for both rectangular and polar color spaces.

色域~対応付けの注釈文に［範囲~外の切詰ng, および疑似-~code ］を追加した。 ◎ Added out of range clamping to the gamut mapping prose, as well as the pseudocode

［ ~ProPhoto~RGB／~ROMM【 ~ROMMは~ProPhoto~RGBの別名】］用の規範的な参照を追加した。 ◎ Added normative reference for ProPhoto RGB / ROMM

［ ~sRGB, ~Display-P3 ］の `reference surround^en【？】用の黒色点~値を正した。 ◎ Corrected sRGB and Display P3 black point value for reference surround

~Display-P3用の規範的な参照を追加した。 ◎ Added normative reference for Display P3

`色域~抑制＠#binsearch$における［ ~whiteより明な【！whiter】／~blackより暗な］色による無限~loopを避けるようにした。 ◎ Avoided an infinite loop in gamut reduction, with colors whiter than white or darker than black

`none$v 値の直列化を明確化した。 ◎ Clarified serialization of the none value

旧来でない色~用には，~Oklab内の補間を選べることを明確化した。 ◎ Clarified the opt-in to interpolation in Oklab, for non-legacy colors

`乗算済み$化が `none$v 値に対しどう働くかを定義した。 ◎ Defined how premultiplication works, with the none value

`rgb^f 内の欠落~値は、 0 として直列化されることを明確化した。 ◎ Clarified that missing values in rgb serialize as 0

`calc^f における `none$v 値の利用について明確化した。 ◎ Clarified the use of calc() with the none value

誤記, および `~system色$の文字大小が一貫でないのを正した。 ◎ Typo, inconsistent casing on System Colors

［ `SelectedItem$vS, `SelectedItemText$vS ］の併用例を追加した。 ◎ Added example of SelectedItem with SelectedItemText

旧来の色の有無【各種色~関数における旧来の色~構文の~support有無】について，明示的に注記した。 ◎ Explicitly noted the presence or absence of legacy colors

~CIE~XYZ用の規範的な参照を追加した。 ◎ Added normative reference for CIE XYZ

［ ~HWB, ~HSL ］用の規範的な参照を追加した。 ◎ Added normative reference for HWB and HSL

`hwb$f は、旧来の構文ではないので， ~commaで分離された旧い構文-形は~supportしないことを明確化した。 ◎ Clarified that hwb() is not a legacy syntax so does not support the older, comma-separated syntactic form

`色域~対応付け$が施されるのは，旧来の色に限られ、他の色には【その成分に】~~限界は無いことを明確化した。 ◎ Clarified that only legacy colors will gamut map, the others are unbounded

分光光度計と分光放射計に別個な用語を利用するようにした。 ◎ Use distinct terms, spectrophotometer and spectroradiometer

諸々の小さな誤記を修正した。文法~上の改善。 ◎ Assorted minor typos fixed, and grammatical improvements

`2021年 6月 1日作業草案＠~TR/2021/WD-css-color-4-20210601/$ からの変更点 ◎ Changes since the Working Draft of 1 June 2021

§ 色域~対応付けを追加した。 ~CSS色域~対応付け~algoを［ ~OkLChにおける，`局所的な最小~DeltaE＠#GM-chroma-local-MINDE$を伴う色度~抑制］として定義した。 ◎ Added gamut mapping section and defined a CSS gamut mapping algorithm as chroma reduction in OkLCh with local MINDE.

`color(xyz ...)^v の算出d値は `color(xyz-d65 ...)^v になるとした。 ◎ Computed value of color(xyz ...) is color(xyz-d65 ...)

補間~色~空間に `srgb-linear$v を追加した。 ◎ Added srgb-linear to interpolation color spaces

`~level 3 からの変更点＠#changes-from-3$を更新した。 ◎ Updated Changes from Colors 3 section

`§ ~Oklab, ~OkLCh値の解決-法＠resolving-oklab-oklch-values$ を追加した。 ◎ Added Resolving Oklab and OkLCh values section

`srgb-linear$v 色~空間を追加した。 ◎ Added srgb-linear color space

~CSS~WGによる解決に則り， `color-profile^at, `device-cmyk^f を`~level 5$ へ移動した。【以下に挙げられる変更点のうち，これらに関係するものも、`~level 5$ の内容を対象にするようになった。】 ◎ Moved @color-profile and device-cmyk to level 5 per CSSWG resolution

補間~色~空間を定義した。 ◎ Defined interpolation color space

行列は、 `column-major order^en 【！誤：row-major】であることを明確化した。行列~乗算~libraryへ~linkした。 ◎ Clarified that matrices are row-major and linked to the matrix multiplication library

§ ~security／~privacy を別々な節に分割した ◎ Split old Security & Privacy section into separate sections

過去互換~modeにおける過去互換~用の~hex色を定義した。 ◎ Defined quirks-mode quirky hex colors

`device-cmyk^f から~fallback色を除去した。 ◎ Removed fallback colors from device-cmyk

既定を宣言しない~host構文は、【~Labに代えて】既定で~Oklabを利用するようにした。 ◎ Host syntax that does not declare a default now uses Oklab by default

~DeltaE~OK用の見本~codeを追加した。 ◎ Added sample code for deltaE OK

［ ~Oklab, ~OkLCh ］用の見本~変換~codeを追加した。 ◎ Added sample conversion code for OKlab and OkLCh

［ `oklab$f, `oklch$f ］関数を追加した。［ ~Oklab, ~OkLCh ］の記述を追加した。 ◎ Added oklab() and oklch() functions Added description of Oklab and OkLCh

~CIE~LCHの欠陥についての記述を追加した。 ◎ Added description of CIE LCH deficiencies

色の各~成分は、 `none$v ~keywordを介して “欠落~成分” になることを許容した。成分が［いつ “無力” になるか／一部の事例においていつ自動的に欠落~成分になるか］を定義した。 “~NaN” 成分を参照していたすべての箇所は、 “欠落~成分” の概念を利用するよう修正した。 ◎ Allowed all components of a color to be "missing" via the none keyword, defined when components are "powerless" and automatically become missing in some cases, and fixed all references to "NaN" components to use the "missing" concept.

白色点の x, y 値を明示的に定義して、一貫して利用するようにした。 ◎ Defined explicit x,y whitepoint values, use consistently throughout

用語として`~host構文$を定義した。 ◎ Defined the term host syntax

`override-color color^en【？】を解決するための文脈を定義した。 ◎ Defined context for resolving override-color colors

`~system色の~pair法$に新たな~pairを追加した。 ◎ Added a new pair of system colors

［ ~HSL, ~HWB ］用の見本~codeを正した。 ◎ Corrected HSL and HWB sample code

~HSL値の表tを~errorが無い~versionに置換した。 ◎ Replaced table of HSL values with error-free version

~WG解決により，共同-編集者に `Lea Verou^en 氏を追加した。 ◎ Added Lea Verou as co-editor by WG resolution

色相~角度には~~限界は無いことを明確化した。 ◎ Clarified that hue angle is unbounded

`MarkText$vS の例を正した。 ◎ MarkText example corrected

図式を追加した。例を正した。 ◎ Added diagrams, corrected examples

いくつかの編集上の明確化。 ◎ Some editorial clarifications

小さな誤記を正した。 ~markupを正した。 ◎ Minor typos corrected, markup corrections

`2020年 11月 12日作業草案＠~TR/2020/WD-css-color-4-20201112/$からの変更点 ◎ Changes since the Working Draft of 12 November 2020

中立に近い~Lab値を~LCHへ変換するとき，色相が不定になる課題【！ssue】について注記した。 ◎ Noted indeterminate hue ssue on near-neutral Lab values converted to LCH

~RGBと~Labとの相互変換において，どの段たちが線形な結合nになるか明確化した。 ◎ Clarified which steps are linear combinations in RGB Lab interconversion

`color-profile$at に `components^d 記述子を追加した — これは、 `~level 5$ から利用される。 ◎ Added components descriptor to @color-profile, for use in CSS Color 5

すべての定義済み~RGB色~空間は、拡張された範囲【色域？】に対し定義された。 ◎ All predefined RGB color spaces are defined over the extended range

色~補間に先立って色域を［対応付ける／~clipする］段は、無いことを明確化した。 ◎ Clarified that there is no gamut mapping or gamut clipping step prior to color interpolation

旧来の各種~sRGB構文の補間を明確化した。 ◎ Clarified interpolation of legacy sRGB syntaxes

`color$f から `lab^v ~optionを除去した。 ◎ Removed the lab option from color()

定義済み色~空間どうしで相互変換する段を~listした。 ◎ List steps to interconvert between predefined color spaces

用語 `color space^en （色~空間）を一貫して利用するようにした。 — `colorspace^en ではなく。 ◎ Consistent use of the term color space (two words)

混合-時の色~空間を選定するための指導をもっと供した。 ◎ Provided more guidance on selecting color space for mixing

一部の例を精度を高めるよう計算し直した。 ◎ Recalculated an example to increase precision

色相~補間の例を追加した。 ◎ Added hue interpolation example

`color$f 構文から~fallback~optionを除去して，単純~化した。 ◎ Simplified color() syntax by removing the fallback options

~ICC~profileの型【？】は、 `color-profile$at から~linkされ得ることを明確化した。 ◎ Clarified the types of ICC profile that may be linked from @color-profile

稀にしかない~ICC有名~色（ `ICC Named Colors^en ）用の~supportは除去した ◎ Support for the rare ICC Named Colors was removed

標準な白色点~純色度【 “~white純色度” 】の精度を改善した。 ◎ Improved precision of standard whitepoint chromaticities

一部の定義済み色~空間の記述から~trademarkを除去した。 ◎ Removed a trademark from description of one predefined color space

補間を`補間~色~空間$に関してより汎用になるよう言い換えた。 ◎ Rephrased interpolation to be more generic wrt to interpolation space

`§ ~accessibilityの考慮点＠#a11y-sec$ を正した。 ◎ Corrected Accessibility Considerations section

`color$f 用の色~空間~引数は、 ~sRGB用であっても，義務的であることを明確化した。 ◎ Clarified that the color space argument for color() is mandatory, even for sRGB

`currentcolor$v は~sRGBに制約されないことを明確化した。 ◎ Clarified that currentColor is not restricted to sRGB

［ ~sRGBから~XYZ, その逆］へ変換する行列を少し補正して，往復-結果を改善した。 ◎ Small correction to the sRGB to XYZ to sRGB matrices, improve round-tripping

`rec2020$v 用の伝達t関数を明確化して、 ~Rec2020参照への~~引用を正した。【不正な引用文を除去した。】 ◎ Clarified the rec2020 transfer function, citing the correct ITU Rec BT.2020-2 reference

正しい構文を利用するよう，~fallbackの例を正した。 ◎ Correct fallback examples to use the correct syntax

旧来の【構文による】色を除き，~gamma符号化された空間~内で補間するのを強制しないようにした。 ◎ Don’t force non-legacy colors to interpolate in a gamma-encoded space

~alpha乗算済み化による補間を定義した。 ◎ Define premultiplied alpha interpolation

`currentcolor$v ［への／からの］補間に取組むのを開始した。 ◎ Start to address interpolation to and from currentColor

色相における~NaNとの補間を定義した。 ◎ Define hue interpolation with NaN

色~補間を一般~化した。 ◎ Generalize color interpolation

補間は~Lab内で行うものと定義した — LCG【？】に対する上書きを伴うよう。 ◎ Define interpolation to be in Lab, with override to LCG

色相の補間を正した。 ◎ Corrections to hue interpolation

色相~角度の補間を定義した。 ◎ Defined hue angle interpolation

`§ 補間＠#interpolation$を追加した。 ◎ Added interpolation section

一部の例における構文を正した。 ◎ Corrected syntax in some examples

`color$f 内で百分率が許容される成分が正確にどれなのかを明確化した。 ◎ Clarify exactly which components are allowed percentages, in color()

`lch$f を直列化した結果は `lab$f でなく同じ関数になるよう変更した。 ◎ Change to serialize lch() as itself rather than as lab()

旧来の【構文による】色を除き，~sRGB `color$f 用の成分ごとの精度を 10 ~bit以上にした。 ◎ Minimum 10 bits per component precision for non-legacy sRGB in color()

`color$f の色~空間は、もはや省略可能でない。 ◎ color space no longer optional in color()

`lab$f と `color(lab)^v の最小な精度が一貫するようにした。 ◎ Consistent minimum precision between lab() and color(lab)

`color$f 関数~用の~fallback手続-を次のように明確化した ⇒＃妥当かつ`色域~内$にある色が在れば最初のそれ／他の場合は，妥当な色が在れば最初のそれ（色域の対応付けが施される）／他の場合は，透明な黒 ◎ Clarified fallback procedure for the color() function – first valid in-gamut color, else first valid color which is then gamut mapped, else transparent black

`opacity$p ~propと不透明度を伴う色との相違を明確化した — 特に，重合している~textを成す~glyphの描画~用に。 ◎ Clarified difference between opacity property and colors with opacity, notably for rendering overlapping text glyphs

~DeltaE 2000 用の見本~codeを追加した（見本だが，正しいことは検証y-済み）。 ◎ Added sample (but verified correct) code for ΔE2000

それまで未定義であった用語 `純色度$の定義を追加した — それに伴い，純色度~図式を定義する例も。 ◎ Added definition of previously-undefined term chromaticity, with examples; define chromaticity diagram.

色の加法性の説明を追加した — それに伴い，例も。 ◎ Added explanation of color additivity, with examples

WPT【 ~web~platform~test 】への~source~linkを追加した。 ◎ Added source links to WPT tests

他の仕様からの参照~用に［ `色$, `妥当な色$ ］の定義を~exportした。 ◎ Export definition of color, and valid color, for other specifications to reference

直列化~用に成分ごとの最小な~bit数を定義した。 ◎ Define minimum number of bits per component, for serialization

“適用対象” の定義を更新した（~CSS~~全般にわたる変更）。【 “行内~box” → “~text” 】 ◎ Updated "applies to" definitions (CSS-wide change)

定義済み色~空間~用の画像~状態（ `scene-referred^en, `display-referred^en ）を追加した。 ◎ Added image state (display referred or scene referred) for predefined color spaces

明確さを得るため、【~whiteの】純色度~座標の傍に，白色点の相関d色~温度（例： ~D65）も挙げた。 ◎ Listed white point correlated color temperature (e.g. D65) alongside chromaticity coordinates, for clarity

丸ngについて明確化した。 ◎ Clarified that rounding is towards +∞

誤記や~markupを正した。 ~linkの修正s。 ◎ Correction of typos, markup corrections, link fixes

`2019年 11月 5日作業草案＠~TR/2019/WD-css-color-4-20191105/$からの変更点 ◎ Changes since Working Draft of 5 November 2019

他の仕様から利用できるよう，一部の用語を~exportした。 ◎ Export some terms for use in other specifications

要件を~WCAG 2.0 から 2.1 に更新した。 ◎ Update requirement from WCAG 2.0 to 2.1

直列化に利用される~Unicode文字を全部的に指定した。 ◎ Fully specify Unicode characters used for serialization

特別な有名~色【 `transparent^v, `currentcolor^v 】の直列化を定義した。 ◎ Define serialization of special named colors

`device-cmyk$f の直列化を定義した。 ◎ Define serialization of device-cmyk()

`color$f の直列化を定義した。 ◎ Define serialization of color()

~RGBの直列化を最大限に~web互換になる仕方で全部的に定義した。 ◎ Fully define RGB serialization, in maximally web-compatible way

~Lab, ~LCHの直列化を定義した。 ◎ Define serialization of Lab and LCH

~alpha値の直列化を全部的にを定義した。 ◎ Fully define serialization of alpha values

`Consistency pass to avoid accidental RFC2119^en 【？】

すべての例に~IDを追加して，参照-可能にした。 ◎ Add IDs to all the examples, to enable referencing

`color^t 値の解決-法と直列化-法を 2 つの節に分離した。 ◎ Separate resolved color and serialized color sections

（~security） ~ICC~profileは、実行-可能な~codeを伴わない。 ◎ (Security) ICC profiles have no executable code

~profiled色~用に，範囲~外が何を意味するかを定義した。 ◎ Define what out-of-range means for profiled colors

範囲~外に対する切詰ngを明確化した。 ◎ Clarify out-of-range clamping

指定d値の例を追加した。 ◎ Add examples of specified values

算出d値を明確化した。 ◎ Clarify computed values

指紋収集に抗するため、非推奨にされた~system色~用の対応付けを義務的にした。 ◎ Resist fingerprinting, with mandatory mappings for deprecated system colors

~X11色の標準~化についての歴史と理由を説明する注記を追加した。 ◎ Added explanatory note on history and reason for standardizing X11 colors

~HWBの見本~codeを正した。 ◎ Correct hwb sample code

~MacBeth~patch用に~DeltaE 2000 値の表tを追加した。 ◎ Add table of DeltaE2000 values for MacBeth patches

~ICC~profile用の~MIME型に対する注記を追加した。 ◎ Add note on ICC profile Internet Media type

~PNGの `sRGB chunk^en への参照を追加した。 ◎ Add reference to PNG sRGB chunk

~CMYKと~Labの相互変換を明確化した。 ◎ Clarify CMYK to Lab interconversion

~RGBと~Labの相互変換を明確化した。 ◎ Clarify RGB to Lab interconversion

~HSLと~LCHの比較についてもっと。 ◎ More comparison of HSL vs. LCH

`Rec.2020$r 色~空間~用の記述をもっと。 ◎ More description for Rec BT.2020 color space

`prophoto-rgb$v の記述を更新した。 ◎ Updated description of prophoto-rgb

◎ Removed duplicate "keywords" from Value Definitions section （すべての CSS に対する変更）

無効な色の例を追加した。 ◎ Added an example of an invalid color

複数の~fallbackを伴う例を追加した。 ◎ Added example with multiple fallbacks

諸々の［誤記／~markup ］の修正s。 ◎ Assorted typos and markup fixes

宣言-済みでない~custom色~空間~用の取扱いを明確化した。 ◎ Clarify handling for undeclared custom color spaces

いくつかの例と説明-用の注記を明確化した。 ◎ Clarify some examples and explanatory notes

［妥当な／妥当でない］~ICC~profileに対する取扱い。 ◎ Handling for valid and invalid ICC profiles

明示的な有~tag色~空間を伴う画像に対する取扱いを定義した。 ◎ Define handling for images with explicit tagged color space

4k, ~SDR動画~用の色~空間を定義した。 ◎ Define color space for 4k, SDR video

利用者の~contrast設定群を優先するモノトスル【！mst】ことを言明した。 ◎ State that user contrast settings mst take precedence

~system色 `outside for^en 強制d色~mode 【強制d色~modeに影響されない~propに利用される~system色？】の意味を明確化した。 ◎ Clarify meaning of system colors outside for forced-color mode

既定の~style規則を更新した。 ◎ Update default style rules

`color$f に~CIE~XYZ色~空間を追加した。 ◎ Add CIE XYZ color space to color()

色相~角度を大幅に明確化して、 ~NaNを明示的に許容した。 ◎ Greater clarity on hue angles, NaN explicitly allowed

~system色の~pair法に関する節を改善して、 ~access可能な~contrastとして~AAを要求するようにした。 ◎ Improve section on system color pairings, require AA accessible contrast

重合している~glyphと `opacity^p ~propの相互作用についての~~注意書き。 ◎ Warn of interaction between overlapping glyphs and the opacity property

色~定義における文法を正した。 ◎ Correct grammar in color definition

`Highlight$vS ／ `HighlightText$vS の記述を改善した。 ◎ Improve description of Highlight/HighlightText

`prophoto-rgb$v 伝達t関数を正した ◎ Correct prophoto-rgb transfer function

`prophoto-rgb$v の原色の精度を高めた。 ◎ More precision for prophoto-rgb primaries

“`表示し得ない$” を定義した。 ◎ Started to define "can’t be displayed"

~canvas表面【の既定の背景~色】についての段落を除去した。 ◎ Removed paragraph about canvas surface

~system色として次を追加した ⇒ `ButtonBorder$vS, `Mark$vS, `MarkText$vS ◎ Added the buttonborder, mark, and marktext system colors

~sRGBから~HWBへの逆~変換を追加した。 ◎ Added reverse conversion, sRGB to HWB

極-座標~空間は、円柱状であり，球状ではないことを明確化した。 ◎ Clarified polar spaces are cylindrical, not spherical

§ ~accessibilityの考慮点を追加した。 ◎ Added an Accessibility Considerations section

色域の対応付けを — 成分ごとの~clip法ではなく — 色度の抑制を通して述べることを開始した。 ◎ Started to describe chroma-reduction gamut mapping rather than per-component clipping

`rec2020$v 用の~white純色度を正した。 ◎ Corrected white chromaticity for rec2020

`device-cmyk^v も `color-profile$at により可用になるようにした。 ~CMYK色から変換する~algoが`素朴な変換＠~CSSCOLOR5#cmyk-rgb$を利用するのは，最後の拠所に限るよう、更新した。 ◎ Made device-cmyk available by @color-profile; updated CMYK to color algorithm to only use naive conversion as a last resort

印刷-向けに［ ~CMYK, ~KCMYOGV ］の例を追加した。 ◎ Added print-oriented CMYK and KCMYOGV examples

利用者~定義な色~空間を `dashed-ident$t にした — 定義済み色~空間がそれに衝突することなく拡張-可能になるよう。 ◎ User-defined color spaces now dashed-ident, making predefined color spaces extensible without clashes

`color$f 関数に `lab^v ~optionを追加した【が再び除去された】。 ◎ Added lab option to the color() function

~CIE~Lab用の規範的な参照を追加した。 ◎ Added normative reference for CIE Lab

`prophoto-rgb$v は、 ~D50白色点を利用するので，順応は要求されないことを明確化した ◎ Clarified that prophoto-rgb uses D50 whitepoint so does not require adaptation

~LCHの角度が増大する方向を明確化した ◎ Clarified direction of increasing angle in LCH

色~名は~ASCII大小無視であることを明確化した。 ◎ Clarified that color names are ASCII case insensitive

`color$p ~propの初期~値を `CanvasText$vS にした。 ◎ Initial value of the "color" property is now CanvasText

~CSS~WGの解決により，【~keyword `gray^v と】混同しやすい `gray^f 関数を除去した。 ◎ Removed confusing gray() function per CSS WG resolution

各所に散らばっていた定義を，新たな`§ 色の各種用語＠#terminology$に収集した。 ◎ Collect scattered definitions into new Color terminology section

~~参考用に図と例をもっと追加した ◎ Add helpful figures and more examples

小さな編集上の明確化, 綴り検査, 誤記~修正, 【！bikeshed】~markup修正s。 ◎ Minor editorial clarifications, spell check, fixing typos, bikeshed markup fixes

`2016年 7月 5日作業草案＠~TR/2016/WD-css-color-4-20160705/$からの変更点 ◎ Changes since Working Draft of 05 July 2016

~CSSとの互換性を得るため、［ ~Lab／~LCH ］における明度（ L ）を百分率に変更した。 ◎ Changed Lightness in Lab and LCH to be a percentage, for CSS compatibility

色~値の切詰ngを明確化した。 ◎ Clamping of color values clarified

百分率による不透明度は、今や許容される。 ◎ Percentage opacity is now allowed

他の仕様から利用するため、用語［ `~sRGB$, 光に線形な~sRGB ］を定義した。【 “光に線形な~sRGB” は、用語でなくなった】 ◎ Define terms sRGB and linear-light sRGB, for use by other specs

~CSS~system色からなる新たな~listを追加した。 `Text^v を `CanvasText$vS に改称した。 ◎ Add new list of CSS system colors; renaming Text to CanvasText

~system色~keywordは、それ自身に算出されるようにした。 ◎ Make system color keywords compute to themselves

［算出d値／使用~値］への解決-法に，~system色のそれを追加した。 ◎ Add computed/used entry for system colors

非推奨dでない~system色についての序論を書き直した — それらの利用は、汎用ではなく，`強制d色~mode$を拠り所にするように。 ◎ Rewrite intro to non-deprecated system colors to center their use around forced-colors mode rather than generic use

`定義済み色~空間$に対する~hyphen化を一貫するようにした。 ◎ Consistent hyphenation of predefined color spaces

不透明でない要素を — `有位置$でなくとも — 有位置な要素と同じ層へ塗ることについての~textを復旧した。 ◎ Restore text about non-opaque elements painting at layers even when not positioned

`color$p ~propの初期~値は、今や `black$vN とされた。 ◎ Initial value of the "color" property is now black

~LCHにおける色相は `360deg^v を法とする剰余であることを明確化した（が、その変更は，今や復帰された）。 ◎ Clarify hue in LCH is modulo 360deg (change now reverted)

~LCH, ~Lab における［ L に許容される範囲, および L=100 の意味］を明確化した。 ◎ Clarify allowed range of L in LCH and Lab, and meaning of L=100

動画にて利用される色~空間~用の参照文献を更新した。 ◎ Update references for color spaces used in video

`定義済み色~空間$として `prophoto-rgb$v を追加した。 ◎ Add prophoto-rgb predefined color space

`display-p3$v 用の［ ~black, ~white ］輝度~levelを正した ◎ Correct black and white luminance levels for display-p3

`display-p3$v 伝達t関数を明確化した。 ◎ Clarify display-p3 transfer function

`a98-rgb$v 色~空間を追加して、原色の純色度の表tを正した。 ◎ Add a98-rgb color space, correct table of primary chromaticities

`currentcolor$v の算出d値は色に解決されないことを明確化した。 ◎ Clarify that currentColor’s computed value is not the resolved color

各例における構文を最新の仕様に適合するよう更新した。 ◎ Update syntax is examples to conform to latest specification

`color-mod^f 関数を除去した。 ◎ Remove the color-mod() function

~prop定義~表tから “媒体” を落とした。 ◎ Drop the "media" from propdef tables

他から参照できる用語として、［ `透明な黒$, `不透明な黒$ ］を定義し，一貫して利用するようにした。 ◎ Export, and consistently use, "transparent black" and "opaque black"

百分率などの算出d値を明確化した。 ◎ Clarify calculated values such as percents

色~成分~用に要求される精度と丸ngの挙動を明確化した。 ◎ Clarify required precision and rounding behavior for color components

`color$p ~propは、色~font~glyphには効果がないことを明確化した（特定的に — 例えば `currentcolor$v で — 参照されない限り）。 ◎ Clarify "color" property has no effect on color font glyphs (unless specifically referenced, e.g. with currentColor)

`color$t 値がどう解決されるかを明確化した。 ◎ Clarify how color values are resolved

［ ~HSL色, ~HWB色, 有名~色］は、 ~sRGB色に解決されることを明確化した。 ◎ Clarify that HSL, HWB and named colors resolve to sRGB

`device-cmyk$f から~sRGBへの変換を単純~化した。 ◎ Simplify conversion from device-cmyk to sRGB

~commaを利用していた以前の色~構文は、 “旧来のもの” と述べた。それに伴い，各例を~commaなしの形に変更した。 ◎ Describe previous, comma-using color syntaxes as "legacy"; change examples to commaless form

［表示される色は、（他の~optionもあるかの様に）機器~色域に制約される］とする過剰な要件は、除去した。 ◎ Remove superfluous requirement that displayed colors be restricted to device gamut (like there was any other option!)

`P3^v を `display-p3$v に改称し，それが `DCI-P3$r であると主張するのを避けた — これらは同じでないので。 ◎ Rename P3 to display-p3; avoid claiming this is DCI P3, as these are not the same

`color$f 関数への~parameterの記述を改善した。 ◎ Improved description of the parameters to the "color()" function

`color-profile$at の識別子として、 `定義済み色~空間$は許容しないようにした。 ◎ Disallow predefined spaces from "@color-profile" identifier

~prop定義~表tに正準的~順序を追加した。 ◎ Add canonical order to "color", "color-adjust" and "opacity" property definitions

~alpha組成-法の定義を， `SVG11$r から `Compositing$r に切替えた。 ◎ Switch definition of alpha compositing from SVG11 to CSS Compositing

見本~変換~codeは、規範的でないことを明確化した。 ◎ Clarify sample conversion code is non-normative

~securityと~privacyの考慮点を追加した。 ◎ Add Security and Privacy Considerations

いくつかの参照文献を，最新~versionに更新した。 ◎ Update several references to most current versions

~inlineに記された課題を GitHub 内の課題を指す~linkへ変換した。 ◎ Convert inline issues to links to GitHub issues

小さな編集上の明確化, 整形と~markupの改善。 ◎ Minor editorial clarifications, formatting and markup improvements

~level 3 からの変更点 ◎ Changes from Colors 3

~level 3 からの首な変更は、 ~CSS色は，もはや狭い~sRGB色域に制約されなくなったことである。 ◎ The primary change, compared to CSS Color 3, is that CSS colors are no longer restricted to the narrow gamut of sRGB.

これを~supportするため、いくつか新規な特能を追加した： ◎ To support this, several brand new features have been added:

定義済み広-色域~RGB色~空間。 ◎ predefined, wide color gamut RGB color spaces
機器に依存しない色~用の次に挙げる関数 ⇒ `lab$f, `lch$f, `oklab$f, `oklch$f ◎ lab(), lch(), oklab() and oklch() functions, for device-independent color

その他の技術的な変更点： ◎ Other technical changes:

`color$t の直列化は、今や `CSSOM-1$r ではなく，この仕様で指定される。 ◎ Serialization of <color> is now specified here, rather than in the CSS Object Model
~HWB記法で色を指定するための `hwb$f 関数。 ◎ hwb() function, for specifying sRGB colors in the HWB notation.
有名~色として `rebeccapurple$vN を追加した。 ◎ Addition of named color rebeccapurple.

加えて，構文上の変更点がいくつかある： ◎ In addition, there have been some syntactic changes:

［ `rgb$f ／ `rgba$f ］関数は、今や， `integer$t のみならず `number$t も受容する。 ◎ rgb() and rgba() functions now accept <number> rather than <integer>.
［ `hsl$f ／ `hsla$f ］関数は、今や，その色相~用に `number$t に加えて `angle$t も受容する。 ◎ hsl() and hsla() functions now accept <angle> as well as <number> for hues.
［ `rgb$f, `rgba$f ］は、今や，互いに他方の別名になった（どちらも，省略可能な~alphaをとれる）。［ `hsl$f, `hsla$f ］についても同様にされた。 ◎ rgb() and rgba(), and hsl() and hsla() are now aliases of each other (all of them have an optional alpha).
［ `rgb$f ／ `rgba$f ／ `hsl$f ／ `hsla$f ］に対し、新たな構文を与えた — ~spaceで分離された引数に加えて，省略可能な［ ~slashで分離された不透明度］からなるような。 `~CSSの関数-記法の設計原則＠https://wiki.csswg.org/ideas/functional-notation#general-principles$を保つため、今や，すべての色~関数はこの形による構文を利用する。 ◎ rgb(), rgba(), hsl(), and hsla() have all gained a new syntax consisting of space-separated arguments and an optional slash-separated opacity. All the color functions use this syntax form now, in keeping with CSS’s functional-notation design principles.
`alpha-value$t のすべての利用は、今や， `number$t のみならず `percentage$t も受容する。 ◎ All uses of <alpha-value> now accept <percentage> as well as <number>.
透明度を指定できる［ 4 桁／8 桁］による~hex色を追加した。 ◎ 4 and 8-digit hex colors have been added, to specify transparency.

`無力$な成分【`欠落~成分$？】を表現するため、 `none$v 値を追加した。 ◎ The none value has been added, to represent powerless components.

~securityの考慮点

~system色が実際に利用者の~system色に対応する場合、 ~malware~siteにとっては ~UIを~systemのそれに似せて作成するのも容易になるので，~security~riskがもたらされる。しかしながら、いくつかの~system色は，今や “汎用” になるよう定義されたので、この~riskは軽減されると予見される。 ◎ The system colors, if they actually correspond to the user’s system colors, pose a security risk, as they make it easier for a malware site to create user interfaces that appear to be from the system. However, as several system colors are now defined to be "generic", this risk is believed to be mitigated.

~privacyの考慮点

この仕様は、 “~system” 色を定義する。これは、理論的には利用者の~OS設定群の詳細を公開し得るので，指紋収集の~riskがある。 ◎ This specification defines "system" colors, which theoretically can expose details of the user’s OS settings, which is a fingerprinting risk.