- From: Chris Lilley via GitHub <sysbot+gh@w3.org>
- Date: Wed, 16 Feb 2022 18:57:08 +0000
- To: public-css-archive@w3.org
svgeesus has just created a new issue for https://github.com/w3c/csswg-drafts: == Percentage reference ranges for `lab()`/`oklab()`/`lch()`/`oklch`/`color()` == For the call, to see the full proposal in one place, the percentages would be explicitly defined so that 0% to 100% maps as follows:: * `lab.L`: `[0, 100]` * `lab.a`: `[-125, 125]` * `lab.b`: `[-125, 125]` (a and b have the same range, for simplicity) * `lch.c`: `[0, 150]` * `oklab.L`: `[0, 1.0]` * `oklab.a`: `[-0.4, 0.4]` * `oklab.b`: `[-0.4, 0.4]` (see above re: a and b) * `oklch.c`: `[0, 0.4]` * `xyz`, `xyz-d50`, `xyz-d65`: `[0, 1.0]` * predefined RGB: `[0, 1.0]` (not a change, but a clarification) No-one mentioned hue as a percentage so it remains an angle, in degrees by default if no unit is given. This gives useful ranges for percentages on all colors, roughly covering the `display-p3` gamut plus a bit, and should minimize the errors in implementations where something was either not divided by 100, or was and shouldn't be, etc (Safari and color.js and PostCSS all had these at various points). It also means people can paste in `lab`/`lch`/`oklab`/`oklch` values from other software (which does not use percents) without getting an error and without having to remember if L is [0..1] or [0..100]. `lch(29% 66.5 327)` == `lch(29% 44.33% 327)` == `lch(29 66.5 327)` `oklch(58% 0.11 110)` == `oklch(58% 27.5% 110)` == `oklch(0.58 0.11 110)` `color(xyz-d65 0.9504 1.0000 1.0888)` == `color(xyz-d65 95.04% 100.00% 108.88%)` _Originally posted by @svgeesus in https://github.com/w3c/csswg-drafts/issues/6741#issuecomment-1041818465_ Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/7064 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 16 February 2022 18:57:10 UTC