Re: [csswg-drafts] [css-color-4] Achromatic colors converted to hue-ish spaces should treat hue as "missing", not NaN (#6107)

> If anything, making it less convenient is better.

Right. I would even argue that usage of `none` could be restricted further.

As it stands now, a color using `none` has a potential dependency on the other end of the interpolation. It's similar to the relative color syntax, with the added bonus of not knowing what color to relate it to.

```
/* this */
rgb(none none none);

/* is the same as */
rgb(from other, r g b);
```

I don't have the context necessary to think through the implications, but how would this work in practice for transitions, etc? Taking a use-case from the spec: <q>For example, to animate a color to "grayscale", no matter what the color is, one can interpolate it with `lch(none 0% none)`.</q>, how would this paragraph change colors? 

```css
p {
  color: lch(none 0% none);
  transition: color 1s;
}

p:hover {
  color: lch(50% 100 40);
}
```

On mouseover: jumping from black to gray, then smoothly towards red?
On mouseout: smoothly from red to gray, then stay there or back to black?

Some types of interpolations (where the _other_ color the value is relative to is not known beforehand) would only work smoothly in the cases where `none` stands for _powerless_ components, i.e. in the cases where the missing values can't affect rendering.

So does it make sense to limit the scope of _none_ to only be valid in powerless slots?

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


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

Received on Monday, 4 October 2021 21:30:39 UTC