[css-color-5] Serialization of the alpha() function is not specified

The serialization of the newly added alpha() RCS function is not specified. All the other RCS color functions have serialization rules specified in https://drafts.csswg.org/css-color-5/#serial-relative-color, and alpha() needs this as well.

@svgeesus

@svgeesus

[css-color-5] Defined the term relative color processing space, #13994 …

[css-color-5] Serialization of relative colors (including the alpha-o…

[css-color-5] Defined serialization of the declared value of the alph…

Now fixed, 1.3. Serializing Relative Color Functions has

for alpha()

the string "alpha(from ", followed by the serialization of the origin color using the rules for serializing nested origin colors, followed by a single space, followed by the canonical colorspace ("xyz-d65" for "xyz") in all-lowercase, followed by " / " and the alpha component as specified (using the same rules as the color channel arguments, but clamped) followed by ")".

I'm a little bit confused by the alpha serialization in the updated spec. In the syntax for alpha(), the alpha component is optional so a color like alpha(from red) is valid and defaults to 100%. Can you explain why alpha() doesn't follow the shortest serialization rule here and allows omission of 100% alphas like the other color functions? I can see that if the alpha component is unspecified, alpha(from <color>) doesn't really make sense on its own, but at least the serialization would be more consistent?

@kbhomes

@kbhomes In general omitting the / 1 on relative colors doesn't round-trip, because omitted alpha defaults to the origin color's alpha, not 1.

So while it's technically doable to realize that red is always opaque, it might not be with something like currentColor.

Might be a bit weird if alpha(from currentcolor / 1) had to serialize alpha(from currentcolor / 1) but alpha(from red / 1) serialized as alpha(from red)? Again, not impossible but maybe a bit weird?

@emilio

@emilio That's a good point, and I'd forgotten about the previous discussion that pointed out that the alpha defaults to the origin color's.

But this would then also apply to the other relative color functions which all currently say:

followed (if the alpha component is non-unity) by " / " and the alpha component as specified (using the same rules as the color channel arguments, but clamped)

So oklch(from rgba(255, 0, 0, 0.5) l c h / 1) is expected to serialize as oklch(from rgba(255, 0, 0, 0.5) l c h) which is a different value. Maybe all of these relative color functions should remove the "non-unity" clause from alpha serialization?

@svgeesus

Yes, I agree that that seems wrong, cc @svgeesus

Maybe all of these relative color functions should remove the "non-unity" clause from alpha serialization?

Could be, we certainly should discuss this.

Proposed:

Remove the "non-unity" clause from alpha serialization of all relative color functions

Navigation Menu

Repository navigation

[css-color-5] Serialization of the alpha() function is not specified #13992

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

[css-color-5] Serialization of the alpha() function is not specified #13992

Description

Activity

nt1m commented on May 31, 2026

svgeesus commented on Jun 18, 2026

kbhomes commented on Jun 18, 2026

emilio commented on Jun 18, 2026

kbhomes commented on Jun 18, 2026

emilio commented on Jun 18, 2026

svgeesus commented on Jun 19, 2026

svgeesus commented on Oct 24, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions