CSS Color Module Level 4 （日本語訳）

◎要約

この仕様は、［前景~色／~group不透明度］用の各種~CSS［ `color$t 値, ~prop ］を述べる。 ◎ This specification describes CSS <color> values and properties for foreground color and group opacity.

~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.42210 0.47580 0.35605);

`加法的な色~空間@ とは、座標系が光~強度に線形であることを意味する。 ~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 ）†な値を生産する。 ◎ 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.

【† “光~強度（ `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).

ほとんどの色~空間は、少数の［日光を模倣している`白色点$ ］のうち一つを利用する — それらは、対応している黒体放射体の色~温度により命名される。例えば，`~D65$は、相関d色~温度 6500K† に対応している［日光の白色点］を表す。（† 実際には 6504K — ~Plank定数の値は、色が元々定義された頃から変更されたので。） ◎ Most color spaces use one of a few daylight-simulating white points, which are named by the color temperature 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).

累積的な往復-~errorを避けるため、計算に利用される純色度~値は，すべての箇所で一貫して一致することが重要になる。したがって，この仕様との最大な互換性を得るためとして、次に挙げる 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色$ ◎ computed color, see resolving color values ◎順文法に従う ◎ア算出d値の型による ◎表終

この~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 以下の範囲に対応付けられる ◎ map to the range [0,1] ◎算指定された実数を 0 以上 1 以下に切詰めた結果 ◎ specified number, clamped to the range [0,1] ◎順文法に従う ◎ア算出d値の型による ◎表終

`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).

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 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” とも呼ばれる。各~channelがとり得る値には、最小と最大があり，その合間にあるどの値もとれる。加えて、どの色にも， `~alpha成分@ が付随する — それは、不透明度 — 後景が色を通してどの程度透けて見えるか — を指示する。 ◎ Colors in CSS are represented as a list of color components, also sometimes called “channels”, representing axises in the color space. Each channel 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~channel, ~alpha~channelを~hex記法で表現する。 ◎ the sRGB hex color notation which represents the RGB and alpha channels 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.

`色~関数@ は、様々な`色~空間$内の色を — それらの~channel座標を~CSS`関数-記法$を利用して指定することにより — 表現する。これらは、次のいずれかの~modelを利用する： ◎ The color functions use CSS functional notation to represent colors in a variety of color spaces by specifying their channel 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 ］~channelにより直に（`~hex色$の様に）。 ◎ rgb() and its rgba() alias, which (like the hex color notation) specify sRGB colors directly by their red/green/blue/alpha channels.
`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$, `~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, 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値は，絶対的な色計量で解釈されるもの］をいう。これは、当の値が次に挙げるものでないことを意味する： ◎ 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)

これらの`色~関数$のうち［次に挙げるものは， `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-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).

注記：特定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 achromatic color will have a powerless hue component.

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

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

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

この仕様においては、一部の色（ `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 § 12.2 Interpolating with Missing Components. For handling of missing component in color interpolation,

他のすべての目的においては、 `欠落~成分$は，その成分に適切な単位を伴う 0 値 — `0^v ／ `0%^v ／ `0deg^v — として挙動する。これには、当の色を［直に描画するとき／別の色~空間へ変換するとき］や［当の色~成分~値の算出を遂行するとき† ］, 等々も含まれる。 ◎ 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.

【† 例えば、色~関数~内に入子にされた`~math関数$内に利用された`~channel~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.

`無力$な成分が手動で指定された場合、それは通常通り動作する — それが`無力$である事実には、効果は無い。しかしながら，色~空間の変換により自動的に生産される色においては、その`無力$な成分は — 変換~処理nにより生産される値が何であれ — `欠落~成分$に設定するモノトスル。 ◎ If a powerless component is manually specified, it acts as normal; the fact that it’s powerless has no effect. 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は、色のある成分が［当の成分に指定された，`無力$になるための精確な条件］に “十分近い” 場合には、当の成分を`無力$として扱っても`ヨイ^em。例えば、 ~gray色を `lch$f へ変換した結果の色度が［数量的な~errorに因り，精確に `0%^v にはならず，それに`極めて近くなる^em ］こともあろう — それでも，~UAは、自身の裁量により，そのような色相~成分を`無力$として扱える。この目的において “十分近い” が正確に何を意味するかは、意図的に指定されない。 ◎ User agents may treat a component as powerless if the color is "sufficiently close" to the precise conditions specified. For example, a gray color converted into lch() may, due to numerical errors, have an extremely small chroma rather than precisely 0%; this can, at the user agent’s discretion, still treat the hue component as powerless. It is intentionally unspecified exactly what "sufficiently close" means for this purpose.

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

`~CSS色~値を構文解析する@ ときは、所与の ( `文字列$ %入力, `要素$ %文脈~要素（省略時は ε ）) に対し： ◎ 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 ）］~channelを直に指定して~sRGB色を定義する。その構文は： ◎ The rgb() and rgba() functions define an sRGB color by specifying the r, g and b (red, green, and blue) channels 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 | one] ]? )
`modern-rgba-syntax@t
	= rgba(
		[ `number$t | `percentage$t | `none$v]{3}
		[ / [`alpha-value$t | `none$v] ]? )

百分率	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 ）］~channelを指定する。 `percentage$t に対する［ `0%^v は，~sRGB色域においてその色~channelの最小~値／ `100%^v は，最大~値］を表現する。 ◎ The first three arguments specify the r, g and b (red, green, and blue) channels of the color, respectively. 0% represents the minimum value for that color channel in the sRGB gamut, and 100% represents the maximum value.

色~channelの百分率~基準~範囲は、多くの~graphic~engineが，色~channelを［ 0 以上 255 以下の整数を保持できる単独の~byte ］として内部的に格納していた歴史的な事実に由来する。実装は，アリな所では、 ~channelの精度を［著作-／計算- ］されたとおりに尊守するベキである。これがアリでない場合、当の~channelを`丸める$ベキである。 ◎ The percentage reference range of the color channels comes from the historical fact that many graphics engines stored the color channels internally as a single byte, which can hold integers between 0 and 255. Implementations should honor the precision of the channel as authored or calculated wherever possible. If this is not possible, the channel 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色@ 記法により、各~channelに~hex数を与えて~sRGB色を指定することも許容される。それは、 ~computer~codeで色を直に与えるときによくある書き方に類似する。また、 `rgb$f 記法より短く書ける。 ◎ The CSS hex color notation allows an sRGB color to be specified by giving the channels 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 ］~channelを指定する。ここで，［ `00^v が色の最小~値／ `ff^v （ 10 進数で255 ）が色の最大~値］を表現する。色の~alpha~channelは全に不透明になる。 ◎ The first pair of digits, interpreted as a hexadecimal number, specifies the red channel 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 channel, and the last pair specifies the blue. The alpha channel 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~channelを指定する。ここで，［ `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 channel 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 ］~channelを指定する。ここで，［ `0^v が色の最小~値／ `f^v が色の最大~値］を表現する。色の~alpha~channelは全に不透明になる。 ◎ This is a shorter variant of the 6-digit notation. The first digit, interpreted as a hexadecimal number, specifies the red channel of the color, where 0 represents the minimum value and f represents the maximum. The next two digits represent the green and blue channels, respectively, in the same way. The alpha channel 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~channelを表現し，同様に［ `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 channel of the color, where 0 represents the minimum value and f represents the maximum. The next three digits represent the green, blue, and alpha channels, 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は，明な~modeから暗な~modeへの（およびその逆の）変化にも応答する。 ◎ To maintain legibility, the <system-color> keywords also respond to light mode or dark mode changes.

例えば，伝統的な `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の中に強制される。各種 `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. 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による色。色見本が市松模様に現れるものは、利用-中な~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

例えば、現在~利用-中な~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 § 20 Privacy Considerations and § 19 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 の一種である†。 ◎ The keyword transparent specifies a transparent black. It is a type of <named-color>.

【† と記されているが、 `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? )

百分率	S, L に許容される
百分率t基準~範囲（ S, L ）	0% = 0.0, 100% = 100.0

◎ Percentages｜Allowed for S and L Percent reference range｜for S and L: 0% = 0.0, 100% = 100.0

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~channelを指定し， `rgb$f 関数を成す 4 個目の引数と同じに解釈される。省略-時の既定は `100%^v になる。 ◎ The final argument specifies the alpha channel of the color. It’s interpreted identically to the fourth argument of the rgb() function. If omitted, it defaults to 100%.

~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 ］~channelを表現する 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 channels 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;

    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;
    }

    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.

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

◎ Percentages｜Allowed for W and B Percent reference range｜for W and B: 0% = 0.0, 100% = 100.0

1 個目の引数は、色相を指定し， `hsl$f のそれと同じに解釈される。このことは、色相の一様~性など，~HSLと同じ`不利点の難がある＠#disadvantage-hsl$ことを意味する。 ◎ The first argument specifies the hue, and is interpreted 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%).

値が範囲~外でも、無効にはならない — ［白度, 黒度【！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~channelを指定し， `rgb$f 関数を成す 4 個目の引数と同じに解釈される。省略-時の既定は `100%^v になる。 ◎ The fourth argument specifies the alpha channel of the color. It’s interpreted identically to the fourth argument of the rgb() function. If omitted, it defaults to 100%.

`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) {
    var %hue = rgbToHue(%red, %green, %blue);
    var %white = Math.min(%red, %green, %blue);
    var %black = 1 - Math.max(%red, %green, %blue);
    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†ように意図されている。 ◎ 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.

【† ヒトが感じる色の近さ度合いが、どの座標でも一様に，空間における色の距離におよそ比例する（`参考＠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 による日光の波長分布の下で、全拡散反射板†から反射される色 — であり，晴天日の太陽光の色を近似する。 ~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.

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

他の白色点を利用して指定された色からの変換†は， `有彩色~順応~変形@ （ `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.

【† すなわち、白色点（波長分布）が異なる光源の下で撮影された画像の色を， “標準な光源”（ ~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 § 18.1 Δ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 § 18.2 Δ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).
省略可能な 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

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

~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

◎ 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

~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 ), %C ~SET `sqrt^op( %a ~MUL %a ~PLUS %b ~MUL %b ), %L はそのまま同じ ◎ Conversion to the polar form is trivial: • H = atan2(b, a) • C = sqrt(a^2 + b^2) • 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 )†, %b ~SET %C ~MUL `sin^op( %H )†, %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

† %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
	| `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をとる。 ◎ 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色／ ~ELSE_ 表示~用に， %指定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(86.6146% 160.0000 136.0088)^v ◎ in LCH, that color is • lch(86.6146% 160.0000 136.0088);

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

それは、 `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().

`srgb@v

`srgb^v — ~sRGB `SRGB$r — 色~空間は、色の［ ~red, ~green, ~blue ］~channelを表現する， 3 個の数量-~parameterを受容する。いずれの成分も，`色域~内$にある色は範囲 0 以上 1 以下に入る。白色点は`~D65$。 ◎ The srgb [SRGB] color space accepts three numeric parameters, representing the red, green, and blue channels of the color. In-gamut colors have all three components in the range [0, 1]. The whitepoint is D65.

`SRGB$r は 2 つの観視~条件（ `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.

~sRGBは~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
画像~状態†	`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

【† 画像~状態（ `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.

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

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

定義済み色~空間 `線形~sRGB@ （ `sRGB-linear^en ）は、その伝達t関数が光に線形である（~gamma符号化は無い）ことを`除いて^em， `srgb$v と同じである。 ◎ 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@v

`srgb-linear^v — 線形~sRGB `SRGB$r — 色~空間は、色の［ ~red, ~green, ~blue ］~channelを表現する， 3 個の数量-~parameterを受容する。いずれの成分も，`色域~内$にある色は範囲 0 以上 1 以下に入る。白色点は`~D65$。 ◎ The srgb-linear [SRGB] color space accepts three numeric parameters, representing the red, green, and blue channels 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

`display-p3@v

`display-p3^v — ~Display-P3 `Display-P3$r — 色~空間は、色の［ ~red, ~green, ~blue ］~channelを表現する， 3 個の数量-~parameterを受容する。いずれの成分も，`色域~内$にある色は範囲 0 以上 1 以下に入る。これは，利用する原色の純色度は `DCI-P3$r と同じである一方、白色点は~sRGBと同じ`~D65$, 伝達t曲線も~sRGBと同じである。 ◎ The display-p3 [Display-P3] color space accepts three numeric parameters, representing the red, green, and blue channels of the color. In-gamut colors have all three components in the range [0, 1]. 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

~LCHにおける~P3色~空間の視覚-化。原色と二次色が示されている（が、~sRGB内でなく，正しい色ではない）。比較~用に，~sRGBの原色と二次色も破線の円で示されている。 ~P3原色の色度は、もっと高い。 ◎ Visualization of the P3 color space in LCH. 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. 定義済み色~空間 ~A98~RGB： `a98-rgb^v ~keyword

`a98-rgb@v

`a98-rgb^v — ~A98【 Adobe® RGB (1998) 】 — 色~空間は、色の［ ~red, ~green, ~blue ］~channelを表現する， 3 個の数量-~parameterを受容する。いずれの成分も，`色域~内$にある色は範囲 0 以上 1 以下に入る。伝達t曲線は、 1/2.2 に近い（が正確には異なる）~gamma関数である。 ◎ The a98-rgb color space accepts three numeric parameters, representing the red, green, and blue channels of the color. In-gamut colors have all three components in the range [0, 1]. 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関数	256/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

~LCHにおける~A98色~空間 `a98-rgb$v の視覚-化。原色と二次色が示されている（が、~sRGB内でなく，正しい色ではない）。比較~用に，~sRGBの原色と二次色も破線の円で示されている。 `a98-rgb^v 原色の色度は、他より，とりわけ［ ~yellow, ~green, ~cyan ］において高い。 ◎ Visualization of the A98 color space in LCH. 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.6. 定義済み色~空間 ~ProPhoto~RGB： `prophoto-rgb^v ~keyword

`prophoto-rgb@v

`prophoto-rgb^v — ~ProPhoto~RGB — 色~空間は、色の［ ~red, ~green, ~blue ］~channelを表現する， 3 個の数量-~parameterを受容する。いずれの成分も，`色域~内$にある色は範囲 0 以上 1 以下に入る。伝達t曲線は、値 1/1.8 の~gamma関数である — が，~blackにごく近い所では線形になる。白色点は、 ~CIE~Labと同じ`~D50$である。したがって，~CIE~Labへの変換は、 `有彩色~順応$段を要さない。 ◎ The prophoto-rgb color space accepts three numeric parameters, representing the red, green, and blue channels of the color. In-gamut colors have all three components in the range [0, 1]. The transfer curve is a gamma function with a value of 1/1.8, and a small linear portion near black. 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.

~ProPhoto~RGB空間は、物理的には実現-不能な，超~彩度な原色を利用する。それらは、［色調の操作-時に色相のズレを最小限にする］ように選ばれている。それは、写真-画像の~archive用~version用の広-色域な色~空間として， ~digital写真撮影に利用されることが多い。 `prophoto-rgb^v 色~空間は、そのような画像~内の色に合致する色を，~CSSにおいて同じ~RGB値で指定できるようにする。 ◎ 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. 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.

~ProPhoto~RGB空間は、元々は 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†（したがって，~black輝度）になる。【†元の画像に無かった光（~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.

~LCHにおける `protphoto-rgb^v 色~空間の視覚-化。原色と二次色が示されている（が、~sRGB内でなく，正しい色ではない）。比較~用に，~sRGBの原色と二次色も破線の円で示されている。 `prophoto-rgb^v の原色と二次色の色度は，ずっと高く、この超広-色域を成すかなりの部分は，物理的に実現-可能な色には対応しない。 ◎ Visualization of the prophoto-rgb color space in LCH. 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.7. 定義済み色~空間 ~Rec2020： `rec2020^v ~keyword

`rec2020@v

`rec2020^v — `ITU Reference 2020^cite `Rec.2020$r — 色~空間は、色の［ ~red, ~green, ~blue ］~channelを表現する， 3 個の数量-~parameterを受容する。これらの妥当な範囲 0 以上 1 以下である。いずれの成分も，`色域~内$にある色は範囲 0 以上 1 以下に入る（動画~用語における “`full-range^en【全-範囲】” ）。この色~空間は、 `Ultra High Definition, 4k and 8k television^en 【いわゆる~~超高精細テレビ】用に利用される。 ◎ The rec2020 [Rec.2020] color space accepts three numeric parameters, representing the red, green, and blue channels of the color. In-gamut colors have all three components in the range [0, 1], ("full-range", in video terminology). 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は、 `rec2020$v の全部的な色域は再現-不能である — 時を経て~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関数	下の，光に線形な成分を見よ
画像~状態	`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｜see below, from [Rec.2020] table 4 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 に対応する光に線形な成分は、 `Rec.2020$r `TABLE 4. Signal format^en に基づく：

%符号 ~LET ［ %C ~LT 0 ならば −1 ／ ~ELSE_ 1 ］
%C ~SET %C の絶対値
%α ~LET 1.09929682680944
%β ~LET 0.018053968510807
%結果 ~LET %C に応じて ⇒＃ %C ~LT %β ~MUL 4.5 ならば %C ~DIV 4.5 ／ ~ELSE_ ( (%C ~PLUS %α ~MINUS 1 ) ~DIV %α ) の ( 1 ~DIV 4.5 ) 乗
~RET %符号 ~MUL %結果

◎ const α = 1.09929682680944 ; const β = 0.018053968510807; let sign = c < 0? -1 : 1; let abs = Math.abs(c); if (abs < β * 4.5 ) { cl = c / 4.5; } else { cl = sign * (Math.pow((abs + α -1 ) / α, 1/0.45)); } ◎ c is the gamma-encoded red, green or blue component. cl is the corresponding linear-light component.

~LCHにおける `rec2020$v 色~空間の視覚-化。原色と二次色が示されている（が、~sRGB内でなく，正しい色ではない）。比較~用に，~sRGBの原色と二次色も破線の円で示されている。 `rec2020$v 原色の色度は、ずっと高い。 ◎ Visualization of the rec2020 color space in LCH. 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.8. 定義済み色~空間 ~CIE~XYZ： `xyz-d50^v, `xyz-d65^v, `xyz^v ~keyword

`xyz-d50@v

`xyz-d65@v

`xyz@v

`xyz^v 色~空間は、［ X, Y, Z ］値を表現している 3 個の数量-~parameterを受容する。それは、 ~CIE~XYZ `COLORIMETRY$r 色~空間を表現する — ［拡散~whiteの`輝度$（ Y ）が 1.0 になる］よう拡縮して、必要yなら，基準~whiteへの`有彩色~順応~変形$も適用して。 ◎ 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-d50$v 用の基準~whiteは`~D50$, ［ `xyz-d65$v ／ `xyz$v ］用の基準~whiteは`~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.9. 定義済み色~空間から~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 § 17 Sample code for Color Conversions.

10.10. ~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 § 17 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.11. 定義済み~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 § 17 Sample code for Color Conversions.

10.12. 単純~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. 色の変換-法

所与の色~空間~内の色は、別の色~空間へ変換できる — 結果の色は、［色域~対応付けを施さない］かつ［どちらの色~空間も【出力~機器の】`色域~外$にある色を表現できる］ならば†，元と同じ††［見かけ, 感覚］を表現することになる。（† このことは、 ~RGB空間においては［伝達t関数は、拡張された範囲にまで定義される］ことを意味する。）（†† 数量的な精度と丸誤差を除けば。） ◎ 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.

`色~空間$ %~source に属する色 %~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:

~IF［ %~source は`円柱な極-座標$で表現される］ ⇒ %~source色 ~SET %~source色を %~source に対応する`矩形な直交-座標$で表現される色~空間へ変換した結果 — `欠落~色~成分$は、 0 に置換する ◎ If src is in a cylindrical polar color representation, first convert col1 to the corresponding rectangular orthogonal color representation and let this be the new col1. 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. 色~補間

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

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

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

各~色に対し： ◎ ↓
1. 【`補間~色~空間$と】`相似的な成分$のうちどれが`先へ運ばれ$【！@】ることになるか検査する。 ◎ checking the two colors for analogous components which will be carried forward
2. `補間~色~空間$へ変換する — この変換は、すでに`補間~色~空間$に属する色に対しても，`無力$な成分を`欠落~色~成分$へ変更する。 ◎ converting them to a given color space＼ ↑ which will be referred to as the interpolation color space below.＼ If one or both colors are already in the interpolation colorspace, this conversion changes any powerless components to missing values
3. 変換された色に`先へ運ばれ$た成分【！値】たちを（もしあれば）挿入し直す。 ◎ (if required) re-inserting carried-forward values in the converted colors
4. （必要なら）色相を修復する — 選定された `hue-interpolation-method$t に依存して。 ◎ (if required) fixing up the hues, depending on the selected <hue-interpolation-method>
5. 各~成分を`乗算済み$な形に変更する。 ◎ 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.

12.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 つの有色な光を物理的に混合した結果が欲される。その事例では、光~強度に線形な，［ ~CIE~XYZ ／ `srgb-linear$v ］色~空間が適切になる。 ◎ In some cases, the result of physically mixing two colored lights is desired. In that case, the CIE XYZ or srgb-linear color space is appropriate, because they are linear in light intensity.
色が知覚的に均等に~~分布する必要がある場合（~gradient内など）、 ~Oklab色~空間（および，より旧い~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（および，より旧い~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色~空間を選ぶことになる — 他より拙い混合-結果を生産する（暗になり過ぎる／~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構文@ と総称される。 `~host構文$は、この仕様では利用されないが，他の仕様から利用できるよう【ここに】公開される — 例えば、 `CSS Images 4^cite `§ 線型~gradient＠~CSSIMAGE4#linear-gradients$ における利用を見よ。 `~host構文$は、各~事例に対し，どれを既定の`補間~色~空間$とするべきか定義するベキである — その場合、この既定を上書きする作者~用の構文も供してヨイ。そのような構文が，ある~prop用の値の一部を成す場合、 `color-interpolation-method$t ~token （他の仕様からの容易な参照~用に，以下に定義される~token）を利用するベキである。これは、［ ~CSSにまたがる一貫性を確保する］ことに加え，［色~補間の遂行-法に対する~custom化が，自動的にすべての~CSSに浸透できる］ようにする。 ◎ These features are collectively termed the host syntax. They are not used by this specification itself, only exposed so that other specifications can use them; see e.g. use in CSS Images 4 § 3.1 Linear Gradients: the linear-gradient() notation. The host syntax should define what the default interpolation color space should be for each case, and optionally provide syntax for authors to override this default. If such syntax is part of a property value, it should use a <color-interpolation-method> token, 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
	| `a98-rgb$v
	| `prophoto-rgb$v
	| `rec2020$v
	| `lab$v
	| `oklab$v
	| `xyz$v
	| `xyz-d50$v
	| `xyz-d65$v
`polar-color-space@t
	= `hsl$v
	| `hwb$v
	| `lch$v
	| `oklch$v
`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.

作者は、特定0の~instanceにおいて，~sRGB内での補間を選好する場合には — 例えば、特定0の~gradientに対し，そのような結果が欲される所では — `補間~色~空間$として~sRGBを明示的に指定することにより，旧-挙動を選べる。 ◎ Authors that prefer interpolation in sRGB in a particular instance can opt-in to the old behavior by explicitly specifying sRGB as the interpolation color space, for example on a particular gradient where that result is desired.

色が`補間~色~空間$の色域の外側に補間されることになる場合、その空間へ変換した結果は，範囲~外の値を包含することになる。そのような値は、 ~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, but the values are interpolated as-is.

12.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 ） — すなわち、［線形な補間, 【それに伴われる】`乗算済み$化］が場を占める前に，変換した結果の色に挿入し直される†ことになる。 ◎ 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.

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

`相似的な成分@ （ `analogous component^en ）は、次に従って分類される： ◎ The analogous components are as follows:

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

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

【† “色彩度（ `colorfulness^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 つの色が~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.

したがって、先へ運ぶ段は，`無力$な成分を取扱うより前に遂行するモノトスル。 ◎ Therefore, the carrying-forward step must be performed before any powerless component handling.

例えば、次の 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)

次ではなく ⇒＃ `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)

［ `先へ運ばれ$た`欠落~色~成分$ ］が~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].

両~色とも所与の成分が`欠落な$場合、補間される両~色とも，その成分は`欠落である$ことになる。 ◎ If both colors are missing a given component, the interpolated color will also be missing that component.

12.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.

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

%~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 § 17 Sample code for Color Conversions.

12.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 ◎ 12.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) (30 + 90) / 2

角度は［ %θ₂ ~MINUS %θ₁ ~IN [−180, 180] ］が満たされるよう調整される。疑似-~JSでは： ◎ Angles are adjusted so that θ₂ - θ₁ ∈ [-180, 180]. In pseudo-Javascript:

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

`longer@v ◎ 12.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)

角度は［ %θ₂ ~MINUS %θ₁ ~IN (-360, -180] ］~OR［ %θ₂ ~MINUS %θ₁ ~IN [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 ◎ 12.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).

しかしながら， 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.

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

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

`decreasing@v ◎ 12.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).

しかしながら， 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.

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

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

13. 色域~対応付け

13.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.

13.1.1. ~clip法

最も単純かつ最も受容-可能でない手法は、単純に［各~成分~値を表示-可能な範囲に~clipする］ことである。これは、（~RGB~display用の） 3 原色の相対比を変化させるので，結果の色相がズレる。 ◎ The simplest and least acceptable method is simply to clip the component values to the displayable range. 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°.

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

もっと良い手法は、 `最小~DeltaE@ （略称 `MINDE^en †） — 知覚的に一様な色~空間~内で，その`色域~内$にある最も近い色を見出すこと — により，色を対応付けることである。この技法の成否は、明瞭に［色域~対応付け色~空間の一様さ度合い, 利用される~DeltaE関数の予測上の正確度］に依存する。【† 原文の表記は “MINDE” （ `MIN^en + `Delta E^en ）が主だが、この訳では “最小~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.

しかしながら，色域~対応付けを行うとき、色相における変化は，`特に^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.

13.1.3. 色度~抑制

色度~抑制は、 `最小~DeltaE$による~algoを改善する — それは、次により色を対応付ける ⇒ 知覚的に一様な`極-座標^em色~空間~内で、色相を一定に保持しながら，色が`色域~内$に入るまで色度を抑制する。 ◎ To improve on MINDE algorithms, 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.

この例では、 ~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.

実用的な実装は、線形な抑制より素早く収束することになる — 二分-探索により，あるいは、一定な［色相, 明度］が成す線と色域~境界との交点を幾何的に算出することにより。 ◎ A practical implementation will converge more quickly than a linear reduction; either by binary search, or by computing the geometric intersection of the line of constant hue and lightness with the gamut boundary.

13.1.4. 過度な色度~抑制

この【前節の】単純な~approachは、ある種の色 — 主に、 ~yellowや~cyanの様な，ごく明な色 — に対しては，色域~境界の上辺が浅い場合に — あるいは少し凹んでいる場合でも — 最適とは言えない結果を与えることになる。それらの事例では、一定な明度が成す線が色域~境界の直上を掬い取り得るので，結果の色度は過度に低くなる。 ◎ Also, this simple 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.

13.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.

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

［ ~CIE~LCH色~空間と~DeltaE 2000 距離~計量］を利用することは、色相~範囲 270° 以上 330° 以下の色に対しては，［有意な色相ズレを伴うので，最適とは言えない結果を与える］ことが既知である。 ◎ Using the CIE LCH color space and 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 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.

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

この節に与える `~CSS色域~対応付け~algo@ は、個々の［ ~SDR（ `Standard Dynamic Range^en, “標準~可動~範囲” ）~CSS色］のうち［ ~RGB~displayの色域~外にあるので `~CSS色域~対応付け@ が要求されるものに適用される。 ◎ The CSS gamut mapping algorithm applies 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.

この~algoは、 `相対~色計量~意図$を実装することに加え，行先~色域の内側にある色は変更しない。 ◎ It implements a relative colorimetric intent, and 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: this algorithm is 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.

~CSS色域~対応付けは、 `~OKLCh色~空間$内で生じる — 利用される色~差~公式は`~DeltaE~OK$である。 `局所的な最小~DeltaE＠#GM-chroma-local-MINDE$による改善が利用される。 ◎ CSS gamut mapping occurs in the OKLCh color space, and the color difference formula used is deltaEOK. The local-MINDE improvement is used.

明度~軸~上で範囲~外にある色に対しては、［明度 ~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.

二分-探索~実装~用には、当の探索~内の各~段にて，［現在の対応付けられた色とその色を~clipした結果］の~DeltaE~OKが算出される。結果の~DeltaE~OKが`~JND$を下回る場合、現在の色が当の色域~境界の`外側^emにあるならば， ~clipした結果の色が対応付けられた結果として返す。 ◎ For the binary search implementation, at each step in the search, the deltaEOK 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 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.

幾何的な実装~用には： ◎ For the geometric implementation,＼

正確な交点が見出されたなら、一定な明度が成す線に沿って外方へ（より高い色度へ向けて），次に挙げるいずれか【近い方】まで射影する： ◎ having found the exact intersection, project outwards (towards higher chroma) along the line of constant lightness until either:
- ［射影された地点, その地点を~clipした結果］の~DeltaE~OKが 1 `~JND$を超過する所 ◎ the deltaEOK between the projected point and a clipped version of that point exceeds one JND, or
- 射影された地点の色度が元の色の色度に等しくなる所（すなわち，元の色を過ぎる所へは射影しない） ◎ the chroma of the projected point is equal to the chroma of the original color (i.e. do not project past the original color)
前~段で得た地点を~clipした結果の色を，対応付けられた結果として返す。 ◎ Then return the clipped version of the color as the mapped result.

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.

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

`色域~対応付けを施す@ ときは、所与の ( 色~空間 %変換元~色~空間, %変換元~色~空間内の色 %変換元, 行先~色~空間 %行先~色~空間 ) に対し ⇒ ~RET 次の下位-手続きを遂行した結果を %行先~色~空間へ変換した結果 ◎ To CSS gamut map 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は無い† ］ ⇒ ~RET %現在の色

【† すなわち、 %行先~色域は~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
%ほぼ0 ~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 %ほぼ0 ］： ◎ 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 %ほぼ0 ］ ⇒ ~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. `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.

14.1. ~sRGB値の解決-法

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

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

~sRGB色が作者により明示的に［ `有名~色$／`~system色$ ］として指定された場合： ◎ If the sRGB color was explicitly specified by the author as a named color, or as a system color,＼

`宣言d値$は、当の色~名を`~ASCII小文字~化$した結果になる。 ◎ the declared value is that named or system color, converted to ASCII lowercase＼
［ `宣言d値$／`使用~値$ ］は、次が成す~pairになる：
- 対応する~sRGB色
- 指定された~alpha~channel （ 0 以上 1 以下に切詰めた後における） — 未指定な場合の既定は、不透明になるとする。
◎ The computed and used value is the corresponding sRGB color, paired with the specified alpha channel (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~channel （ 0 以上 1 以下に切詰めた後における） — 未指定な場合の既定は、不透明になるとする。

◎ Otherwise, the declared, computed and used value is the corresponding sRGB color, paired with the specified alpha channel (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)

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

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

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

対応する~CIE［ ~Lab／~LCH ］色（ L, C, H を切詰めた後における）
指定された~alpha~channel ⇒＃ `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 channel (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)

14.3. ~Oklab／~OKLCh値の解決-法

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

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

対応する［ ~Oklab／~OKLCh ］色（ L, C, H を切詰めた後における）
指定された~alpha~channel （ `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 channel (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)

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

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

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

◎ The declared, computed and used value is the color in the specified color space, paired with the specified alpha channel (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)

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

この節は、次に挙げる値に適用される ⇒＃ `system-color$t【！`~system色$】, `deprecated-color$t【！(including the <deprecated-color>s)】, `transparent$v, `currentcolor$v ◎ This applies to system colors (including the <deprecated-color>s), transparent, and currentcolor.

各［ `system-color$t ／ `deprecated-color$t ］~keywordの：

`宣言d値$は、それ自身になる。
`算出d値$は、それが属する色~空間~内の対応する色になる。しかしながら、そのような色は， “強制d色~mode” により改められないモノトスル。

◎ The declared value for each <system-color> keyword and <deprecated-color> keyword is itself. The computed value is the corresponding color in its color space. However, such colors must not be altered by 'forced colors mode'.

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

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

`color^p ~propの宣言d値は "`ButtonText$vS" になる一方、算出d値は，例えば `#000^swatch【！#FFF】 `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).

`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 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.

15. `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".

15.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値 %~alpha を直列化するときは、次の手続きを遂行した結果（ 0 以上 1 未満の実数）を（ `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>).

~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用に】 `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値に維持される精度 — したがって、直列化した結果における小数部の桁数 — は，この仕様では定義されないが、少なくとも［整数な百分率~値が往復する］に足るようにするモノトスル。したがって，結果における小数部は、尾部を成す 0 たちが省略された場合を除き， 2 桁以上になる。値は、切捨てるのではなく，`丸める$モノトスル。 ◎ The precision with which alpha 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.

実数をある精度までに `丸める@ ときは、 2 数に等しく近い場合には，正な無限大に近い方を選ぶとする。

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

例えば，~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.

妥当な範囲の外側に指定された `alpha-value$t は，構文解析-時に切詰められるので、その`宣言d値$は，切詰められることになる。しかしながら， `CSS-VALUES-4$r `§ 範囲の検査-法＠~CSSVAL#calc-range$ により、 `calc^f 【より一般には`~math関数$】を利用して指定された `alpha-value$t は，［宣言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)".

15.2. ~sRGB値の直列化-法

次に挙げる~sRGB値に対しては ⇒＃ `~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

直列化した形は、 `宣言d値$から導出される。 ◎ is derived from the declared value.

したがって，作者により［ `named-color$t【！`有名~色$】／ `system-color$t【！`~system色$】／ `deprecated-color$t【！#deprecated-system-colors】／ `transparent$v ］に設定された~propの値を直列化するときは： ◎ 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,＼

`宣言d値$用には，~ASCII小文字による~keyword値が維持される。 ◎ for the declared value, the ASCII lowercase keyword value is retained.＼
［ `算出d値$／`使用~値$ ］用には，対応する~sRGB値が利用される。 ◎ For the computed and used value, the corresponding sRGB value is used.

したがって， `transparent$v を直列化した結果は ⇒＃宣言d値であったなら `transparent^l になる。算出d値であったなら `rgba(0, 0, 0, 0)^l になる。 ◎ 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)".

