- From: Chris Lilley via GitHub <sysbot+gh@w3.org>
- Date: Wed, 16 Feb 2022 16:00:17 +0000
- To: public-css-archive@w3.org
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%)` -- GitHub Notification of comment by svgeesus Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/6741#issuecomment-1041818465 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 16:00:19 UTC