- From: Dan Burzo via GitHub <sysbot+gh@w3.org>
- Date: Mon, 25 Oct 2021 12:18:55 +0000
- To: public-css-archive@w3.org
> Yes, I know there are unresolved issues wrt to representing polar coordinates in color() and we'd need to solve these first. Maybe by changing its grammar to be [<number-percentage> | <angle> | none]+ instead of [<number-percentage> | none]+. I think it's perfectly reasonable to only accept the `<number>` version of `<hue>` in the `color()` syntax to represent polar coordinates. > There is no way for authors to parameterize the color space for colors not available in color() so that e.g. they can use OKLCH if that's supported or LCH if not. Currently the unifying aspect of color spaces that you can express with `color()` is the expected range of each of their components is `[0, 1]` / `[0%, 100%]`, while the theoretically-unbounded color spaces don't share a scale. The chroma in `oklch` hovers inside `[0, 0.3]`, while for `lch` it's more like `[0, 130]` (approximate numbers that fit in the sRGB gamut), so hotswapping these color spaces will only produce usable results if we scale `oklch` to match `lch`. -- GitHub Notification of comment by danburzo Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/6741#issuecomment-950867556 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Monday, 25 October 2021 12:18:56 UTC