他のすべての~sRGB値~用には、［宣言d値, 算出d値, 使用~値］は、どれも，対応する~sRGB値になる。 ◎ For all other sRGB values, the declared, computed and used value is the corresponding sRGB value.

直列化においては、 `欠落~成分$は， 0 へ変換される。 ◎ During serialization, any missing values are converted to 0.

15.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直列化＠#css-serialization-of-srgb$に従う。他の色~空間~用には関連な`直列化＠#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)".

15.2.2. ~sRGB値の~CSS直列化

~sRGB値は、（（切詰められた結果の）~alphaが正確に 1 になるか否かに依存して）［ `rgb$f, `rgba$f ］いずれかの形を利用する — 関数の名前は、 `~ASCII小文字~化$される。 ◎ 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 （または `100%^v ）は、 `§ ~alpha値の直列化-法$に注記したとおり，明示的に直列化されない。次の形を利用するとする ⇒＃ ~alpha ~EQ 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.

例えば， `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.

注記： `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)"

15.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 †の外側にある［ a ／ b ］値もアリになる。例えば、 `prophoto-rgb$v の原色と二次色は、 `どれも^em，この範囲を超過する（ ±200 の中に入るが）。【† 上の段落に指定された範囲 ±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 （または `100%^v ）は、 `§ ~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)"

15.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 の各~成分~値に維持される精度 — したがって、直列化した結果における有効数字の個数 — は，この仕様では定義されないが、広-色域に因り，少なくとも［精度 16 ~bitの［ 0 以上 1 以下（ 0% 以上 100% 以下）の L 値／ −0.5 以上 0.5 以下の［ a ／ b ／ C ］値］が往復する］に足るようにするモノトスル。したがって，結果における小数部は、尾部を成す 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 （または `100%^v ）は、 `§ ~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)"

15.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 （または `100%^v ）は、 `§ ~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.

15.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".

16. 既定の~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; }

17. 色~変換~用の見本~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.
 */
	// ITU-R BT.2020-2 p.4
	const %α = 1.09929682680944 ;
	const %β = 0.018053968510807;

	return %RGB.map(function (%val) {
		let %sign = %val < 0? -1 : 1;
		let %abs = Math.abs(%val);

		if (%abs < %β * 4.5 ) {
			return %val / 4.5;
		}

		return %sign * (Math.pow((%abs + %α -1 ) / %α, 1/0.45));
	});
}

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
 */
	// ITU-R BT.2020-2 p.4
	const %α = 1.09929682680944 ;
	const %β = 0.018053968510807;

	return %RGB.map(function (%val) {
		let %sign = %val < 0? -1 : 1;
		let %abs = Math.abs(%val);

		if (%abs > %β ) {
			return %sign * (%α * Math.pow(%abs, 0.45) - (%α - 1));
		}

		return 4.5 * %val;
	});
}

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)
 */
	// http://www.brucelindbloom.com/index.html?Eqn_RGB_XYZ_Matrix.html
	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にて利用するときは、
百分率を追加すること。
◎
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_RGB_XYZ_Matrix.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) {
	/* 
極-座標~形へ変換する。
◎
Convert to polar form
 */
	var hue = Math.atan2(%Lab[2], %Lab[1]) * 180 / Math.PI;
	return [
		%Lab[0], /* 
L はそのまま
◎
L is still L
 */
		Math.sqrt(Math.pow(%Lab[1], 2) + Math.pow(%Lab[2], 2)), /* 
色度
◎
Chroma
 */
		hue >= 0 ? hue : hue + 360 /* 
色相（度数）は 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 %hue = Math.atan2(%OKLab[2], %OKLab[1]) * 180 / Math.PI;
	return [
		%OKLab[0], /* 
L はそのまま
◎
L is still L
 */
		Math.sqrt(%OKLab[1] ** 2 + %OKLab[2] ** 2), /* 
色度
◎
Chroma
 */
		%hue >= 0 ? %hue : %hue + 360 /* 
色相（度数）は 0 以上 360 未満になる
◎
Hue, in degrees [0 to 360)
 */
	];
}

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);
}

18. ［~DeltaE 2000, ~DeltaE~OK］色~差~用の見本~code

◎非規範的

18.1. ~DeltaE 2000

最も単純な色~差~計量~DeltaE 76 は、単純に~Lab色~空間~内の~Euclidean距離である。これは，最初の近似としては良いが、色に~criticalな業界 — 印刷ngや織物染色など — は，改善された公式をすぐに開発した。現時点で最も広く利用されている公式は、 ~DeltaE 2000 である。それは、 ~DeltaE 76 に比して，いくつかの既知な［非対称性, 非-線形~性］を正す。公式は複階的であり，様々な中間~計算の正負符号に~criticalに依存するので、不正な実装が多い `Sharma$r 。 ◎ The simplest color difference metric, ΔE76, is simply the Euclidean distance in Lab color space. While this is a good first approximation, color-critical industries such as printing and fabric dyeing soon developed improved formulae. 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 個の有意な~figureに対し， `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†
］により推奨されるが、
意地悪で複雑であり，多くの実装には小さな誤りがある。
【† おそらく， `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} 色 %sample の %reference からの差
 */
◎
/**
 * @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 == 0 && %Cdash2 == 0) {
		%hdash = %hsum;   /* 
0 になるべき
◎
which should be zero
 */
	}
	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† や~DeltaE 94
