[css-color-4][cssom] Overlap between the definition of resolving color values and serializing <color> component values.

[frivoal]

Forked from a comment in another issue

As discussed at the Seattle F2F, there is some overlap between https://drafts.csswg.org/cssom/#serialize-a-css-component-value and https://drafts.csswg.org/css-color-4/#resolving-color-values.

https://drafts.csswg.org/css-color-4/#resolving-color-values is more specific / clear about which color should resolve to what at what time, but cssom is more specific about how to serialize the various functions once you've decided to do that.

Fixing this redundancy by having css-color-4 just keep the high level logic, and defer to cssom for the string level details of how to serialize the value does not seem particularly good to me, as presumably the new functions added to css-color-4 (and later) will have their serialization in css-color-4 (and later), and then you need to look up to multiple specs to have the full picture.

What I think would be nicer is:

• inline the the details that currently live in cssom into css-color-4
• have css-color-4 normatively state that it supersedes cssom on this topic
• either:
  • leave cssom as is, maybe with a note informatively pointing back to color-4)
  • make cssom normatively reference css-color-4 about this.

The comment/issue at the bottom of this section of cssom seems to agree:

One idea is that we can remove this section somewhere in the CSS3/CSS4 timeline by moving the above definitions to the drafts that define the CSS components.

[svgeesus]

related to #1004 #480 #1891 #585

[svgeesus]

I agree that having CSS Color 4 supersede CSSOM is cleaner, particularly since CSSOM currently assumes all values can serialize as either rgb() or rgba() in other words 8bit-per-component sRGB. (It also is silent on how to serialize the % form of rgb().

Even the float (%) form of rgb() is currently coerced in some unspecified way to an 8bit int.

[svgeesus]

Having color-4 supersede cssom here was already proposed and accepted

[css-meeting-bot]

The CSS Working Group just discussed Overlap between the definition of resolving color values and serializing <color> component values., and agreed to the following:

• RESOLVED: move serialization into color-4

The full IRC log of that discussion

<stantonm> topic: Overlap between the definition of resolving color values and serializing <color> component values.
<astearns> github: https://github.com//issues/982
<stantonm> chris: css object model has not clear text about how to construct these color strings
<stantonm> ... color-4 should obsolete that part of the model
<stantonm> ... do people agree? or do we think it needs serialization
<stantonm> ... even if you have rgb with percentage, some bits get thrown away
<stantonm> ... should it be in color-4 or OM
<stantonm> emilio: as long as its well defined I don't care
<stantonm> TabAtkins: prefer color spec
<stantonm> leaverou: remove it from css OM and just point to color-4
<stantonm> florian: agree, color-4 now has appropriate infomation to represent that spec
<stantonm> RESOLVED: move serialization into color-4
<stantonm> fantasai: before we remove from OM should we publish it
<stantonm> TabAtkins: publish both after the move

[svgeesus]

The overlap has now been separated out:

• Resolving <color> values
• Serializing <color> Values

So the only thing remaining is a PR on CSSOM to remove the color serialization stuff and point to CSS Color 4.