Open weinig opened 5 months ago
I think this is from 4.1. Processing Model for Relative Colors :
If the alpha value of the relative color is omitted, it defaults to that of the origin color (rather than defaulting to 100%, as it does in the absolute syntax).
Missing components are handled the same way as with CSS Color 4 § 12.2 Interpolating with Missing Components: the origin colorspace and the relative function colorspace are checked for analogous components which are then carried forward as missing.
Aha! It is implied, but not directly stated, that alpha is analogous to alpha.
If you agree, then I can add alpha to 12.2. Interpolating with Missing Components
Is the intention for that last conversion (from
hsl()
tocolor(srgb)
) to carry forward analogous component missing values?
I'm not fully sure on that point.
I totally agree that adding something to 12.2. Interpolating with Missing Components that says alpha is analogous to alpha would be great.
To restate what is probably obvious though, the bigger issue on this one is should the conversion from HSL()/HWB() to color(srgb) done for serialization be a "normal conversion" or should it be a "conversion that carries forward analogous component missing values"?
I thought a bit more about this and I think preserving the NaN (that is, using the "carries forward analogous component missing values" conversion) for alpha is better than not.
My argument is there really isn't any value in converting it to 0 here. As much as possible, serialization tries to preserve as much information as possible, and since we can preserve this, why not. (It also seems to be what Chrome does).
One things this does is beg the question, should all conversions between color spaces carry forward analogous missing components? In what cases would it not be what you want?
Is there any part of the specification that indicates that you shouldn't always carry forward analogous missing components during conversions between color spaces?
I thought this was always required.
Is there any part of the specification that indicates that you shouldn't always carry forward analogous missing components during conversions between color spaces?
I thought this was always required.
Section 4.4 is pretty explicit.
For all other purposes, a missing component behaves as a zero value, in the appropriate unit for that component: 0, 0%, or 0deg. This includes rendering the color directly, converting it to another color space, performing computations on the color component values, etc.
And since interpolation calls it out as a separate step, I think the implication is that if an algorithm wants carrying forward, it needs to call it out.
Ah, indeed!
The intention is to preserve missing components / none
as much as possible.
So if there are algorithms where it isn't stated and where it could be preserved, then we should change that.
The serialization as color(srgb)
for specific cases is problematic when trying to preserve missing components / none
.
It doesn't currently state that carry forward should happen. But it also makes carry forward impossible for non-alpha components when the src and dest aren't both in srgb to begin with.
If you agree, then I can add alpha to 12.2. Interpolating with Missing Components
https://codepen.io/romainmenke/pen/LYvvNrb
This would also affect interpolation but there isn't any interop for none
alpha.
Chrome threats none
in alpha during interpolation as the alpha of the other color. Safari and Firefox do not.
The CSS Working Group just discussed [css-color] Clarification needed on how missing alpha components flow through relative color syntax for hsl/hwb
, and agreed to the following:
ACTION fantasai and emilio to ask their respective teams this question
If you agree, then I can add alpha to 12.2. Interpolating with Missing Components
https://codepen.io/romainmenke/pen/LYvvNrb
This would also affect interpolation but there isn't any interop for
none
alpha. Chrome threatsnone
in alpha during interpolation as the alpha of the other color. Safari and Firefox do not.
That looks like a bug, if you change it to:
background-color: color-mix(
in srgb,
color(srgb 0.4 0.4 0 / none),
color(srgb 0.4 0 0.4 / 0.5)
)
Then Firefox does the right thing too. It seems we lose the none
information when converting the colors for interpolation.
Filed https://bugzilla.mozilla.org/show_bug.cgi?id=1901991 for this btw, Safari seems to behave like Firefox.
Ok, so the issue is that we treat those colors like "legacy" syntax, which generally doesn't allow none
, but the /
syntax does.
Chrome's handling seems broken as well, the none
is completely missing when serializing:
a.style.backgroundColor = "rgb(100 100 0 / none)";
a.style.backgroundColor // 'rgba(100, 100, 0, 0)'
So, how should those colors serialize? Should we just serialize to color(srgb ..)
? That'd be preferable IMO...
So, how should those colors serialize? Should we just serialize to
color(srgb ..)
? That'd be preferable IMO...
That seems like a good way forward to me
In the WPT test,
css/css-color/parsing/color-computed-relative-color.html
, there are a few examples I don't quite understand and can't figure out which language in the spec dictate them.One is:
What allows the alpha value to be passed through as
none
?My understand here of the operations performed is:
rebeccapurple
converted to hsl() [hsl(270 50% 40%)
]hsl(none none none / none)
hsl(none none none / none)
is converted tocolor(srgb)
for serialization, resolving all missing components to 0 [color(srgb 0 0 0 / 0)
] (https://drafts.csswg.org/css-color-5/#serial-relative-color)Is the intention for that last conversion (from
hsl()
tocolor(srgb)
) to carry forward analogous component missing values?Somewhat perplexingly (and perhaps just an error in the test), the corresponding test
css/css-color/parsing/color-valid-relative-color
has a similar example.My expectation is that they should at least expect the same result.
Similarly, what would expect for missing components in the origin.