[css-color-4] Serialization of named colors

[GPHemsley]

The spec says that named colors (including transparent) resolve to their rgb()/rgba() values. However, it appears that Firefox, Chrome, and Edge, at least, serialize to their literal (lowercase) names.

Should the spec be changed?

[cdoublev]

You might be interested by the comments starting from this #1004 (comment).

[GPHemsley]

You might be interested by the comments starting from this #1004 (comment).

@cdoublev I am indeed. You're always a step ahead of me. :)

Can't say I understand anything any better, though. :/

I'm working on some wpt tests that might enlighten us all.

[cdoublev]

Yeah, it gives me a headache each time I try to understand how color serialization is defined. The simple answer is that browsers do not always serialize in a conforming way and I think serialization does not have a high priority, be it for browser interoperability or spec authors. I understand it since it is not a feature for end users.

With that said, two people asking the same question may be a sign that the spec can be improved. The part you are linking to defines that a named color is derived from a computed value, but style.color (specified value) is not. Why would it be required to serialize a named color as part of a specified value, to rgb()? I have learned (this should be defined somewhere, imo) that a specified value is meant to represent the value as specified by its author + simplifications from tokenization (lowercase keywords, etc).

Good luck with your WPTs! =)

[svgeesus]

I discussed a similar issue with @emilio at TPAC and the problem is that most, but not all, of to serialize a CSS value for colors moved to CSS Color 4. The part that remains, and thus makes reading CSS Color 4 about serialization difficult, is:

If is a component of a specified value, then return the color as follows:

• If the color was explicitly specified by the author, then return the original, author specified color value.
• Otherwise, return the value that would be returned if the color were a component of a computed value.

That needs to be moved over; in addition, the rule in CSSOM does not reflect what browsers do and needs to be amended to

• If the color was explicitly specified by the author as a named color, then return the original, author specified color value folded to ASCII-lowercase.

[GPHemsley]

Ah, I was suspecting that the keyword rule may also have been coming into play:

keyword
→ The keyword converted to ASCII lowercase.

[svgeesus]

@emilio can you confirm that I remembered correctly? If so I can copy-and-edit the remaining portion of color serialization from CSSOM to CSS Color 4.

[svgeesus]

Related:

• [css-images-4] is serialization from named colors to rgb values is mandatory in general #7728

[GPHemsley]

So, if I'm understanding correctly, serialization (of sRGB, anyway) uses the computed value except when it was specified as a keyword, then it uses the (normalized) specified value?

Any update on the decisions about spec edits? I'm not seeing anything in the minutes beyond publishing a new draft.

[svgeesus]

Was waiting for confirmation from @emilio

[emilio]

Yeah, Chris's comment is right. The only explicitly preserved thing for srgb colors is the keyword.

But it needs to be recursive (e.g., color-mix(red, blue, ..) should use red / blue. It's not necessarily the computed value for all colors, depending on how / when some of the new functions compute.

[cdoublev]

The only explicitly preserved thing for srgb colors is the keyword.

In my experience, there are a lot more specified things that are not preserved: conversion to legacy rgb() or rgba(), removing <alpha-value> >= 1, mapping percentage to numbers, resolving calc values, clamping, precision, etc.