[css-color] Support all existing (non-legacy?) formats in color()? #6741
Description
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]+.
Why should we be able to represent all existing color formats through color()?
- Right now the distinction between which color formats have a dedicated function and which ones are specified via
color()is murky. The spec describescolor()as "Profiled, Device-dependent Colors", but also includes the XYZ spaces there. - 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. - Even we are confused about whether to add new color spaces in
color()or as separate functions, imagine how difficult authors will find it to remember the distinction.
Reasons against doing this:
- Which serialization do we pick? The way we decided in [css-color-4] What serialization should be used when using color(lab ...) syntax to specify a lab color? #5825 was to drop
color(lab). If we adopt this proposal, we'd need to actually pick this time.