You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Historically (and per-spec for RGB colors - "For all other sRGB values, the declared, computed and used value is the corresponding sRGB value.") color values have serialized the same way for declared and computed values (with the exception of "CSS named color, a system color, a deprecated-color, or transparent."
One unfortunate side effect of this is that calc() values get lost, in a way that is distinct from pretty much all other declared values (or at least in my limited testing). For instance, color: hsl(calc(30 + 60) 50% 50%) serializes as rgb(128, 191, 64), where as width: calc(20px) serializes as calc(20px). While there may be a compatibility reason to continue doing this for the RGB/HSL/HWB set, what is the argument to continue that on for lab()/lch()/oklab()/oklch()/color()?
Relative colors kick the trend, and are, I think, spec'd to serialize their declared form as declared (presumably retaining calc(), though that is not explicitly stated). I can't quite work out if that is the intention of section 11.2. Serializing Relative Color Functions, as there is some text that reads:
The serialization of the result of a relative color function depends on whether the keyword currentColor is the origin color.
It's not clear to me when this condition should kick in.
What is the rationale for using the computed value serialization for all absolute color serializations?
What is the intention of relative color serialization section? Is the intention to serialize declared values as declared, or only when currentColor is used?
The text was updated successfully, but these errors were encountered:
weinig
changed the title
[css-color] Declared value serializations of absolute and relative colors
[css-color-5] Declared value serializations of absolute and relative colors
May 13, 2024
In case the initial description was unclear, the meat of the question I am raising here can be stated more simply as:
"Should the declared value serialization of all RCS colors maintain follow the first paragraph of section 11.2, or does the first paragraph only apply to RCS colors that have currentcolor origin colors?"
Historically (and per-spec for RGB colors - "For all other sRGB values, the declared, computed and used value is the corresponding sRGB value.") color values have serialized the same way for declared and computed values (with the exception of "CSS named color, a system color, a deprecated-color, or transparent."
One unfortunate side effect of this is that
calc()
values get lost, in a way that is distinct from pretty much all other declared values (or at least in my limited testing). For instance,color: hsl(calc(30 + 60) 50% 50%)
serializes asrgb(128, 191, 64)
, where aswidth: calc(20px)
serializes ascalc(20px)
. While there may be a compatibility reason to continue doing this for the RGB/HSL/HWB set, what is the argument to continue that on forlab()
/lch()
/oklab()
/oklch()
/color()
?Relative colors kick the trend, and are, I think, spec'd to serialize their declared form as declared (presumably retaining
calc()
, though that is not explicitly stated). I can't quite work out if that is the intention of section 11.2. Serializing Relative Color Functions, as there is some text that reads:It's not clear to me when this condition should kick in.
What is the rationale for using the computed value serialization for all absolute color serializations?
What is the intention of relative color serialization section? Is the intention to serialize declared values as declared, or only when
currentColor
is used?The text was updated successfully, but these errors were encountered: