-
Notifications
You must be signed in to change notification settings - Fork 661
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[css-color-4] Inconsistent results with none
and interpolation color spaces.
#8563
Comments
The issue is that there's a minor conflict between the original purpose of So currently, the spec's position is that this is somewhat intentional, and if you're using But this could theoretically be different - we could do a check before conversion and do I think the spec's current approach is probably the best overall here, then. Explicit |
Good to have this background! With relative color syntax, authors also have one more tool to control the outcome here. color-mix(in oklch, oklch(from var(--some-color-a), l c none), oklch(from var(--other-color-a), l c h)) As long as this behaviour is known and everyone is ok with it, we can close this issue. |
The lightness has certainly changed, but a hue angle changing from 135.9 to 135.943 is insignificant and entirely invisible. |
That should probably be called out explicitly in a note in the spec. |
After giving it more thought and continuing with implementation I am still seeing some unexpected results. Are these steps correct for starting with https://drafts.csswg.org/css-color-4/#interpolation-missing
After replacing
After conversion to oklch :
Handling them as missing components would result in https://drafts.csswg.org/css-color-4/#interpolation-missing
Lightness is missing but has an analogous component in oklch.
https://drafts.csswg.org/css-color-4/#ex-analogous-hue
When mixing with
After linear interpolation :
The actual result in Chrome is :
The actual result in Safari is :
Safari's implementation is still behind a flag and might be behind the spec https://codepen.io/romainmenke/pen/wvEpOBN I am definitely missing a step where I should be handling powerless components, this explains the difference in But I don't get why the missing |
Hm, I think the spec isn't super clear here, wrt the ordering of powerless->none and none-carrover. One possible interpretation is that powerless->none happens first. The conversion produces black, which has powerless chroma and hue, so they become However, I suspect it makes more sense to do the opposite and process the carryover first, then check for powerlessness. This would mean the conversion initially produces Neither browser is correct per either interpretation of the spec currently - we should add this as a test once we decide which ordering was intended. @svgeesus ? Edit: actually, let me raise that as a separate issue. |
And yeah, while writing out #8602 I tried to define a third option that carries over components from the source if the missing->default process renders them powerless (so your example would carry over the specified HSL saturation and hue into OkLCH chroma and hue), but unfortunately there's no generally-doable way to convert a specific value across analogous components. So this confirms that using |
Thank you opening the second issue 🙇
True and that is fine I think. Just to be sure, in either case from #8602,
|
Yes, the carryover definitely requires the color to have a missing lightness after conversion. (And the two L channels are indeed analogous.) |
So I believe the spec is now clear:
|
I agree. |
https://drafts.csswg.org/css-color-4/#interpolation
https://drafts.csswg.org/css-color-4/#interpolation-missing
This seems to lead to unexpected results as currently implemented in Safari and Chrome.
In these examples I am using
color-mix
with the same color twice to illustrate to unexpected outcome. But the same is true with any combination of colors.The source color space, interpolation color space and the color function happen to be the same.
The result is
hsl(90deg 100% 50%)
The source color space, interpolation color space and the color function happen to be the same.
The result is
oklch(0.89 0.265 135.9)
or roughlyhsl(89.91 100% 50%)
The source color space, interpolation color space and the color function are not all the same.
The result is
oklch(0.445225 0.132279 135.943)
or roughlyhsl(92.45deg 100% 19%)
The hue angle and the lightness have changed, even when the inputs haven't changed and both inputs have the same hue.
Is this behavior intentional?
To me it is very surprising that you can unexpectedly hit or miss this special case where the color spaces and color functions align.
Keeping in mind that CSS authors might be using CSS variables, JavaScript, ... to dynamically combine and alter colors.
The text was updated successfully, but these errors were encountered: