1. 序論
~INFORMATIVEこの~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, CSS2 にすでに存在する,色に関係する各種~propと値について定義するのみならず,新たな~propと値も定義する。 ◎ It not only defines the color-related properties and values that already exist in CSS1 and CSS2, but also defines new properties and values.
2. 前景~色: `color^p ~prop
◎名 `color@p ◎値 `color$t ◎初 UA により定義される。 注釈文を見よ。 ◎ UA-defined, see prose ◎適 すべての要素 ◎継 される ◎百 受容しない ◎算 `色~値の解決-法$を見よ ◎ See resolving color values ◎順 文法に従う ◎ア 離散的 ◎表終この~propは、要素の~text内容の前景を埋める色を述べる。 加えて、 `currentcolor$v が解決される値も供する。 ◎ This property describes the foreground fill color of an element’s text content. In addition, it provides the value that currentcolor resolves to.
この~propの初期値は `black$v である。 【何故 上の初期値の欄にそう記されない?】 ◎ The initial value of this property is black.
所与の色を指定する仕方には、いくつかの構文が~~用意されている。 ◎ There are several different ways to syntactically specify a given color.
例えば、~lime~greenを指定するには: ◎ For example, to specify lime green:
em { color: lime; } /* 色~keywordで指定する */ em { color: rgb(0 255 0); } /* RGB 範囲 0 〜 255 で指定する */ em { color: rgb(0% 100% 0%); } /* RGB 範囲 0% 〜 100% で指定する */
`color$t 型については、後の節にて定義される。 ◎ <color> ◎ The <color> type is defined in a later section.
注記: 一般に,この~propは、その~alpha成分も含め, “色~付き~glyph” に対する効果はない — 組込みの~paletteにより色が与えられている,一部の~font内の絵文字など。 一部の有色~fontは、前景~色を~~参照できる — OpenType の COLR table 内の~palette~entry 0xFFFF や, SVG-in-OpenType 内の `context-fill^v 値など。 その事例では、前景~色はこの~propにより設定され, `currentcolor$v 値と同じに働く。 ◎ Note: In general, this property, including its alpha component, has no effect on "color glyphs", such as emoji in some fonts, which are colored by a built-in palette. Some colored fonts are able to refer to the foreground color, such as palette entry 0xFFFF in COLR table of OpenType, and context-fill value in SVG-in-OpenType. In that case, the foreground color is set by this property, identical to how currentcolor value works.
3. ~sRGB色: `color$t 型の表現-法
~sRGB色~空間による~CSS色は、値の三組 — ~red, ~green, ~blue — により表現され,~sRGB色~空間 `SRGB$r 内のある点を識別する。 この色~空間は、国際的に認識される,機器に依存しない色~空間であり、~computer~screen上で表示される色を指定するときのみならず,印刷機の様な他の型の機器~上で色を指定するときにも有用にもなる( `COLORIMETRY$r を見よ)。 加えて、どの色にも,不透明度 — 後景が色の背後からどの程度透けて見えるか — を指示する~alpha成分が付帯する。 各~成分は “~channel” と呼ばれることもある。 各~channelがとり得る値の範囲には,最小と最大があり,その範囲~内のどの値もとれる。 ◎ 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. (See [COLORIMETRY].) Additionally, every color is accompanied by an alpha component, indicating how transparent it is, and thus how much of the backdrop one can see behind the color. The components are also sometimes called "channels". Each channel has a minimum and maximum value, and can take any value between those two.
すべての色は、下層においては同じ記憶形式を共有する: ~CSSには、 `color$t 値を指定するためとして,いくつかの構文が~~用意されている。 `rgb$f, `rgba$f 関数 や~hex記法など,~sRGB色を直に指定するものあれば、 `hsl$f, `hsla$f 関数や, ~CSSが定義する各種 `有名~色$の長大な~listなど,より人に馴染み易く書いたり理解でき, かつ~CSSにより~sRGB色に変換されるものもある。 ◎ While all colors share an underlying storage format, CSS contains several syntaxes for specifying <color> values. Some directly specify the sRGB color, such as the rgb() and rgba() functions and the hex notation. Others are more human-friendly to write and understand, and are converted to an sRGB color by CSS, such as the hsl() and hsla() functions, or the long list of named colors defined by CSS.
総てを併せた `color$t の定義は次で与えられる: ◎ In total, the definition of <color> is:
`color@t = <`rgb$f> | <`rgba$f> | <`hsl$f> | <`hsla$f> | <`hwb$f> | <`gray$f> | <`device-cmyk$f> | `hex-color$t | `named-color$t | `currentcolor$v | `deprecated-system-color$t
演算によっては、 `無彩色@ に対する働きが異なることがある。 `無彩色$とは、~grayの濃淡である: ~RGB色空間においては,[ ~red, ~green, ~blue ]~channelのいずれも同じ値をとる色が `無彩色$とされ、 ~HSL色空間においては,彩度 `0%^v の色が `無彩色$とされ、 ~HWB色空間においては,白味と黒味の和が `100%^v 以上になる色が `無彩色$とされる。 ◎ Some operations work differently on achromatic colors. An achromatic color is a shade of gray: in the RGB colorspace, a color is achromatic if the red, green, and blue channels are all the same value; in the HSL colorspace, a color is achromatic if the saturation is 0%; in the HWB colorspace, a color is achromatic if the sum of the whiteness and blackness is at least 100%.
他の仕様から参照し易くするため、次の用語を定義する: ◎ For easy reference in other specifications,\
- `不透明な黒@ とは、 ( ~red, ~green, ~blue ) 成分がすべて最小~値にされ, ~alpha成分は最大~値にされた~sRGB色とする( `rgb(0 0 0 / 100%)^v が生産する色と同じ)。 ◎ opaque black is an sRGB color with the red, green, and blue components all at their minimum value, and the alpha component at its maximum value (the same color as produced by rgb(0 0 0 / 100%)).\
- `透明な黒@ とは、~alpha成分は最小~値にされることを除き,`不透明な黒$と同じとする( `rgb(0 0 0 / 0%)^v が生産する色と同じ)。 ◎ Transparent black is the same color, but with the alpha component at the minimum instead (the same color as produced by rgb(0 0 0 / 0%)).
3.1. 色を利用するときの注意点
色は、文書をより読易くし,有意~な量の情報を追加できるが、色それ自体が 重要な情報を運ぶ~~唯一の手段になるべきでない。 文書に色を含ませるときには、 W3C Web Content Accessibility Guidelines `WCAG20$r ( Web 内容~accessibilityのための指針)を考慮するように。 ◎ Although colors can add significant amounts of information to documents and make them more readable, color by itself should not be the sole means to convey important information. Please consider the W3C Web Content Accessibility Guidelines [WCAG20] when including color in your documents.
1.4.1 Use of Color(色の利用): [ 情報を運ぶ/動作を指示する/応答を促す/視覚的~要素を判別する ]ための視覚的~手段として,色のみに~~頼らないこと。 ◎ 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. ~sRGBにおける色
~CSS /~HTML/ `無tag画像$ にて指定される色は、~sRGB色~空間( `SRGB$r )に属する。 ◎ Colors specified in CSS, HTML, and untagged images are in the sRGB color space ([SRGB]).
注記: これはまだ,依拠できるほど各 実装にわたって実装されていない — 実装-可能なことは示されているが。 互換に実装するためには、色が頁~内で互いに合致しない課題を避けるため,~pluginに対し同じ仕方で無tag色を扱うよう通知することを要するであろう。 ◎ This is not yet reliably implemented across implementations, though it has been shown to be implementable. Implementing it compatibly may require notifying plugins to treat untagged colors in the same way to avoid issues with colors not matching each other within a page.
`無tag画像@ とは、[ 当の画像~形式による定義に従って,色~profileが明示的にあてがわれている画像 ]ではない画像を指す。 ◎ An untagged image is an image that is not explicitly assigned a color profile, as defined by the image format.
この規則は動画には適用されないことに注意。 無tag動画は、 ITU にて presume されるべき【?】なので。 ◎ Note that this rule does not apply to videos, since untagged video should be presumed to be in ITU.
- 720p 未満においては、それは Recommendation ITU-R BT.601 [ITU-R-BT.601] を指す。 ◎ At below 720p, it is Recommendation ITU-R BT.601 [ITU-R-BT.601]
- 720p においては、それは SMPTE ST 296 ( 709 と同じ色計量~法) [SMPTE-ST-296] を指す。 ◎ At 720p, it is SMPTE ST 296 (same colorimetry as 709) [SMPTE-ST-296]
- 1080p においては、それは Recommendation ITU-R BT.709 [ITU-R-BT.709] を指す。 ◎ At 1080p, it is Recommendation ITU-R BT.709 [ITU-R-BT.709]
[css-color] issue#287: colorspace for video (動画~用の色空間) ◎ w3c/csswg-drafts/287[css-color] colorspace for video
4. 色~値の解決-法
種々の~propは `color$t 値を受容する。 明示的に例外が定義されない限り、そのような どの~propも,下に定義されるように `色~値を解決-@ して, `color$t に対する`算出値$と`使用値$を決定し~MUST。 ◎ Various properties accept <color> values. Unless an exception is explicitly defined, all such properties must resolve color values as defined below to determine the computed value and the used value for <color>.
-
`color$p ~propに対しては、その指定値 `currentcolor$v は, `inherit$v として扱われる。 ◎ If currentcolor is the specified value of the color property, it is treated as if the specified value was inherit.
`color$t を受容する他のすべての~propに対しては、 `currentcolor$v ~keywordの算出値は `currentcolor$v になり,使用値は 同じ要素~上の `color$p ~propの使用値と同じになる。 ◎ For all other properties that accept a <color>, the computed value of the currentcolor keyword is currentcolor, and the used value of currentcolor is the same as the used value of the color property on the same element.
注記: したがって, `currentcolor$v 値が継承されるときは、 `color$p ~propの値としてではなく,~keywordとして継承される。 なので,子孫は、それを解決するときに自前の `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.
-
`transparent$v の[ 算出値/使用値 ]は `rgba(0, 0, 0, 0)^v になる。 ◎ The computed value and used value of transparent is rgba(0, 0, 0, 0).
Gecko は、他の~browserと異なり,~alpha ~channel 0 のどの `color$t も `transparent$v として直列化する。 ◎ Gecko disagrees, and serializes any <color> with an alpha channel of 0 as transparent. No other browser does that though.
-
次に挙げる色の[ 算出値/使用値 ]は、~alpha値を省略した ~comma区切りの `rgb$f 記法による等価な数量~値になる:
- `有名~色$( `deprecated-system-color$t による色も含む)
- 3 桁/ 6 桁の`~hex色$
- ~alpha~channelは伴わない,~comma区切りの[ `rgb$f 色 / `hsl$f 色 ]
- 明示的に不透明な~alpha~channelを伴うような,次に挙げる色:
- 4 桁/ 8 桁の`~hex色$
- ~comma区切りの `rgba$f 色
- ~comma区切りの `hsla$f 色
-
次に挙げる色の[ 算出値/使用値 ]は、その~alpha~channelは不透明でないならば,[ ~alpha値も伴われた,~comma区切りの `rgba$f 記法による等価な数量~値 ]になる:
- 4 桁 / 8桁 の`~hex色$
- ~comma区切りの `rgba$f 色
- ~comma区切りの `hsla$f 色
上述は、最も相互運用可能な挙動に基づいて,すでに実装されている値を定義しているが、より新たな構文がどう働くか定義する必要がある: ◎ The above defines values that are already implemented based on the most interoperable behavior. We still need to define how newer syntaxes work:
- ~comma区切りでない `rgb$f, `rgba$f, `hsl$f, `hsla$f であって,~slash区切りの~alpha~channelを伴うもの。
- ~comma区切りの `rgb$f, `rgba$f, `hsl$f, `hsla$f であって,【~slash区切りの?】~alpha~channelを伴うもの。
- `device-cmyk$f
- `hwb$f
- `lab$f, `lch$f
- `gray$f
- `color$f
作業用~色~空間を変更したときに,上述に何か~~影響を及ぼすべきかどうか定義する。 ◎ Define if changing the working color space should have any impact on the above.
各種~仕様は、指定された数値が範囲~外にあるときの 種々の数量~記法にて起こるべき切詰法の種類を定義し,その精細さも様々である — 算出値の時点で起こると記していることもあれば, いつ起こるか記してないこともあれば, 何も記していないこともある。 これらは、ここに~~集約されるべきであろう。 ◎ Various parts of the spec define the kind of clamping that should happen to the various numeric notations when the numbers specified are out of range, and do so with varrying precision, sometimes saying that this happens at computed value time, sometimes not saying when it happens, and sometimes not saying anything at all. Maybe this should be consolidated here.
`color$t の構文を拡張する将来の仕様は、新たな拡張~用に`色~値を解決-$する方法を定義し~MUST。 ◎ Any future specification extending the syntax of <color> must define the how to resolve color values for the new extensions.
5. ~RGB色
色をその~RGBA各~channelを通して直に指定するような,いくつかの手法がある。 ◎ There are several methods of directly specifying a color in terms of its RGBA channels.
5.1. ~RGB関数: `rgb^f, `rgba^f
`rgb$f 関数は、[ ~red, ~green, ~blue ]~channelを直に指定して~RGB色を定義する。 その構文は次で与えられる: ◎ The rgb() function defines an RGB color by specifying the red, green, and blue channels directly. Its syntax is:
`rgb@f = rgb( `percentage$t{3} [ / `alpha-value$t ]? ) | rgb( `number$t{3} [ / `alpha-value$t ]? ) `alpha-value@t = `number$t | `percentage$t
最初の 3 個の引数は、順に,色の[ ~red, ~green, ~blue ]~channelを指定する。 `percentage$t に対する `0%^v は、~sRGB色域においてその色~channelの最小~値を表現し, `100%^v は最大~値を表現する。 `number$t は `percentage$t に等価であるが,とる範囲は異なる: ここでも `0^v は色~channelの最小~値を表現するが,最大~値は `255^v が表現する。 これらの値は、多くの~graphic~engineが,色~channelを[ 0 〜 255 の整数を保持できる単独の~byte ]として内部的に格納する事実から来る。 実装は,可能な所では、~channelの精度を 著作された/計算された ように尊守するべきである。 これが可能でない場合、~channelは利用される最高~精度で最も近い値に( 2 数に等しく近い場合は高い方に)丸められるべきである。 ◎ The first three arguments specify the 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. A <number> is equivalent to a <percentage>, but with a different range: 0 again represents the minimum value for the color channel, but 255 represents the maximum. These values come from the fact that many graphics engines store 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 to the closest value at the highest precision used, rounding up if two values are equally close.
~~最後の引数の `alpha-value$t は、色の~alphaを指定する。 `number$t 値の有用な範囲は、 `0^v (全に透明な色を表現する) 〜 `1^v (全に不透明な色を表現する)である。 `percentage$t 値の範囲は、 `0%^v (全に透明な色を表現する) 〜 `100%^v (全に不透明な色を表現する)である。 省略-時の既定は `100%^v になる。 ◎ The final argument, the <alpha-value>, specifies the alpha of the color. If given as a <number>, the useful range of the value is 0 (representing a fully transparent color) to 1 (representing a fully opaque color). If given as a <percentage>, 0% represents a fully transparent color, while 100% represents a fully opaque color. If omitted, it defaults to 100%.
これらの範囲~外の値も無効ではないが、算出値の時点で ここで定義した範囲に切詰められる。 ◎ Values outside these ranges are not invalid, but are clamped to the ranges defined here at computed-value time.
旧来の理由から、 `rgb$f は,すべての引数を~commaで区切る代替~構文も~supportする: ◎ For legacy reasons, rgb() also supports an alternate syntax that separates all of its arguments with commas:
`rgb$f = rgb( `percentage$t#{3} , `alpha-value$t? ) | rgb( `number$t#{3} , `alpha-value$t? )
同じく旧来の理由から、 `rgba@f 関数も存在し, `rgb$f と同じ文法と挙動を備える。 ◎ Also for legacy reasons, an rgba() function also exists, with an identical grammar and behavior to rgb().
5.2. RGB ~hex~記法: `#RRGGBB^v
~CSSの `~hex色@ 記法により、各~channelに~hex~数を与えて色を指定できるようになる。 それは、~computer~codeで色を直に与えるときによくある書き方に類似する。 また、 `rgb$f 記法より短く書ける。 ◎ The CSS hex color notation allows a 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 は、 `rgb(0 255 0)^fv と同じ色(~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 は, `rgb(0 0 100% / 80%)^fv と同じ色(少しばかり透明な~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^v による表記と同じ色を指定する。 この手法は、 6 桁~記法より “解像度” が低い。 3 桁の~hex構文では 4096 色しか表せない一方で, 6 桁の~hex構文では およそ 17 百万~色が可能になる。 ◎ 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. 有名~色
`color$t に対する種々の数量~構文に加え、~CSSでは,代わりに利用できる 長大な `有名~色@ の集合 — `named-color@t — も定義する。 これらにより、共通的な色をより容易く書いたり読んだりできるようになる。 `named-color$t は、 `ident$t として記され, `color$t が受容される所ならどこでも利用できる。 ~CSSにより定義される通例の `ident$t と同様に、これらの~keywordは,すべて文字大小無視である。 ◎ In addition to the various numeric syntaxes for <color>s, CSS defines a large set of named colors that can be used instead, 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 case-insensitive.
~CSSの有名~色のうち 16 色は、元々は~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 。 残りの大部分は、 Unix 系の~systemで~consoleの色を指定するときに利用されている X11 色~systemのある~versionに由来する。 ( 2 つの特別な色~値 `transparent$v と `currentcolor$v は、それ専用の節にて特別に定義される。) ◎ 16 of CSS’s named colors come from HTML originally: aqua, black, blue, fuchsia, gray, green, lime, maroon, navy, olive, purple, red, silver, teal, white, and yellow. Most of the rest come from one version of the X11 color system, used in Unix-derived systems to specify colors for the console. (Two special color values, transparent and currentcolor, are specially defined in their own sections.)
注記: X11 色~systemの歴史は興味深く, Alex Sexton 氏による優れた公演 “Peachpuffs and Lemonchiffons” に要約されている。 ◎ Note: The history of the X11 color system is interesting, and was excellently summarized by Alex Sexton in his talk “Peachpuffs and Lemonchiffons”.
次の一覧に、定義される すべての(不透明な)有名~色を挙げる: ◎ The following table defines all of the opaque named colors, by giving equivalent numeric specifications in the other color syntaxes.
~style | 色~名 | 値 | ||
---|---|---|---|---|
色~名 | ~hex | #RRGGBB | 10 進 R, G, B |
注記: この色の~listとそれらの定義は、 SVG 1.1 にて定義される 有名~色 ~listの上位集合である。 【 SVG 1.1 に無い色~名は `rebeccapurple$v のみ。】 ◎ 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.
6.1. `transparent^v ~keyword
~keyword `transparent@v は、`透明な黒$を指定する。 これは、 `named-color$t の一種である。 ◎ The keyword transparent specifies a transparent black. It is a type of <named-color>.
6.2. `currentcolor^v ~keyword
~keyword `currentcolor@v は、同じ要素~上の `color$p ~propの値を表現する。 その算出値と使用値は、`色~値の解決-法$により決定される。 ◎ The keyword currentcolor represents value of the color property on the same element. Its computed value and used values are determined by resolving color values.
`currentcolor$v ~keywordの用法を示す単純な例をここに示す: ◎ Here’s a simple example showing how to use the currentcolor keyword:
.foo { color: red; background-color: currentcolor; }
これは、次の様に書くことに等価になる: ◎ This is equivalent to writing:
.foo { color: red; background-color: 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.
<p><em>ある<strong>本当に</strong>強勢された~text。</em> <style> p { color: black; } em { text-emphasis: dot; } strong { color: red; } </style>
上の例における `em^e の内容のうち,~text[ "ある" , "強勢された~text" ]は~blackになるが、 ~text "本当に" は~redになる。 ◎ In the above example, the emphasis marks would be black over the text "Some" and "emphasized text", but red over the text "really".
注記: ~CSSにおける,複数の単語からなる~keywordは、通例的に,その各~成分~単語を~hyphenで区切るが、 `currentcolor$v はそうでない — 元々は、~CSS値としてではなく SVG にて "currentColor" と綴られる特別な属性~値として導入されたので。 後に~CSSがそれを選出した時点で、~~大文字化は~~意味を為さなくなった — CSS ~keywordは文字大小無視なので。 ◎ Note: Multi-word keywords in CSS usually separate their component words with hyphens. currentcolor doesn’t, because it was originally introduced in SVG as a special attribute value spelled "currentColor", rather than a CSS value. Only later did CSS pick it up, at which point the capitalization stopped mattering, as CSS keywords are 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.
可能な色~体系は他にもいくつかある。 そのような一つは ~HSLによる色~体系であり、ずっと直感的に利用でき,かつ ~RGB色に対応付けるのも容易である。 ◎ There are several other color schemes possible. One such is the HSL color scheme, which is much more intuitive to use, but still maps easily back to RGB colors.
~HSL色は、[ 色相, 彩度, 明度 ( = Hue, Saturation, Lightness ) ]からなる三組で指定される。 `hsl$f 関数の構文は次で与えられる: ◎ HSL colors are specified as a triplet of hue, saturation, and lightness. The syntax of the hsl() function is:
`hsl@f = hsl( `hue$t `percentage$t `percentage$t [ / `alpha-value$t ]? ) `hue@t = `number$t | `angle$t
1 個目の引数は、色相を指定する。 色相は、 `色相環^_ における角度として表現される。 角度 `0deg^v は ~redを表現し( `360deg^v , `720deg^v, 等々も同様)、他の色相は,それを~~起点に環の周に~~分布する — 例えば `120deg^v は~green, `240deg^v は~blue を表現する,等々。 この値は, `deg^css 単位(度(°), degree )で与えられることが多いので、単位なしの数として与えることもでき, `deg^css 単位として解釈される。 ◎ The first argument specifies the hue. Hue is represented as an angle of the color circle (the rainbow, twisted around into a circle). The angle 0deg represents red (as does 360deg, 720deg, etc.), and the rest of the hues are spread around the circle, so 120deg represents green, 240deg represents blue, etc. 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.
2 個目の引数は、彩度を指定する。 彩度に対する `100%^v は 最大彩度の鮮明な色であり, `0%^v は 彩度なしにされた~grayである。 3 個目の引数は、明度を指定する。 明度に対する `50%^v は “通常の” 色を表現する一方で `100%^v は ~white, `0%^v は ~blackを表現する。 [ `0%^v 〜 `100%^v ]の範囲~外の明度/彩度は、~RGB色に変換される前に切取られる。 ◎ The next two arguments are the saturation and lightness, respectively. For saturation, 100% is a fully-saturated, bright color, and 0% is a fully-unsaturated gray. For lightness, 50% represents the "normal" color, while 100% is white and 0% is black. If the saturation or lightness are less than 0% or greater than 100%, they are clipped to those values before being converted to an RGB color.
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%.
例えば、[ ~keyword `red$v / ~hex記法 `#f00^v ]と同じ色を表す普通の~redは,~HSLにおいては `hsl(0, 100%, 50%)^fv で表現される。 ◎ 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に対する利点は、ずっと直感的なことにある — 求める色を推測しながら調節できるほどに。 また、調和する色~一式を作成するのもより容易になる(色相を同じに保ちつつ,彩度や明度を変えることにより)。 ◎ The advantage of HSL over RGB is that it is far more intuitive: one can guess at the colors they want, and then tweak. It is also easier to create sets of matching colors (by keeping the hue the same and varying the saturation and lightness).
例えば、次のどの色も,単に他の 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%) lime green hsl(120deg 100% 25%) dark green hsl(120deg 100% 75%) light green hsl(120deg 75% 85%) pastel green
旧来の理由から、 `hsl$f は,すべての引数を~commaで区切る代替~構文も~supportする: ◎ For legacy reasons, hsl() also supports an alternate syntax that separates all of its arguments with commas:
`hsl$f = hsl( `hue$t, `percentage$t, `percentage$t, `alpha-value$t? )
同じく旧来の理由から、 `hsla@f 関数も存在し, `hsl$f と同じ文法と挙動を備える。 ◎ Also for legacy reasons, an hsla() function also exists, with an identical grammar and behavior to hsl().
7.1. ~HSL色から RGB 色への変換-法
~HSL色から RGB 色への変換-法は、数学的に簡単に行える。 ここに,~JSによる変換~algoの単純な実装を与える。 ~~簡潔にするため、~algoでは, 色相( %hue )は 半開区間 [0, 6) 内の数に正規化されていて,彩度( %sat )と明度( %light )は 範囲 0 〜 1 に正規化されているとする。 これは、範囲 0 〜 1 に正規化された[ 色の[ ~red, ~green, ~blue ]~channelを表現する 3 個の数 ]からなる配列を返す。 ◎ Converting an HSL color to RGB is straightforward mathematically. Here’s a simple implementation of the conversion algorithm in JavaScript. For simplicity, this algorithm assumes that the hue has been normalized to a number in the half-open range [0, 6), and the saturation and lightness have been normalized to the range [0, 1]. It returns an array of three numbers representing the red, green, and blue channels of the colors, normalized to the range [0, 1].
function hslToRgb(%hue, %sat, %light) { if( %light <= .5 ) { var %t2 = %light * (%sat + 1); } else { var %t2 = %light + %sat - (%light * %sat); } var %t1 = %light * 2 - %t2; var %r = hueToRgb(%t1, %t2, %hue + 2); var %g = hueToRgb(%t1, %t2, %hue); var %b = hueToRgb(%t1, %t2, %hue - 2); return [%r,%g,%b]; } function hueToRgb(%t1, %t2, %hue) { if(%hue < 0) %hue += 6; if(%hue >= 6) %hue -= 6; if(%hue < 1) return (%t2 - %t1) * %hue + %t1; else if(%hue < 3) return %t2; else if(%hue < 4) return (%t2 - %t1) * (4 - %hue) + %t1; else return %t1; }
7.2. ~HSL色の例
【 この訳では、原文の[ 30°ごとの間隔で選択された各~色相による一連の~HSL色の表 ]ではなく,任意の色相から~scriptにより生成して表すことにする。 また、次節の~HWB色の例も同時に示す。 ( Canvas API を~supportしない/対応が古い~browserでは~~機能しない。) 】 ◎ 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.
下の図に、特定0の色相の下で表現し得る, HSL 色と次節の HWB 色を順に示す。 色相はスライダで調節できる。 HSL 色の彩度は下方向に, 明度は右方向に増大し, HWB 色の白味は下方向に, 黒味は右方向に増大する。
8. ~HWB色: `hwb^f 関数
~HWB( Hue-Whiteness-Blackness の略称)は、色を指定する別の手法であり,~HSLに類似するが、人にとって更に使い易いことが多い。 それは、色を,基底となる色相を与える色と, その色に混合される白味と黒味の度合いで述べる。 ◎ HWB (short for Hue-Whiteness-Blackness) is another method of specifying 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.
~color-pickerは、その直感性に因り~HWB色~systemに基づいているものが多い。 ◎ Many color-pickers are based on the HWB color system, due to its intuitiveness.
`hwb$f 関数の構文は次で与えられる: ◎ The syntax of the hwb() function is:
`hwb@f = hwb( `hue$t `percentage$t `percentage$t [ / `alpha-value$t ]? )
1 個目の引数は色相を指定し, `hsl$f と~~同じに解釈される。 ◎ The first argument specifies the hue, and is interpreted identically to hsl().
2 個目の引数は、白味の度合いを表す範囲 `0%^v 〜 `100%^v の百分率として,混合する~whiteの量を指定する。 同様に, 3 個目の引数も、黒味の度合いを表す範囲 `0%^v 〜 `100%^v の百分率として,混合する~blackの量を指定する。 範囲~外の値は、関数を無効にする。 この 2 つの引数の和が 100% より大きい場合、算出値の時点で それらの引数は 2 つの和が 100% になるように同じ比率で正規化される。 ◎ 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). Values outside of these ranges make the function invalid. If the sum of these two arguments is greater than 100%, then at computed-value time they are normalized to add up to 100%, with the same relative ratio.
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%.
結果の色は、概念的には,選ばれた色相を塗ってから, 百分率で決定される相対~量により~whiteを塗って, ~black塗った混合と捉えることができる。 ~whiteと~blackの和が(正規化-後に) `100%^v に等しいならば、`無彩色$ すなわち ある~grayの濃淡を定義することになる。 ◎ 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. If white+black is equal to 100% (after normalization), it defines an achromatic color, or some shade of gray, without any hint of the chosen hue.
8.1. ~HWB色から~RGB色への変換-法
~HWB色から~RGB色への変換-法は、簡単であり, ~HSLから~RGBへ変換する方法に関係する。 ~algoは次の~JS実装で与えられる — ~whiteと~black成分は,予め その和が 100% 以下に正規化された上で,範囲 0 〜 1 に変換されているとする。 ◎ Converting an HWB color to RGB is straightforward, and related to how one converts HSL to RGB. The following Javascript implementation of the algorithm assumes that the white and black components have already been normalized, so their sum is no larger than 100%, and have been converted into numbers in the range [0,1].
function hwbToRgb(%hue, %white, %black) { var %rgb = hslToRgb(%hue, 1, .5); for(var %i = 0; %i < 3; %i++) { rgb[%i] *= (1 - %white - %black); rgb[%i] += %white; } return %rgb; }
8.2. ~HWB色の例
【 この節の内容は ~HSL色の例 節に委譲。 】
9. 機器に依存しない色: ~Labと~LCH
色の物理的~計測は,概して、 1976 年に CIE により創出された ~Lab色~空間として表される。 ある機器から別の機器への色~変換でも,その中間段階に~Labが利用される。 ~Labは人の視覚経験から導出されており,人が見れる色の全~範囲を表現する。 ◎ Physical measurements of a color are typically expressed as the Lab color space, created in 1976 by the CIE. Color conversions from one device to another 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=0 は漆黒(明るさ皆無), L=100 は~white( ~D50 ~white — 標準~化された色~温度 5000K による日光の波長分布)を表す。 有用にするため, L=50 が真中の~grayになるように設計されている — ~Lab色~空間は,知覚的に一様 になる†ように意図されている。 a, b 軸は色相~情報を与える。 a 軸における正の値は~redになる一方, 負の値は補色の~greenになる。 同様に, b 軸における正の値は~yellowになる一方, 負の値は補色である紫になる。 彩度の低い色の a, b 値は小さくなる — すなわち、彩度を落とせば L 軸 に近づき,彩度を上げれば L 軸から離れる。 ◎ Lab is a rectangular coordinate system with a central Lightness axis. L=0 is deep black (no light at all) while L=100 is white (D50 white, a standardized daylight spectrum with a color temperature of 5000K). Usefully, L=50 is mid gray, by design: the Lab color space is intended to be perceptually uniform. The a and b axes convey hue; positive values along the a axis are red while negative values are the complementary color, 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はまた、 ICC 色~間の変換における~profile接続~空間( profile connection space, 略称 PCS )の白色点†として利用される。 これは、~Lab編集を提供する画像~editorや, 分光計などの物理的~計測~機器が,計測された色を~Labで報告するときに利用される値である。 他の白色点を利用して指定された色からの変換††は,有彩色~順応~変形( chromatic adaptation transform )と呼ばれ、新たな光環境に人が順応するときの,人の視覚~systemにおける変化を~modelにしている。 ~Bradford~algoは,有彩色~順応~変形の工業規格であり、単純な行列の乗算により,容易に計算できる。 ◎ D50 is also the whitepoint used for the profile connection space in ICC color interconversion, the values used in image editors which offer Lab editing, and the value used by physical measurement devices such as spectrometers, when they report measured colors in Lab. 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 Bradford algorithm is the industry standard chromatic adaptation transform, and is easy to calculate as it is a simple matrix multiplication.
【† 白色点 — 光源が損失なく感知されるときの,光源の波長分布と強さを表現する色(光源で “真白な紙” を照らしたときに見える色)。 】【†† 白色点が異なる光源の下で撮影された画像の色を,~D50( “~~標準の光源” )の下で撮影されたかのように補正することを意味すると思われる( 参考 )。 】
~Labでは、2 つの色は,視覚的に同じ明度であれば、色相にかかわらず,同じ L 値になり、この点で~HSLと異なる。 例えば,~yellow( `#FF0^v )は ~blue( `#00F^v )より明らかに~~明るいが、これらの~HSL明度は,同じになる。 ◎ In Lab if two colors have the same L value, they appear to have the same visual lightness—regardless of how different their hues are. This is different from HSL, where for example blue (#00F) and yellow (#FF0) have the same HSL lightness despite yellow being obviously far lighter than blue.
~LCHは、~Labと同じ L 軸を利用しつつ,極座標 ( C, H ) ( = ( Chroma, Hue ) = ( 純色度, 彩度 ) )を利用する。 C は L 軸からの距離であり, H は a 軸~正~~方向から時計回りの角度( ° )である。 ◎ LCH has the same L axis as Lab, but uses polar coordinates C (chroma) and H (hue). C is the geometric distance from the L axis and H is the angle from the positive a axis, with positive angles being more clockwise.
注記: ~Labにおける明度~軸と~HSLにおける L 軸とを混同すべきでない。 例えば~HSLにおいては、~sRGB色~blue( `#00F^v )は視覚的には~yellow( `#FF0^v )よりずっと暗くなるが,それらの L 値は同じになる。 ~Labにおいては、同じ L 値に計測される 2 つの色の視覚的~明度は一致する。 ~HSL, および関係する極座標~RGB~modelは, ~LCHが~Labにもたらしたものに類似する便益を,~RGBにももたらすために開発された。 ◎ Note: The Lightness axis in Lab should not 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 even though visually, blue is much darker. In Lab, if two colors have the same measured L value, they have identical visual lightness. HSL and related polar RGB models were developed to give similar usability benefits for RGB that LCH gave to Lab.
9.1. ~Lab, ~LCH の指定-法: `lab^f, `lch^f 関数記法
~CSSでは、~Lab/~LCHで直に色を表せる: ◎ CSS allows colors to be directly expressed in Lab and LCH.
`lab@f = lab( `number$t `number$t `number$t [ / `alpha-value$t]?)
最初の引数は、 CIE 明度( “L” )を指定する。 これは概して、 `hsl$f の明度~引数と同様に, (~blackを表現する) `0^v 〜 (~whiteを表現する) `100^v に入る数である。 しかしながら,~systemによっては、 CIE 明度は,この範囲を超過し得る — `400^v までの明度を利用した余分に鮮明な~whiteで。 ◎ The first argument specifies the CIE Lightness. This is typically a number between 0 (representing black) and 100 (representing white), similar to the lightness argument of hsl(). However, CIE Lightness can exceed this range on some systems, with extra-bright whites using a lightness up to 400.
2 個目, 3 個目の引数( “a”, “b” )は、前節に述べたように,順に ~Lab色空間における a 軸, b 軸~~方向の距離を与える。 これらの値は、有符号であり,理論的には上限も下限もない(が、実施においては, ±160 を超過しない)。 ◎ The second and third arguments are the distances along the "a" and "b" axises in the Lab colorspace, 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値もとれ、 `rgb$f における `alpha-value$t と同じに解釈される。 ◎ There is an optional fourth alpha value, separated by a slash, and interpreted identically to the <alpha-value> in rgb().
`lch@f = lch( `number$t `number$t `hue$t [ / `alpha-value$t]?)
最初の引数は CIE 明度( “L” )を指定し, `lab$f のそれと同じに解釈される。 ◎ The first argument specifies the CIE Lightness, interpreted identically to the Lightness argument of lab().
2 個目の引数は色度( “C” )を与える(概ね, “色の含有量” を表現する)。 その有用な最小~値は `0^v である一方、その最大は理論的には上限も下限もない(が、実施においては, `230^v を超過しない)。 供された値が負の場合、 `0^v 以上に切上げられる。 ◎ The second argument is the chroma (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.
3 個目の引数は色相( “H” )を与え, `hsl$f の `hue$t 引数と同じように解釈されるが、角度への対応付けは同じでない — [ `0deg^v, `90deg^v, `180deg^v, `270deg^v ]は、順に[ ~red, ~yellow, ~green, ~blue ]を表現し,順に[ a 軸~正方向, b 軸~正方向, a 軸~負方向, b 軸~負方向 ]を指す。 ◎ The third argument is the hue. It’s interpreted identically to the <hue> argument of hsl(), but doesn’t map hues to angles in the same way. Instead, 0deg represents red (pointing along the positive "a" axis), 90deg represents yellow (the positive "b" axis), 180deg represents green (the negative "a" axis), and 270deg represents blue (the negative "b" axis).
任意選択で、 4 個目の引数として,~slashで区切った後に~alpha値もとれ、 `rgb$f における `alpha-value$t と同じに解釈される。 ◎ There is an optional fourth alpha value, separated by a slash, and interpreted identically to the <alpha-value> in rgb().
輝度の最大最小比が高いときにどうするか決める必要がある。 ◎ Need to decide what, if anything, to do for high dynamic range on luminance.
9.2. ~sRGB色から~Lab色への変換-法
~sRGBから~Labへの変換には、何~段か要する。 実施においては、最初の段を除くすべては,線形の計算であり 結合できるが: ◎ Conversion from sRGB to Lab requires several steps, although in practice all but the first step are linear calculations and can be combined.
- ~sRGBから線形明度~sRGBへ変換する(~gamma符号化を外す) ◎ Convert from sRGB to linear-light sRGB (undo gamma encoding)
- 線形~sRGBから CIE ~XYZへ変換する ◎ Convert from linear sRGB to CIE XYZ
- ~Bradford変形で, (~sRGBが利用する)~D65白色点から (~Labが利用する)~D50白色点へ変換する ◎ Convert from a D65 whitepoint (used by sRGB) to the D50 whitepoint used in Lab, with the Bradford transform
- ( ~D50に順応された)~XYZから~Labへ変換する ◎ Convert D50-adapted XYZ to Lab
`色~変換~codeの見本$ 節に、これらの変換を与える見本~JS~codeがある。 ◎ There is sample JavaScript code for this conversion in §17 Sample code for color conversions.
9.3. ~Lab色から~sRGB色への変換-法
~Labから~sRGBへの変換には、何~段か要する。 実施においては、最後の段を除くすべては,線形の計算であり 結合できるが: ◎ Conversion from Lab to sRGB also requires multiple steps, and again in practice all but the last step are linear calculations and can be combined.
- ~Labから( ~D50に順応された)~XYZへ変換する ◎ Convert Lab to (D50-adapted) XYZ
- ~Bradford変形で, (~Labが利用する)~D50白色点から (~sRGBが利用する)~D65白色点へ変換する ◎ Convert from a D50 whitepoint (used by Lab) to the D65 whitepoint used in sRGB, with the Bradford transform
- ( ~D65に順応された) CIE ~XYZから線形~sRGBへ変換する ◎ Convert from (D65-adapted) CIE XYZ to linear sRGB
- 線形明度~sRGBから~sRGBへ変換する(~gamma符号化を施す) ◎ Convert from linear-light sRGB to sRGB (do gamma encoding)
9.4. ~Lab色から~LCH色への変換-法
~LCHへの変換は自明である ⇒# %H ~SET atan2( %b, %a ), %C ~SET sqrt( %a ~MUL %b ~PLUS %b ~MUL %b ), %L はそのまま同じ ◎ Conversion to LCH is trivial: • H = atan2(b, a) • C = sqrt(a^2 + b^2) • L is the same
9.5. ~LCH色から~Lab色への変換-法
~Labへの変換は自明である ⇒# %a ~SET %C ~MUL cos( %H ), %b ~SET %C ~MUL sin( %H ), %L はそのまま同じ ◎ Conversion to Lab is trivial: • a = C cos(H) • b = C sin(H) • L is the same
10. ~grayの指定-法: `gray^f 関数記法
San Francisco 会合にて、この構文は,[ %a, %b とも 0 にされた Lab ]の別名とすることが決まった。 ◎ As decided at San Francisco, this syntax is an alias to Lab with a=b=0.
~grayは、彩度がない色の集合である。 `gray$f 関数記法は、単独の数量的な値のみが要求され, `gray(50)^v が視覚的に真中の~gray(知覚的に~blackと~whiteから等距離にある)になるように,この共通的な色の集合に対する指定-法を単純化する。 ◎ Grays are fully desaturated colors. The gray() functional notation simplifies specifying this common set of colors, so that only a single numerical parameter is required, and so that gray(50) is a visual mid-gray (perceptually equidistant between black and white).
`gray@f = gray( `number$t [ / `alpha-value$t]? )
1 個目の引数は、 CIE 明度に等しい~grayの濃淡を指定する。 省略可能な 2 個目の引数は、~grayの~alpha~channelを指定する。 ◎ The first argument specifies the shade of gray, equal to the CIE Lightness, while the second optional argument specifies the alpha channel of the gray.
注記:
言い換えれば、
gray(%L / %alpha)
は
lab(%L 0 0 / %alpha)
に等しい。
◎
Note: In other words, gray(a / b) is equal to lab(a 0 0 / b).
10.1. ~gray色から~sRGB色への変換-法
~grayから~sRGBへの変換には、何~段か要する。 実施においては、最後の段を除くすべては,線形の計算であり 結合できるが: ◎ Conversion from gray to sRGB requires multiple steps; in practice all but the last step are linear calculations and can be combined.
- ( L, a, b ) を順に ( ~gray値, 0, 0 ) に設定して,~Labへ変換する ◎ Convert to Lab by setting L to the gray value, a and b to 0
- ~Labから~XYZへ変換する ◎ Convert Lab to XYZ
- (~Bradford変形で)~D50から~D65に順応させる ◎ Adapt from D50 to D65 (Bradford transform)
- ( ~D65に順応された) CIE ~XYZから線形~sRGBへ変換する ◎ Convert from (D65-adapted) CIE XYZ to linear sRGB
- 線形明度~sRGBから~sRGBへ変換する(~gamma符号化を施す) ◎ Convert from linear-light sRGB to sRGB (do gamma encoding)
11. 機器に依存する,~profiled色
[ 色~空間/色を生産する機器 ]は、それに対し計測される物理的~特性(利用する原色の純色度( chromaticity )や,所与の入力の集合に呼応して生産される色など)が既知であるとき、 有特性 ( characterised )と称される。 この特性評価~情報は、 ~profile 内に格納される。 色~profileの最も共通的な型は、 ICC ( International Color Consortium ) `ICC$r により定義される。 ◎ 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 characterised. This characterization information is stored in a profile. The most common type of color profile is defined by the International Color Consortium (ICC) [ICC].
加えて、機器が[ 白色点, ~greyの中立度, 色調~応答の予測-能と一貫性 ]などの較正~対象に合わせて調整されている場合、それは 較正-済み( calibrated ) と呼ばれる。 ◎ 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.
~CSSでは、ある色~profileを基準に色を指定することも許容される。 これには例えば、[ 較正-済み~CMYK印刷機 / ~RGB色空間(写真家たちから広く利用されている ProPhoto など) / 他の任意の,有特性[ 色度有り( color ) / 色度無し( monochrome ) ]の出力~機器 ]などもあり得る。 加えて,便宜のため、~CSSでは,次の 2 つの定義済み~RGB色~空間が供される:
- `image-p3$v `DCI-P3$r — 現在の広 色域~monitorに典型的な,広 色域~空間。
- `rec2020$v `Rec.2020$r — 現実のほぼすべての可視~色を表現できる超広 色域~空間。
いずれも~~普及している工業規格である。
◎ CSS allows colors to be specified by reference to a color profile. This could be for example a calibrated CMYK printer, or an RGB colorspace (such as ProPhoto , widely used by photographers), or any other color or monochrome output device which has been characterized. In addition, for convenience, CSS provides two predefined RGB color spaces: image-p3 [DCI-P3], which is a wide gamut space typical of current wide-gamut monitors, and Rec. 2020 [Rec.2020], which is a ultra-wide gamut space capable of representing almost all visible real-world colors. Both are broadcast industry standards.次の例は、順に[ 標準~CMYK刷版, ある広 色域の七色~ink印刷機, ProPhoto ~RGB, P3 標準~RGB空間 ]に対する~profiled色を指定する。 ◎ This example specifies four profiled colors: for a standard CMYK press, for a wide-gamut seven-ink printer, for ProPhoto RGB, and for the P3 standard RGB space.
color: color(swopc 0 206 190 77); color: color(indigo 24 160 86 42 0 18 31); color: color(prophoto 233 150 122); color: color(image-p3 97 253 36);
この例のうち定義済み色空間( `image-p3$v )を除くすべては、名前と~profile~dataを接続するため、~stylesheet内のどこかに,合致する `color-profile$at at-規則も必要とする: ◎ All but the predefined colorspace example also need a matching @color-profile at-rule somewhere in the stylesheet, to connect the name with the profile data.
@color-profile swopc { src: url('http://example.org/swop-coated.icc');} @color-profile indigo { src: url('http://example.org/indigo-seven.icc');} @color-profile prophoto { src: url('http://example.org/prophoto.icc');}
San Francisco 会合にて、 `color$f ~fallbackは,~font~list~fallbackと同様になるべきと決まった。 Recursive? ◎ color() fallback should be like font list fallback, as decided at San Francisco. Recursive?
11.1. ~profiled色の指定-法: `color^f 関数
`color$f 関数により、特定0の色~空間~内の色を指定できるようになる(他の色~関数が暗黙の~sRGB色~空間の中で演算するのとは~~対照的に)。 その構文は: ◎ The color() function allows a color to be specified in a particular colorspace (rather than the implicit sRGB colorspace that the other color functions operate in). Its syntax is:
`color@f = color( [ `ident$t? [ `number$t+ | `string$t ] [ / `alpha-value$t ]? ]# , `color$t? )
この色~関数は、~commaで区切られた 1 個~以上の引数をとる — 各 引数は, 1 個の色を指定し、後に現れる色は,先に現れる色が表示できないときには(例えば,それが指定する色~空間はまだ読込まれていない), “~fallback” として動作する。 ◎ The color function takes one or more comma-separated arguments, with each argument specifying a color, and later colors acting as "fallback" if an earlier color can’t be displayed (for example, if the colorspace it specifies hasn’t been loaded yet).
各 引数は、次の形をとる: ◎ Each argument has the following form:
-
任意選択の `ident$t は、色~空間を表す。 とり得る値は、定義済みのそれ( `image-p3$v など)か, `color-profile$at 規則により定義されるそれのいずれか。 省略-時の既定は、定義済み色~profile `srgb$v になる。 ◎ An optional <ident> denoting the colorspace. This can be one of the predefined colorspaces (such as image-p3), or one defined by a @color-profile rule. If omitted, it defaults to the predefined srgb color profile.
`ident$t が与える名前が,存在しない色~空間を指す場合、この引数は,`無効な色$を表現する。 ◎ If the <ident> names a non-existent colorspace, this argument represents an invalid color.
-
次のいずれか: ◎ Either one or more <number>s providing the parameter values that the colorspace takes, or a <string> giving the name of a color defined by the colorspace.
- 色~空間がとり得る一連の数量~parameterを与える, 1 個~以上の `number$t 値: ◎ If the colorspace takes numeric parameters
- 供された `number$t の個数が多過ぎる場合、末尾側の超過分の `number$t は無視される。 ◎ If more <number>s are provided than parameters that the colorspace takes, the excess <number>s at the end are ignored.
- 供された `number$t の個数が足りない場合、足りない~parameterは,既定で `0^v にされる(これは特に、複~channel印刷機において,追加の~inkは~spot色か上塗り用で,ほとんどの色には利用されない場合に~~便利になる)。 ◎ If less <number>s are provided than parameters that the colorspace takes, the missing parameters default to 0. (This is particularly convenient for multichannel printers where the additional inks are spot colors or varnishes that most colors on the page won’t use.)
- `string$t も供されている場合、この引数は `無効な色$を表現する。 ◎ If a <string> is provided, this argument represents an invalid color.
- 色~空間が定義する色~名を与える, 1 個の `string$t 値: ◎ If the colorspace defines named colors
- 色~空間が定義する どの色~名にも合致しない `string$t が供された場合、この引数は `無効な色$を表現する。 ◎ If <number>s are provided, or a <string> is provided that doesn’t match any of the color names defined by the colorspace, this argument represents an invalid color.
- `number$t も供されている場合、この引数は `無効な色$を表現する。 ◎ ↑
-
任意選択で、~slashで区切った後に `alpha-value$t 。 これは、 `rgb$f 内の `alpha-value$t と同じ仕方で解釈される。 省略-時の既定は `100%^v になる。 ◎ An optional slash-separated <alpha-value>. This is interpreted the same way as the <alpha-value> in rgb(), and if omitted it defaults to 100%.
上の形による 1 個~以上の引数の後、~~最後に,~CSS色~構文を利用する `color$t 引数を供せる。 ◎ After one or more arguments of the above form, a final <color> argument using any CSS color syntax can be provided.
`color$f 関数は、 `妥当な色@ (すなわち, `無効な色@ でない色)を表現する引数のうち,最初のものが指定する色を表現する。 すべての引数が`無効な色$を表現する場合、 `color$f は`不透明な黒$を表現する。 ◎ The color() function represents the color specified by the first of its arguments that represent a valid color (that is, the first argument that isn’t an invalid color). If all of its arguments represent invalid colors, color() represents opaque black.
11.2. 定義済み色空間: `srgb^v, `image-p3^v, `rec2020^v
`color$f 関数~用として定義済みの色~空間を,以下に挙げる。 これらは、 `color-profile$at 規則なしに利用できる。 ◎ The following colorspaces are predefined for use in the color() function. They can be used without any @color-profile rule.
San Francisco 会合にて, AdobeRGB, ProPhoto RGB, 等々の様な,共通的な定義済み空間の,より大きな集合を追加することが決まった。 coated swop, uncoated swop などなども。 ◎ Decided at San Francisco to add a larger set of common predefined spaces like AdobeRGB, ProPhoto RGB, and so on. Also coated and uncoated swop, etc, etc.
- `srgb@v
- `srgb^v 色空間 `SRGB$r は、色の[ ~red, ~green, ~blue ]~channelを表現する, 3 個の数量~parameterを受容する。 これらの妥当な範囲は 0 〜 1 である。 ◎ The srgb [SRGB] colorspace accepts three numeric parameters, representing the red, green, and blue channels of the color, with each having a valid range of [0, 1].
- これは~CSSにおける既定の色空間であり、 `rgb$f 関数で色を指定することに一致する。 ◎ It is the default colorspace for CSS, identical to specifying a color with the rgb() function.
-
この色空間は、次の特性を備える: ◎ It has the following characteristics:
x y ~red純色度 0.640 0.330 ~green純色度 0.300 0.600 ~blue純色度 0.150 0.060 ~white純色度 0.3127 0.3290 伝達関数 下を見よ %C は[ ~red/~green/~blue ]成分とするとき、次の %Cl で与えられる:
var %Cl; if (%C <= 0.04045) %Cl = %C / 12.92; else %Cl = Math.pow((%C + 0.055) / 1.055, 2.4);
- `image-p3@v
- `image-p3^v 色空間 `DCI-P3$r は、色の[ ~red, ~green, ~blue ]~channelを表現する, 3 個の数量~parameterを受容する。 これらの妥当な範囲は 0 〜 1 である。 ◎ The image-p3 [DCI-P3] colorspace accepts three numeric parameters, representing the red, green, and blue channels of the color, with each having a valid range of [0, 1].
-
この色空間は、次の特性を備える: ◎ It has the following characteristics:
x y ~red純色度 0.680 0.320 ~green純色度 0.265 0.690 ~blue純色度 0.150 0.060 ~white純色度 0.3127 0.3290 伝達関数 `srgb$v と同じ - `rec2020@v
- `rec2020^v 色空間 `Rec.2020$r は、色の[ ~red, ~green, ~blue ]~channelを表現する, 3 個の数量~parameterを受容する。 これらの妥当な範囲は 0 〜 1 である。 ◎ The rec2020 [Rec.2020] colorspace accepts three numeric parameters, representing the red, green, and blue channels of the color, with each having a valid range of [0, 1].
-
この色空間は、次の特性を備える: ◎ It has the following characteristics:
x y ~red純色度 0.708 0.292 ~green純色度 0.170 0.797 ~blue純色度 0.131 0.046 ~white純色度 0.3127 0.3290 ( ~D65 ) 伝達関数 1/2.4 (注記を見よ) 注記: Rec2020 は、~cameraに対しては,異なる伝達-曲線を基準にする。 しかしながら、この曲線が製品の~cameraや 2020 ~displayに利用されることは決してない。 ◎ Note: Rec2020 references a different transfer curve for cameras. However this curve is never used in production cameras or 2020 displays.
“代表的な製品~実施においては,画像~sourceの符号化~関数は、[ Recommendation ITU-R BT.2035 に定義される基準~視認~環境 ]において[[ Recommendation ITU-R BT.1886 の基準~復号~関数 ]を備える基準~monitor ]で見たときの最終的な絵が欲される見かけになるよう調整される。” ◎ "In typical production practice the encoding function of image sources is adjusted so that the final picture has the desired look, as viewed on a reference monitor having the reference decoding function of Recommendation ITU-R BT.1886, in the reference viewing environment defined in Recommendation ITU-R BT.2035."
基準 Rec.2020 ~displayに対する伝達関数( 1886 )の~gammaは 2.4 である。 `Rec.2020$r ◎ The transfer function (1886) for reference Rec.2020 displays is gamma 2.4 [Rec.2020]
11.2.1. 定義済み色空間から~Labへの変換-法
いずれの定義済み色~空間とも、~Labへの変換には,何~段か要する。 実施においては、最初の段を除くすべては,線形の計算であり 結合できるが: ◎ For both predefined 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-corrected RGB to linear-light RGB (undo gamma encoding)
- 線形~RGBから CIE ~XYZへ変換する ◎ Convert from linear RGB to CIE XYZ
- ~Bradford変形で, ( `image-p3$v / `rec2020$v で利用される)~D65白色点から (~Labが利用する)~D50白色点へ変換する ◎ Convert from a D65 whitepoint (used by both image-p3 and rec2020) to the D50 whitepoint used in Lab, with the Bradford transform
- ( ~D50に順応された)~XYZから~Labへ変換する ◎ Convert D50-adapted XYZ to Lab
`Canvas^c 【おそらく, ~HTML Canvas API 】 では, 16bit half-float 線形 `rec2020$v 空間の追加が提案されている。 ◎ Canvas proposes adding a 16bit half-float linear rec2020 space
11.2.2. ~Labから定義済み色空間への変換-法
~Labから[ `image-p3$v / `rec2020$v ]への変換もまた、何~段か要する。 これも,実施においては、最後の段を除くすべては,線形の計算であり 結合できるが: ◎ Conversion from Lab to image-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が利用する)~D65白色点へ変換する ◎ Convert from a D50 whitepoint (used by Lab) to the D65 whitepoint used in sRGB, with the 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)
実装は、変換元/変換先の色域~内の色に対し,同じ結果が得られる限り、他の仕方でこの手続きを実装してもよい(例えば、`描画意図$に `relative-colorimetric$v を伴うような, 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 the source and destination gamuts.
11.3. 色~profileの指定-法:`color-profile^at at-規則
`color-profile@at 規則は、 `色~profile@ を定義し,それに名前を与える。 後で `color$f 関数にて色を指定するときに,その名前を利用できる。 その構文は、次で定義される: ◎ The @color-profile rule defines and names a color profile which can later be used in the color() function to specify a color. It’s defined as:
@color-profile = @color-profile `custom-ident$t { `declaration-list$t }
`custom-ident$t が`色~profile$の名前を与える。 この `custom-ident$t からは、定義済み色空間~keyword[ `srgb$v, `image-p3$v, `rec2020$v ]は除外される。 それらは、この仕様にて定義済みであり,常に可用である。 ◎ The <custom-ident> gives the color profile’s name. All of the predefined colorspace keywords (srgb, image-p3, rec2020) are excluded from this <custom-ident>, as they’re predefined by this specification and always available.
`color-profile$at 規則は、この仕様に定義される記述子を受容する。 ◎ The @color-profile rule accepts the descriptors defined in this specification.
◎述 `src@d ◎用 `color-profile$at ◎値 `url$t ◎初 n/a ◎表終`src$d 記述子は、色~profile情報の~~取得先~URLを指定する。 ◎ The src descriptor specifies the URL to retrieve the color-profile information from.
`src^d に対する同一生成元と CORS に関する取扱い。 ◎ Same-origin and CORS for src.
局所的に~installされた~profileを利用する `local^f 関数。 単独の url でなく, `font-face^at の `src^d の様に,~profile名を連ねられるようにする。 未較正の色による明滅を避けるために。 ◎ local() to use locally installed profiles. Profile stack like font-face rather than a single url. Avoid flash of uncalibrated color.
◎述 `rendering-intent@d ◎用 `color-profile$at ◎値 `relative-colorimetric$v | `absolute-colorimetric$v | `perceptual$v | `saturation$v ◎初 `relative-colorimetric$v ◎表終`色~profile$は、 `描画意図@ を包含する。 それは、色を それを定義していた色域より狭い色域へ対応付ける方法を定義する。 ~profileが描画意図を一つだけ包含する場合が多いが、複数ある場合は, `rendering-intent$d 記述子を利用して いずれかを選べる。 ◎ Color profiles contain “rendering intents”, which define how to map their color to smaller gamuts than they’re defined over. Often a profile will contain only a single intent, but when there are multiple, the rendering-intent descriptor chooses one of them to use.
【 (色計量における)描画意図( ( colorimetric ) rendering intent ) — 色域が異なる機器で,色をどう再現するか(何を重視して再現するか)を表現する情報。 】
描画意図 `ICC$r には、次の 4 種がある: ◎ The four possible rendering intents are [ICC]:
- `relative-colorimetric@v 【 “相対~色計量” 】
- 色計量が媒体に相対的になることが要求される — すなわち,変換元の色は、変換先~媒体の色域においても,双方の媒体の白色点から相対的に変化しない。 変換先~媒体の色域~外になる変換元の色は、種々の手法を利用して,色域~境界の色に対応付けられる。 ◎ Media-relative colorimetric is required to leave source colors that fall inside the destination medium gamut unchanged relative to the respective media white points. Source colors that are out of the destination medium gamut are mapped to colors on the gamut boundary using a variety of different methods.
- 注記: この`描画意図$は、黒色点~補償 — 黒色点も,変換元~媒体から変換先~媒体に対応付ける — を伴って利用されることが多い。 この手法では、変換元の白色点は,変換先の白色点へ対応付けられ~MUST。 黒色点~補償も利用-中にある場合、変換元の黒色点も,変換先の黒色点に対応付けられ~MUST。 白色点の変化に対する調整には、順応~algoが利用されるべきである。 変換元の色のうち,変換先の色域~内に入る各~色に対しては、それらの相対的な関係性が保全されるべきである。 変換先の色域~外になる色については、相対的な関係性は変化し得る。 ◎ Note: the media-relative colorimetric rendering intent is often used with black point compensation, where the source medium black point is mapped to the destination medium black point as well. This method must map the source white point to the desination white point. If black point compensation is in use, the source black point must also be mapped to the destination black point. Adaptation algorithms should be used to adjust for the change in white point. Relative relationships of colors inside both source and destination gamuts should be preserved. Relative relationships of colors outside the destination gamut may be changed.
- 【 黒色点~補償( black point compensation ) — 大雑把に言えば、黒のつぶれも回避するように変換することに思われる。 】
- `absolute-colorimetric@v 【 “絶対~色計量” 】
- 色計量が ICC 色に関して絶対的になることが要求される — すなわち、変換元の色のうち,変換先~媒体の色域~内に入るものは、順応された~white(光源を全反射する色)から相対的に変化しない。 変換元の色のうち,変換先~媒体の色域~外になるものは、種々の手法を利用して,色域~境界の色に対応付けられる。 この手法は、色域~内の色については,最も正確aに合致する色を生産するが、変換先~媒体の白色点が変換元~媒体の白色点より~~暗い場合、高明度~付近がつぶれる結果になる。 この理由から、色を正確に合致させる必要はあるが,高明度~付近のつぶれは懸念されないような応用に限って利用することが推奨される。 ◎ ICC-absolute colorimetric is required to leave source colors that fall inside the destination medium gamut unchanged relative to the adopted white (a perfect reflecting diffuser). Source colors that are out of the destination medium gamut are mapped to colors on the gamut boundary using a variety of different methods. This method produces the most accurate color matching of in-gamut colors, but will result in highlight clipping if the destination medium white point is lower than the source medium white point. For this reason it is recommended for use only in applications that need exact color matching and where highlight clipping is not a concern.
- この手法は、色を変換する際には、白色点/黒色点の~~対応付けを不能化し~MUST。 一般に,この~optionは、試験~目的を除き,推奨されない。 ◎ This method MUST disable white point matching and black point matching when converting colors. In general, this option is not recommended except for testing purposes.
- `perceptual@v 【 “知覚~重視” 】
- この手法は、画像に選好されることが多い — とりわけ,変換元と変換先の間が相当に異なるときに(反射~印刷-面に再現される,~screen~display用の画像など)。 これは、~proprietary【すなわち,~UA特有の】手法を利用して,変換元の画像の色から変換先~媒体~用に,画像の外観を最適化し直す。 その結果、変換元の色は,変換先の色域に入る色でも変化し得る — 知覚的には、元の基本的な審美的意図を保守するように変形されて再現されることが想定されているが。 この手法は、変換元の画像~内の~errorを補正しようと試みることはない 【何の~error?】。 ◎ This method is often the preferred choice for images, especially when there are substantial differences between the source and destination (such as a screen display image reproduced on a reflection print). It takes the colors of the source image and re-optimizes the appearance for the destination medium using proprietary methods. This re-optimization may result in colors within both the source and destination gamuts being changed, although perceptual transforms are supposed to maintain the basic artistic intent of the original in the reproduction. They will not attempt to correct errors in the source image.
- 注記: v2 ICC ~profileでは,知覚的な基準~媒体が指定されていないため、相互運用性の問題が生じ得る。 v2 ICC ~profileの利用-時には、`描画意図$ `perceptual$v に代わって,黒色点~補償を伴う `relative-colorimetric$v を利用する方が安全かもしれない — 特定の[ 変換元, 変換先 ]が利用され、それらの~profileの組合せの下で,欲される結果が生産されるものと検査-済みであれば別だが。 ◎ Note: With v2 ICC profiles there is no specified perceptual reference medium, which can cause interoperability problems. When v2 ICC profiles are used it may be safer to use the media-relative colorimetric rendering intent with black point compensation, instead of the perceptual rendering intent, unless the specific source and destination profiles to be used have been checked to ensure the combination produces the desired result.
- この手法は、~~目的~機器の色域に対応付ける際に,画素~間の相対的な色~値を保守するべきである。 この手法は、色相ずれや不連続性を避けて,風景の全体的な外観を可能な限り保全するため、~~目的~機器の色域に元から入っていた画素~値も変更し得る。 ◎ This method should maintain relative color values among the pixels as they are mapped to the target device gamut. This method may change pixel values that were originally within the target device gamut, in order to avoid hue shifts and discontinuities and to preserve as much as possible the overall appearance of the scene.
- `saturation@v 【 “彩度~重視” 】
- この~optionは、元の相対的な彩度(純色度)を保全して,単色を純に保つために創出された。 しかしながら、`描画意図$ `perceptual$v の様な相互運用性の問題があることも判っている。 単色の保全は,基準~媒体に~~帰順させられないので、 v4 ~profileを利用しても,その問題は解消できない。 この描画意図の利用は推奨されない — 特定の[ 変換元, 変換先 ]が利用され、それらの~profileの組合せの下で,欲される結果が生産されるものと検査-済みであれば別だが。 この~optionは、元の画素の相対的な彩度(純色度)値を保全する。 色域~外の色は、色域~内に入る同じ彩度の色に変換されるべきである。 ◎ This option was created to preserve the relative saturation (chroma) of the original, and to keep solid colors pure. However, it experienced interoperability problems like the perceptual intent, and as solid color preservation is not amenable to a reference medium solution using v4 profiles does not solve the problem. Use of this rendering intent is not recommended unless the specific source and destination profiles to be used have been checked to ensure the combination produces the desired result. This option should preserve the relative saturation (chroma) values of the original pixels. Out of gamut colors should be converted to colors that have the same saturation but fall just inside the gamut.
RESOLVED: ある~profileから 別のそれへ変換するときは黒色点~補償を行う。 これは、上に言及した描画意図に依存することになる。 これだけで足るか? ~sRGBに組込みの~flare補正~用の黒色点~補償はどうなのか? ◎ RESOLVED: Do black point compensation when converting from profile to another. This will depend on the rendering intent and is mentioned there already. Does that suffice? What about black point compensation for the flare correction built into sRGB?
12. 作業用 色~空間
San Francisco 会合にて,文書~全体に影響する `working-color-space^at at-規則を追加することに解決された。 組成-法, 補間, 混色-法にはこれが利用される。 初期値は `sRGB^v 。 `linear-sRGB^v, `p3^v, `rec2020^v, `lab^v も値の~~候補に挙がっている。 そこで何をするかについては canvas 仕様を見よ。 特に “最適な” 値。 ◎ Resolved at San Francisco to add a working-color-space at-rule, which affects the entire document. Compositing, interpolation, blending use this. Initial value is sRGB. linear-sRGB, p3, rec2020, and lab were also discussed as values. Chris to read the canvas spec to see what it does there, particularly for the “optimal” value.
13. 機器に依存する~CMYK色: `device-cmyk^f 関数
色は、~screen上では 概して ~RGB画素で直に表示されるが、印刷機では 異なる仕方で表現されることが多い。 特に,印刷用途においては、その機器~上の特定0の色を,~CMYK — ~cyan, ~magenta, ~yellow, ~black — の組合せで表現して得るのが,最も共通的な仕方である。 `device-cmyk$f 関数により、作者は,この仕方で色を指定できるようになる: ◎ While screens typically display colors directly with RGB pixels, printers often represent colors in different ways. In particular, one of the most common print-based ways of representing colors is with CMYK: a combination of cyan, magenta, yellow, and black which yields a particular color on that device. The device-cmyk() function allows authors to specify a color in this way:
`device-cmyk@f = device-cmyk( `cmyk-component$t{4} [ / `alpha-value$t ]? , `color$t? ) `cmyk-component@t = `number$t | `percentage$t
`device-cmyk$f 関数の最初から 4 個の引数は、順に,[ ~cyan, ~magenta, ~yellow, ~black ]成分を 範囲 0 〜 1 の数, または 範囲 0% 〜 100% の百分率で指定する。 これら 2 つの用法は等価であり,互いの対応関係は線形になる。 この範囲~外の値も無効にはされないが、それらは範囲~内に切詰められる。 ◎ The arguments of the device-cmyk() function specify the cyan, magenta, yellow, and black components, in order, as a number between 0 and 1 or a percentage between 0% and 100%. These two usages are equivalent, and map to each other linearly. Values less than 0 or 0%, or greater than 1 or 100%, are not invalid; instead, they are clamped to 0/0% or 1/100%.
5 個目の引数は、色の~alpha~channelを指定し, `rgb$f 関数に対する 4 個目の引数と~~同じに解釈される。 省略-時の既定は `100%^v になる。 ◎ The fifth argument specifies the alpha channel of the color. It’s interpreted identically to the fourth argument of the rgb() function. If omitted, it defaults to 100%.
6 個目の引数は、~fallback色を指定する。 ~UAが~CMYK色から~RGBへ正確aに変形する方法を知らないときに利用される。 省略-時の既定は、`~CMYKから~RGBAへ素朴に変換-$した結果の~RGB色になる。 ◎ The sixth argument specifies the fallback color, used when the user agent doesn’t know how to accurately transform the CMYK color to RGB. If omitted, it defaults to the CMYK color naively converted to RGBA.
RESOLVED: `color-profile$at 規則~内に 出力~機器の色~profileが正確aに記述されていれば、健全な実装は,それらの色を改めることはないので、一般に `device-cmyk^f の代用として足り,程よい~RGB~fallbackを自動的に供する。 ◎ RESOLVED: If you accurately describe the output device’s color profile in an @color-profile rule then a sane implementation will not alter your colors so this is sufficient as a replacement for device-cmyk in general and provides a good RGB fallback automatically.
概して,印刷用途の~appは、実際に利用する色を~CMYKとして格納し, それを そのままの形で印刷機へ送信するが、あいにく,~CSSは それをできない。 種々の~CSS特色機能は、色の組成-法や混色-法, 等々 を行うときに,~RGB色を要する。 そのようなわけで、~CMYK色は,等価な~RGB色に変換され~MUST。 これは、~HSL/~HWBから~RGBへ変換するときほど自明ではない — 精確な変換は、出力~機器の精確な特性に依存する。 ◎ Typically, print-based applications will actually store the used colors as CMYK, and send them to the printer in that form. Unfortunately, CSS cannot do that; various CSS features require an RGB color, so that compositing/blending/etc. can be done. As such, CMYK colors must be converted to an equivalent RGB color. This is not trivial, like the conversion from HSL or HWB to RGB; the precise conversion depends on the precise characteristics of the output device.
`device-cmyk$f 関数の算出値は、~UAが[ ~CMYK色から正しい~RGB色へ正確aに変換できるような,出力~機器についての情報 ]を得られるならば,~RGBA色で~MUST。 他の場合の算出値は、~fallback色で~MUST。 ◎ If the user agent has information about the output device such that it believes it can accurately convert the CMYK color to a correct RGB color, the computed value of the device-cmyk() function must be that RGBA color. Otherwise, the computed value must be the fallback color.
例えば、次の色は、(上に挙げた既定の変換の下で)等価になる: ◎ For example, the following colors are equivalent (under the default conversion listed above):
color: device-cmyk(0 81% 81% 30%); color: rgb(178 34 34); color: firebrick;
注記: これらの色は、~browserが,~CMYKと~RGBとの間の より精確な変換を知るならば、精確に合致しないかもしれない。 自身の文書にて~CMYK色を少しでも利用する作者には、色の調和をとる困難さを避けるため,~CMYK色のみを利用することが推奨される。 ◎ Note: these colors might not match precisely if the browser knows a more precise conversion between CMYK and RGB colors. It’s recommended that if authors use any CMYK colors in their document, that they use only CMYK colors in their document to avoid any color-matching difficulties.
13.1. ~CMYK色と~RGB色の間の変換-法
この節では、( icc に基づく)較正-済みの色と機器による未較正の~CMYKとを明瞭に判別する必要がある。 これは特に~RGBとの間の変換に影響する。 ◎ This section now needs to clearly distinguish between calibrated (icc-based) color on the one hand, and uncalibrated device-cmyk on the other. This particularly affects conversion to and from RGB.
この仕様にて定義されるほとんどの色は、~RGBAと直に互換であり,したがって 互いの間を機械的かつ一貫するように変換できる一方で、~CMYK色は,直に互換にならない。 所与の~CMYK色に対応付けられる~RGBA色は、出力~機器の物理的~特性に依存することになる。 ◎ While most colors defined in this specification are directly compatible with RGBA, and thus can be mechanically and consistently converted back and forth with it, CMYK colors are not directly compatible; a given CMYK color will map to various RGBA colors depending on the physical characteristics of the output device.
~UAが,~RGBAと~CMYKに対し出力~機器の色~profileを~~認識するのが,理想である — そうであれば、~UAは,~CMYK色と~RGBA色を相互に変換し~MUST — 先ず対象の色を[ CIELab などの,機器に依存しない適切な色~空間 ]へ変換した上で、各~演算に対し,適切な色~profileを利用して出力~色~空間に変換することにより。 ◎ Ideally, the user agent will be aware of the output device’s color profiles for RGBA and CMYK. If this is true, then the user agent must convert between CMYK and RGBA colors (and vice versa) by first converting the color into an appropriate device-independent color space, such as CIELab, and then converting into the output color space, using the appropriate color profiles for each operation.
しかしながら、これは常に可能になるとは限らない。 その場合、~UAは 次の “素朴な” 変換~algoを利用し~MUST。 ◎ This is not always possible, however. In that case, the user agent must use the following naive conversion algorithms.
`~CMYKから~RGBAへ素朴に変換-@ するときは: ◎ To naively convert from CMYK to RGBA:
~fallback色が指定されていた場合、その色を返す(必要なら~RGBへ変換するときも)。 他の場合: ◎ If a fallback color was specified, return that color (converting it to RGB as well, if necessary). Otherwise:
red = 1 - min(1, cyan * (1 - black) + black) green = 1 - min(1, magenta * (1 - black) + black) blue = 1 - min(1, yellow * (1 - black) + black)
~alphaについては入力~色と同じ。 ◎ Alpha is same as for input color.
`~RGBAから~CMYKへ素朴に変換-@ するときは: ◎ To naively convert from RGBA to CMYK:
black = 1 - max(red, green, blue) cyan = (1 - red - black) / (1 - black), or 0 if black is 1 magenta = (1 - green - black) / (1 - black), or 0 if black is 1 yellow = (1 - blue - black) / (1 - black), or 0 if black is 1
- ~alphaについては入力~色と同じ。 ◎ alpha is the same as the input color
- ~fallback色は、入力~色に設定され~MUST ◎ fallback color must be set to the input color
【 次の様に式を簡略化できる: 】
// CMYK → RGB %v = 1 - black; red = max(0, (1 - cyan) * %v); green = max(0, (1 - magenta) * %v); blue = max(0, (1 - yellow) * %v); // RGB → CMYK %v = max(red, green, blue); black = 1 - %v; if(%v !== 0){ cyan = 1 - ( red / %v ); magenta = 1 - ( green / %v ); yellow = 1 - ( blue / %v ); } else { cyan = magenta = yellow = 0; }
14. 透明度: `opacity^p ~prop
不透明度は、後処理~演算と捉えることができる。 概念的には、要素(その子孫も含めて)が~RGBA~offscreen画像に描画されてから,不透明度の設定が その描画を 現在の組成-描画へ混色する方法を指定する。 詳細は 単純~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 ◎値 `alpha-value$t ◎初 `1^v ◎適 すべての要素 ◎継 されない ◎百 受容しない ◎算 指定値を実数に変換した結果を範囲 0 〜 1 に切詰めた結果 ◎ the specified value converted to a number, clamped to the range [0,1] ◎順 文法に従う ◎ア `実数として$ ◎表終- `alpha-value$t
- 要素に適用される不透明度。 結果の不透明度が 特定0の色とではなく,要素~全体に適用されることを除いて、 `rgb$f におけるその定義と~~同じに解釈される。 ◎ The opacity to be applied to the element. It is interpreted identically to its definition in rgb(), except that the resulting opacity is applied to the entire element, rather than a particular color.
`opacity$p ~propは、指定された不透明度を,要素にその内容も含めて 全体として 適用する。 各~子孫ごとに適用するのでなく。 これは例えば、要素の `opacity$p が 1 未満のときでも,要素の不透明な子が要素の背景を塞ぐ部分は そうあり続けるが、全体としての要素とその子は,それら自身を透かして下層の頁を示すことになることを意味する。 ◎ The opacity property applies the specified opacity to the element as a whole, including its contents, rather than applying it to each descendant individually. 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.
`opacity$p の値が 1 未満の場合、要素は,その子たちに対する`積層文脈$を形成する。 これは、要素の 外側と内側の内容が z-順序により互いに多層化されることは,なくなることを意味する。 要素~上の `z-index$p ~propに対する `auto^v 値は, `0^v に扱われる【算出値として?】 。 積層文脈についての更なる情報は、 `CSS21$r の[ 多層化による呈示, 付録 E ]を見よ。 この段落の規則は、 SVG 要素には適用されない — SVG は自前の 描画~model を備えているので( `SVG11$r, 3 章)。 ◎ If opacity has a value less than 1, the element forms a stacking context for its children. This means that any content outside of it cannot be layered in z-order between pieces of content inside of it, and vice versa. If the element is in a context where the z-index property applies, the auto value is treated as 0 for the element. See section 9.9 and Appendix E of [CSS21] for more information on stacking contexts. The rules in this paragraph do not apply to SVG elements, since SVG has its own rendering model ([SVG11], Chapter 3).
14.1. 単純~alpha組成-法
色を描くとき、実装は,~alphaを `Compositing$r による`単純~alpha組成-法$の規則に則って取扱わ~MUST。 ◎ When drawing, implementations must handle alpha according to the rules in Section 5.1 Simple alpha compositing of [Compositing].
15. 能力が様々な機器~間での色の保全-法: `color-adjust^p ~prop
ほとんどの~monitor上では、作者が何~色を選ぼうが,機器がどう描画するかに関して,有意な相違が生じることはない。 文書の背景が~white/~blackどちらであろうが,表示する容易さは ほぼ等しい。 ◎ On most monitors, the color choices that authors make have no significant difference in terms of how the device performs; displaying a document with a white background or a black background is approximately equally easy.
しかしながら、この前提が成り立たないような機器も中にはあり,制限があったり, 品質が変わることがある。 例えば、印刷機は,白い紙に印刷する傾向にあるので、白い背景の文書は,さして~inkを費やすことなく,その背景~上に描く一方で、背景が黒い文書は,背景~色を埋めるために多量の~inkを費やす。 これは、印刷費を跳ね上げるのは言うまでもなく,紙に有害な物理的~効果をもたらすこともある。 ~text色を黒にするか暗い~grayにするか のような,さほど違いはない場合でも、印刷-時には全く異なることはある — 利用する~inkを単独の黒~inkから[ ~cyan, ~magenta, ~yellow ]~inkの混合に切替えるので、~inkを余計に費やしたり, 解像度が低下する。 ◎ However, some devices have limitations and other qualities that make this assumption untrue. For example, printers tend to print on white paper; a document with a white background thus has to spend no ink on drawing that background, while a document with a black background will have to expend a large amount of ink filling in the background color. This tends to look fairly bad, and sometimes has deleterious physical effects on the paper, not to mention the vastly increased printing cost from expending the extra ink. Even fairly small differences, such as coloring text black versus dark gray, can be quite different when printing, as it switches from using a single black ink to a mixture of cyan, magenta, and yellow ink, resulting in higher ink usage and lower resolution.
その結果、状況によっては、~UAは,特定0の文脈~下では,作者が指定した~styleを改めることもある — それらを出力~機器に より適切に調整して,利用者が選好すると見做されるものに適応するように。 しかしながら、一部の事例では、文書は,利用者に快適になるように,重要かつ熟慮された仕方で色を利用していることもあり、そのような頁では,選ばれた色が尊重されるよう,何らかの仕方で~UAに~hintすることが求められるであろう。 `color-adjust$p ~propは、これを制御する。 ◎ As a result, in some circumstances user agents will alter the styles an author specifies in some particular context, adjusting them to be more appropriate for the output device and to accommodate what they assume the user would prefer. However, in some cases the document may be using colors in important, well-thought-out ways that the user would appreciate, and so the document would like some way to hint to the user agent that it might want to respect the page’s color choices. The color-adjust property controls this.
◎名 `color-adjust@p ◎値 `economy$v | `exact$v ◎初 `economy$v ◎適 すべての要素 ◎継 される ◎百 受容しない ◎算 指定値 ◎順 文法に従う ◎ア 離散的 ◎表終`color-adjust$p ~propは、所与の機器~上で,高価に, より一般には無分別になり得るようなときに — 文書における 暗い背景に明るい~textを利用して印刷するなど — 色や~styleの~~選択をどう扱うべきかについての~hintを,~UAに供する。 ~UAが,文書~表示のこの側面を 利用者が制御できるようにする場合、利用者の選好は,この~propにて供される~hintより強く尊重され~MUST。 次の値をとり得る: ◎ The color-adjust property provides a hint to the user-agent about how it should treat color and style choices that might be expensive or generally unwise on a given device, such as using light text on a dark background in a printed document. If user agents allow users to control this aspect of the document’s display, the user preference must be respected more strongly than the hint provided by color-adjust. It has the following values:
- `economy@v
- ~UAは、頁の~style付けに対し,出力~機器に必要かつ賢明と判断される調整を施すべきである。 ◎ The user agent should make adjustments to the page’s styling as it deems necessary and prudent for the output device.
- 例えば,文書が印刷されるとき、~UAは,費やす~ink量を~~抑えるため,背景を無視して ~textを十分~暗い色になるよう調整することもあり得る。 ◎ For example, if the document is being printed, a user agent might ignore any backgrounds and adjust text color to be sufficiently dark, to minimize ink usage.
- `exact@v
- この値は、頁は,重要かつ有意な仕方で 要素の色や~style付けを指定していて、利用者から要請されない限り,調節されたり変更されるべきでないことを指示する。 ◎ This value indicates that the page is using color and styling on the specified element in a way which is important and significant, and which should not be tweaked or changed except at the user’s request.
- 例えば、 printed directions 【方向指示?】を提供している地図siteは、 directions 内の各 step の背景が ~whiteと明るめの~grayが交互になるよう “縞模様に” することもある。 この縞模様が失われて背景が純~whiteにされると,~~車の~~運転時に direction を~~一目で読み取るのも難しくなる。 ◎ For example, a mapping website offering printed directions might "zebra-stripe" the steps in the directions, alternating between white and light gray backgrounds. Losing this zebra-striping and having a pure-white background would make the directions harder to read with a quick glance when distracted in a car.
16. 既定の~style規則
次の~stylesheetは参考であり,規範的ではない。 実装は、この~stylesheetを各種 HTML/XHTML Family 文書( HTML4, XHTML1, XHTML1.1, XHTML Basic, 他)にて既定~style付けの一部として利用できる。 ◎ The following stylesheet is informative, not normative. This style sheet could be used by an implementation as part of its default styling of HTML4, XHTML1, XHTML1.1, XHTML Basic, and other XHTML Family documents.
html {
color: black;
}
/*
~hyperlinkに対しては、伝統的な~desktop~UA色
◎
traditional desktop user agent colors for hyperlinks
*/
:link { color: blue; }
:visited { color: purple; }
根~要素に対する既定の背景は、 `transparent$v で~MUST。 ~canvas(文書が塗られる~~面)の既定の色は~UAに依存するが、 `white$v にすることが推奨される。 とりわけ,上の `color$p: `black$v 規則が利用されるときは。 ◎ The default background of the root element must be transparent. The default color of the canvas (the surface on which the document is painted) is UA-dependent, but is recommended to be white, especially if the above color rules are used.
17. 色~変換~codeの見本
~INFORMATIVE【 この節の内容は未訳(全体を~JS~codeが占めるので、原文を参照されたし)。 】
付録 A: 非推奨にされた~CSS~system色
~CSSのより早期の~versionは、追加の有名~色~keyword `deprecated-system-color@t 【非推奨にされた~system色】 をいくつか定義していた。 それらは、~OSの~themeから色を取込むためとして~~意図されていた。 しかしながら、これらの色~名は,次の~~理由から非推奨にされた:
- その元々の目的(~web~siteの要素を ~native~OSに~~相当する見かけにする)には不足である。
- ~web頁が~native~OSの~dialogを “偽装する” のも容易になり,~security~riskになる。
~UAは、これらの~keywordを~supportし~MUSTが,それらを 利用者~OSの環境設定に基づかないような “既定の” 値に対応付けるべきである(例えば、すべての “背景” 色は~whiteに, “前景” 色は~blackに対応付けるなど)。 作者は、これらの~keywordを利用しては~MUST_NOT。 ◎ User agents must support these keywords, but should map them to "default" values, not based on the user’s OS settings (for example, mapping all the "background" colors to white and "foreground" colors to black). Authors must not use these keywords.
- `ActiveBorder@vk
- `ActiveCaption@vk
- 順に、作動中の~windowの[ ~border, ~caption ]の色。 ◎ Active window border. ◎ Active window caption.
- `AppWorkspace@vk
- 複数の文書~interfaceの背景~色。 ◎ Background color of multiple document interface.
- `Background@vk
- ~desktop背景。 ◎ Desktop background.
- `ButtonFace@vk
- `ButtonHighlight@vk
- `ButtonShadow@vk
- 順に、周囲の~border層に因り立体的に現れるような要素の[ ~~表面の背景, 光源に照らされている方の~border, 光源から離れた方の~border ]の色。 ◎ The face background color for 3-D elements that appear 3-D due to one layer of surrounding 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. ◎ 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.
- `ButtonText@vk
- ~push-buttonの~text。 ◎ Text on push buttons.
- `CaptionText@vk
- [ ~caption, ~size~box, ~scrollbar矢印~box ]内の~text。 ◎ Text in caption, size box, and scrollbar arrow box.
- `GrayText@vk
- 不能化-(~grayに)された~text。 この色は、現在の~display~driverが単色の~grayを~supportしない場合には, `#000^v に設定される。 ◎ Grayed (disabled) text. This color is set to #000 if the current display driver does not support a solid gray color.
- `Highlight@vk
- `HighlightText@vk
- 順に、~control内で選択されている[ ~item, ~itemの~text ]の色。 ◎ Item(s) selected in a control. ◎ Text of item(s) selected in a control.
- `InactiveBorder@vk
- `InactiveCaption@vk
- `InactiveCaptionText@vk
- 順に,作動中でない~windowの[ ~border, ~caption, ~caption内の~text ]の色。 ◎ Inactive window border. ◎ Inactive window caption. ◎ Color of text in an inactive caption.
- `InfoBackground@vk
- `InfoText@vk
- 順に、~tooltip~controlの[ 背景, ~text ]の色。 ◎ Background color for tooltip controls. ◎ Text color for tooltip controls.
- `Menu@vk
- `MenuText@vk
- 順に,~menuの[ 背景, ~text ]の色。 ◎ Menu background. ◎ Text in menus.
- `Scrollbar@vk
- ~scrollbarの~gray区画。 ◎ Scroll bar gray area.
- `ThreeDDarkShadow@vk
- `ThreeDFace@vk
- `ThreeDHighlight@vk
- `ThreeDLightShadow@vk
- `ThreeDShadow@vk
- 順に、周囲の~borderの 2 つの~concentric層に因り立体的に現れるような要素の[ 光源から離れた方の 2 本の~borderのうち 暗い方(一般に外縁), ~~表面の背景, 光源に照らされている方の 2 本の~borderのうち 明るい方(一般に外縁), 光源に照らされている方の 2 本の~borderのうち 暗い方(一般に内縁), 光源から離れた方の 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. ◎ The face background color for 3-D elements that appear 3-D due to two concentric layers of surrounding 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. ◎ 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. ◎ 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.
- `Window@vk
- `WindowFrame@vk
- `WindowText@vk
- 順に、~windowの[ 背景, ~frame, 中の~text ]の色。 ◎ Window background. ◎ Window frame. ◎ Text in windows.
謝辞
各種 色~profileを書き上げて 実装された Brad Pettit 氏に。 ~HSL色を書き上げた Steven Pemberton 氏に。 次の方々からの~feedbackに:
Thanks to Brad Pettit both for writing up color-profiles, and for implementing it. Thanks to Steven Pemberton for his write up on HSL colors. Thanks especially to the feedback from Marc Attinasi, Bert Bos, Joe Clark, fantasai, Patrick Garies, Tony Graham, Ian Hickson, Susan Lesch, Alex LeDonne, Cameron McCormack, Krzysztof Maczyński, Chris Moschini, Chris Murphy, Christoph Päper, David Perrell, Jacob Refstrup, Dave Singer, Jonathan Stanley, Andrew Thompson, Russ Weakley, Etan Wexler, David Woolley, Boris Zbarsky, Steve Zilles, the XSL FO subgroup of the XSL working group, and all the rest of the www-style community.
常駐の CSS Color 専門家である Chris Lilley 氏に。 ◎ And thanks to Chris Lilley for being the resident CSS Color expert.
変更点
CSS Colors 3 からの変更点
- `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の関数記法の設計原則 を保つため、今や,すべての色~関数は この形による構文を利用する。 ◎ 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.
新規に,いくつかの特色機能が追加された: ◎ Several brand new features have been added:
- ~grayを~~簡潔に指定する(および,輝度を介する指定もおそらく可能にする)ための `gray$f 関数。 ◎ gray() function, for specifying grays compactly. (And maybe allowing specification via luminance.)
- ~HWB記法による色を指定する `hwb$f 関数。 ◎ hwb() function, for specifying colors in the HWB notation.
- 色を操作するための `color-mod$f 関数。 【いったん導入されたが、除去された(が、構文を改めた上で再び導入されるであろう)。】 ◎ color-mod() function, for manipulating colors.
- 機器に依存しない色~用の `lab$f, `lch$f 関数。 ◎ lab() and lch() functions, for device-independent color
- 機器に依存する~profiled色~用の `color$f 関数と `color-profile$at at-規則。 ◎ color() function and @color-profile at-rule, for profiled device-dependent color.
- 出力~機器~特有の CMYK 色空間に属する,未較正の色を指定するための `device-cmyk$f 関数。 ◎ device-cmyk() function, for specifying uncalibrated colors in an output-device-specific CMYK colorspace.
- 有名~色に `rebeccapurple$v を追加。 ◎ Addition of named color rebeccapurple.
~securityと~privacy上の考慮点
この仕様は,“~system” 色を定義し、理論的に 利用者の~OS環境設定の詳細を公開し得るため,指紋収集の~riskがある。 しかしながら、これらの値は今や,環境設定に中立的になるものと定義されたので、実際には~system色を公開しないような汎用的な仕方で実装されるべきである。 ◎ This specification defines "system" colors, which theoretically can expose details of the user’s OS settings, which is a fingerprinting risk. However, these values are now defined to be settings-neutral, and should be implemented in a generic way that does not actually expose system colors.
~system色が実際に利用者の~system色に対応する場合、~malware~siteにとっては,~system~dialogに似た見かけの~dialogを作成するのも容易になるので~security~riskがもたらされる。 しかしながら,それらは今や “汎用” になるよう定義されたので、この~riskも消えるはずである。 ◎ The system colors, if they actually correspond to the user’s system colors, also pose a security risk, as they make it easier for a malware site to create a dialog that appears to be a system dialog. However, as they are now defined to be "generic", this risk should be eliminated.