W3C home > Mailing lists > Public > public-css-archive@w3.org > February 2020

Re: [csswg-drafts] [css-color-4] Color modifications proposal: extending color functions (#3187)

From: Christoph Päper via GitHub <sysbot+gh@w3.org>
Date: Mon, 03 Feb 2020 09:09:15 +0000
To: public-css-archive@w3.org
Message-ID: <issue_comment.created-581310104-1580720954-sysbot+gh@w3.org>
This syntax with “local constants” allows to easily switch channels, e. g. `rgb(from currentcolor b g r)`, and it does allow inner colors defined in any valid syntax after `from`, but authors are limited to the parameters of the outer functional notation they are using, i. e. they cannot access the ones of other notations. Iʼm not sure how useful this would actually be, but I assume authors would expect or even want to be able to do that nevertheless. Wouldnʼt it thus make sense to make them available as well? 

This would require unambiguous, multiple-letter monikers for some components of `hsl` and `hwb` vs. `lch`, and `rgb` vs. `hwb` vs. `lab`. The keyword for the opacity channel common to all notations is already spelt `alpha` instead of `a` which would clash with `lab`.

________

- **`red[ness]`** is a `<percentage>` that corresponds to the origin color’s red channel after its conversion to sRGB

- **`green[ness]`** is a `<percentage>` that corresponds to the origin color’s green channel after its conversion to sRGB

- **`blue[ness]`** is a `<percentage>` that corresponds to the origin color’s blue channel after its conversion to sRGB

- **`hue`** is an `<angle>` that corresponds to the origin color’s HSL hue after its conversion to sRGB, normalized to a [0°, 360°) range.

- **`sat[uration]`** is a `<percentage>` that corresponds to the origin color’s HSL normalized chroma (i. e. saturation) after its conversion to sRGB

- **`light[ness]`** is a `<percentage>` that corresponds to the origin color’s HSL lightness after its conversion to sRGB

- **`white[ness]`** is a `<percentage>` that corresponds to the origin color’s HWB whiteness after its conversion to sRGB

- **`black[ness]`** is a `<percentage>` that corresponds to the origin color’s HWB blackness after its conversion to sRGB

- **`l-star`** / **`bright[ness]`** is a `<percentage>` that corresponds to the origin color’s CIE lightness

- **`a-star`** or **`chroma[ticity]-a`** is a `<number>` that corresponds to the origin color’s CIELab greenish-reddish *a* axis

- **`b-star`** or **`chroma[ticity]-b`** is a `<number>` that corresponds to the origin color’s CIELab bluish-yellowish *b* axis

- **`chroma`** is a `<number>` that corresponds to the origin color’s LCH chroma

- **`h-star`** is an `<angle>` that corresponds to the origin color’s LCH hue, normalized to a [0°, 360°) range.

- **`alpha`** is a `<percentage>` that corresponds to the origin color’s alpha opacity ~~transparency~~

________

This would also allow to make further values available in the future, which do not need to have dedicated notations, e. g. HSI `intensity` (relative chroma), HSV relative `value`, HSB absolute `brightness`; `grayness`; XYZ `tristimulus-x`; `luminosity` (W, J/s), YUV `luminance` (linear `y`, nit, cd/m²), Y'UV / Y'CC `luma` (`y-prime`), `chroma[ticity]-u`, `v-star`, `chroma-blue` (Cb, Pb), `red-cyan` (Cr, Pr), `chrominance`, `colorful[ness]` (saturation as relative colorfulness, chroma as comparative colorfulness;), `blue-luminance` (U), `luma-v`; YIQ `orangish-bluish` (I), `purple-green` (Q), CMYK `cyan[ness]`, `magenta[ness]`, `yellow[ness] `, `key`; `tint`, `tone`, `shade`; `radiance`… 

Btw., I believe it is counter-intuitive that angular hue would be converted to a `<number>`, so I kept `<angle>`. 

-- 
GitHub Notification of comment by Crissov
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/3187#issuecomment-581310104 using your GitHub account
Received on Monday, 3 February 2020 09:09:17 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 5 July 2022 06:42:00 UTC