Re: [csswg-drafts] [css-color-4] Clarify how color() values with fallback should serialize (#5904)

You are right, this is not covered at all, and should be, explicitly, not just as an example.

In general, the design principles for `<<color>>` serialization were:

1. For legacy formats, maximal backwards compat so comma separators between color components, etc
2. For the new formats, normalize the values (such as trimming trailing zeroes) but otherwise serialize as-is
3. Normalize fully opaque colors by using an implicit alpha, except for legacy `rgb`/`rgba`, `hsl`/`hsla`

So it seems therefore that the serialized form, in the case of fallback, should be serialization as-is except for the various normalizations. Does that seem reasonable?

(Note to self to make sure Typed OM also handles fallback colors on the `color()` function).

Also btw your example is incorrect, it should either be

```css
color(display-p3 0 1 0, rgb(0 100% 0))
```

using the legacy syntax as a fallback, or

```css
color(display-p3 0 1 0, color(srgb 0 1 0))
```
using another color function as a fallback. Note that in this second case, the fallback could itself have a fallback. Here is an example:

```css
color(rec2020 0 0 1, color(display-p3 0.119 0 0.415, rgb(14.1% 0% 43.8%)))
```

![image](https://user-images.githubusercontent.com/2506926/106072079-2d298980-6110-11eb-9809-f425195c06ee.png)



-- 
GitHub Notification of comment by svgeesus
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/5904#issuecomment-768668338 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Thursday, 28 January 2021 00:26:19 UTC