- From: Chris Lilley via GitHub <sysbot+gh@w3.org>
- Date: Mon, 05 Aug 2024 18:53:36 +0000
- To: public-css-archive@w3.org
In terms of adding a bunch of human-language aliases for semi-transparent named colors, note that CSS Color 4 already states: > Note: these color names are standardized here, _not because they are good,_ but because their use and implementation has been widespread for decades and the standard needs to reflect reality. Indeed, it is often hard to imagine what each name will look like (hence the list below); the names are not evenly distributed throughout the sRGB color volume, the names are not even internally consistent ( [darkgray](https://drafts.csswg.org/css-color-4/#valdef-color-darkgray) is lighter than [gray](https://drafts.csswg.org/css-color-4/#valdef-color-gray), while [lightpink](https://drafts.csswg.org/css-color-4/#valdef-color-lightpink) is darker than [pink](https://drafts.csswg.org/css-color-4/#valdef-color-pink)), and some names (such as [indianred](https://drafts.csswg.org/css-color-4/#valdef-color-indianred), which was originally named after a red pigment from India), have been found to be offensive. Thus, their use is not encouraged. Clearly, that rationale would not apply to new named colors. As @nt1m said, relative colors already handle this case and allows any desired opacity to be specified: `oklab(from PapayaWhip l a b /0.8)` in addition to allowing other modifications, such as making a color darker at the same time: `oklab(from PapayaWhip (calc(l * 0.8) a b /0.8)` -- GitHub Notification of comment by svgeesus Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10678#issuecomment-2269703428 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Monday, 5 August 2024 18:53:37 UTC