Re: [csswg-drafts] [css-color-4] Inconsistent results with `none` and interpolation color spaces. (#8563)

The issue is that there's a minor conflict between the original purpose of `none` (don't do weird things like pretending that `black` has a red hue when interpolating in hsl), and the "eh, if we have the ability, might as well expose it" purpose of an explicit `none` keyword (since you could *force* the behavior in a hacky way, might as well bless it with a non-hacky syntax instead). The former *must* be based on the results *post-conversion*, when we see what the actual color is and if there are any powerless components. But the latter *looks* like it could be based on *pre-conversion*, and as long as you're interpolating in the same space as you're specifying, you can't tell the difference (because there's no conversion anyway).

So currently, the spec's position is that this *is* somewhat intentional, and if you're using `none` explicitly, you better be in control of both the specifying and interpolating color spaces.

But this could theoretically be different - we could do a check *before* conversion and do `none`-substitution (if both the start and end points are indeed using identical functions), and then do another `none` check *after* conversion, as currently specified. But this would be somewhat fragile - it wouldn't persist thru, say, a transition being interrupted and a new transition starting from the current color to a new endpoint. And in the case of dynamic colors being passed around in JS or variables, there's no guarantee that the start and end colors are going to use the same function anyway, so the "pre-substitution" check would be unreliable anyway.

I think the spec's current approach is probably the best overall here, then. Explicit `none` is only useful when you're controlling the entire transition and can make sure things align; in all other cases conversions are gonna happen and get confusing anway, so *sometimes* making it work slightly better probably isn't worthwhile.

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


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

Received on Monday, 13 March 2023 17:54:48 UTC