- From: Chris Lilley via GitHub <sysbot+gh@w3.org>
- Date: Tue, 31 Oct 2023 23:19:48 +0000
- To: public-css-archive@w3.org
Let's see if the spec tells us. First, [parsing directly specified colors](https://drafts.csswg.org/css-color-4/#specifying-lab-lch): > In Lab, 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. Now, colors specified some other way but [converted](https://drafts.csswg.org/css-color-4/#color-conversion): > 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. So: if I take `color(xyz-d65 1 1 1)` and [convert it to Lab](https://colorjs.io/apps/convert/?color=color(xyz-d65%201%201%201)&precision=5) offline and paste the result, `lab(100.12 9.0645 5.8018)` into my CSS then it will be clamped at parse time. But if I do `color-mix(in lab, color(xyz-d65 1 1 1) 100%, black)` there will be no clamping until it comes time to display it on screen at used-value time. I appreciate that this sucks for CSS pre-processors. -- GitHub Notification of comment by svgeesus Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9484#issuecomment-1788165615 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 31 October 2023 23:19:51 UTC