］公式におけるそれらに類似な。
【† おそらく， `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 項† %T
【† 平たく言えば、 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!!!
 */
};

18.2. ~DeltaE~OK

~Oklabには、 ~CIE~Labの［色相の線形~性, 色相の一様~性, 色度の非-線形~性］のような難はないので，色~差~計量を正す必要は無い — なので、単純に，~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 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} 色 %sample の %reference からの差
 */
◎
/**
 * @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);
}

付録 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による色。色見本が市松模様に現れるものは、利用-中な~UAが~supportしていない（または本当に透明にされている）。】【 “非推奨にされた~system色” と称されているが、 `~system色$の一部を成すものとは定義されていない — 明示的に指定されない限り，［ `~system色$に課される要件が，これらにも自動的に適用される］ことにはならないと思われる。】

`ActiveBorder^swatch `ActiveBorder@vD: ［作動中な~UIwindow ］の~border。 ◎ Active window border.＼; `ButtonBorder$vS と同じ。 ◎ Same as ButtonBorder.
`ActiveCaption^swatch `ActiveCaption@vD: 同対象の~caption。 ◎ Active window caption.＼; `Canvas$vS と同じ。 ◎ Same as Canvas.
`AppWorkspace^swatch `AppWorkspace@vD: 複数の文書~interfaceの背景。 ◎ Background color of multiple document interface.＼; `Canvas$vS と同じ。 ◎ Same as Canvas.
`Background^swatch `Background@vD: ~desktop背景。 ◎ Desktop background.＼; `Canvas$vS と同じ。 ◎ Same as 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 と同じ。 ◎ Same as 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 と同じ。 ◎ Same as ButtonFace.
`CaptionText^swatch `CaptionText@vD: ［ ~caption／~size~box／~scrollbar矢印~box ］内の~text。 ◎ Text in caption, size box, and scrollbar arrow box.＼; `CanvasText$vS と同じ。 ◎ Same as CanvasText.
`InactiveBorder^swatch `InactiveBorder@vD: ［作動中でない~UIwindow ］の~border。 ◎ Inactive window border.＼; `ButtonBorder$vS と同じ。 ◎ Same as ButtonBorder.
`InactiveCaption^swatch `InactiveCaption@vD: 同対象の~caption。 ◎ Inactive window caption.＼; `Canvas$vS と同じ。 ◎ Same as Canvas.
`InactiveCaptionText^swatch `InactiveCaptionText@vD: 同対象の［ ~caption内の~text ］。 ◎ Color of text in an inactive caption.＼; `GrayText$vS と同じ。 ◎ Same as GrayText.
`InfoBackground^swatch `InfoBackground@vD: ~tooltipの背景。 ◎ Background color for tooltip controls.＼; `Canvas$vS と同じ。 ◎ Same as Canvas.
`InfoText^swatch `InfoText@vD: 同対象の~text。 ◎ Text color for tooltip controls.＼; `CanvasText$vS と同じ。 ◎ Same as CanvasText.
`Menu^swatch `Menu@vD: ~menuの背景。 ◎ Menu background.＼; `Canvas$vS と同じ。 ◎ Same as Canvas.
`MenuText^swatch `MenuText@vD: 同対象の~text。 ◎ Text in menus.＼; `CanvasText$vS と同じ。 ◎ Same as CanvasText.
`Scrollbar^swatch `Scrollbar@vD: ~scrollbarの~gray区画。 ◎ Scroll bar gray area.＼; `Canvas$vS と同じ。 ◎ Same as 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 と同じ。 ◎ Same as 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 と同じ。 ◎ Same as 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 と同じ。 ◎ Same as 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 と同じ。 ◎ Same as 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 と同じ。 ◎ Same as ButtonBorder.
`Window^swatch `Window@vD: ~UIwindowの背景。 ◎ Window background.＼; `Canvas$vS と同じ。 ◎ Same as Canvas.
`WindowFrame^swatch `WindowFrame@vD: ~UIwindowの枠。 ◎ Window frame.＼; `ButtonBorder$vS と同じ。 ◎ Same as ButtonBorder.
`WindowText^swatch `WindowText@vD: ~UIwindow内の~text。 ◎ Text in windows.＼; `CanvasText$vS と同じ。 ◎ Same as 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.

変更点

`2024年 2月 13日勧告候補~草案＠~TR/2024/CRD-css-color-4-20240213/$ からの変更点 ◎ Changes since the Candidate Recommendation Draft of 13 Feb 2024

`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 colorspace, 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~channelを［注釈文ではなく，基準~範囲］を利用して指定した。 ◎ Specified RGB channels 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” ~channelを参照していたすべての箇所は、 “欠落~成分” の概念を利用するよう修正した。 ◎ 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" channels 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

色~channel用に要求される精度と丸ngの挙動を明確化した。 ◎ Clarify required precision and rounding behavior for color channels

`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

［表示される色は、（他の~~選択肢もあるかの様に）機器~色域に制約される］とする過剰な要件は、除去した。 ◎ 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.

1. 序論

1.1. 値~定義

2. 色の各種用語

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

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

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

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

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

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

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

4.1. `color^t 構文

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

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

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

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

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

4.4.1. “無力” な色~成分

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

5. ~sRGB色

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

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

6. 色~keyword

6.1. 有名~色

6.2. ~system色

6.3. `transparent^v ~keyword

6.4. `currentcolor^v ~keyword

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

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

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

7.3. ~HSL色の例

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

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

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

8.3. ~HWB色の例

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

9.1. ~CIE~Lab, ~CIE~LCH

9.2. ~Oklabと~OKLCh

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

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

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

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

10. 定義済み色~空間

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

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

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

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

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

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

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

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

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

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

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

10.12. 単純~alpha組成-法

11. 色の変換-法

12. 色~補間

12.1. 補間~用の色~空間

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

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

12.4. 色相の補間

13. 色域~対応付け

13.1. 色域~対応付け序論

13.1.1. ~clip法

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

13.1.3. 色度~抑制

13.1.4. 過度な色度~抑制

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

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

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

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

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

14.1. ~sRGB値の解決-法

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

14.3. ~Oklab／~OKLCh値の解決-法

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

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

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

15.1. ~alpha値の直列化-法

15.2. ~sRGB値の直列化-法

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

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