[css-color-5] Clarify serialization of color-mix()

[weinig]

In the recently added color-mix() test in WPT, https://github.com/web-platform-tests/wpt/blob/master/css/css-color/color-mix-basic-001.tentative.html, Firefox and WebKit already disagree on the results.

Firefox (and the test, since it was imported from Firefox) is currently serializing the result of a color-mix in srgb as:

color-mix(in srgb, blue, red  50%)  -> rgb(128, 0, 128)

whereas WebKit is serializing it as:

color-mix(in srgb, blue, red  50%)  -> color(srgb 0.5 0 0.5)

I chose the color(srgb ...) syntax serialization for WebKit for two reasons.

1. The use of srgb as the color space in the color-mix() gave it symmetry.
2. The use of the color(srgb ...) syntax gives more precision in WebKit, and therefore a mix could be more precise.

Either way, I think this should be clarified in the spec.

(Side note, I have a bunch of tests for color-mix(), color-contrast(), and relative color syntax, but have not proposed them for WPT since the specs were still actively moving targets, but if they would be useful, I would be happy to make a PR for WPT.)

[emilio]

(Side note, I have a bunch of tests for color-mix(), color-contrast(), and relative color syntax, but have not proposed them for WPT since the specs were still actively moving targets, but if they would be useful, I would be happy to make a PR for WPT.)

I think this issue is a good argument for exporting them to WPT, even if as .tentative, as I did :)

[weinig]

I think this issue is a good argument for exporting them to WPT, even if as .tentative, as I did :)

:) I agree, just want to double check with the editors.

[svgeesus]

@weinig wrote:

I chose the color(srgb ...) syntax serialization for WebKit for two reasons.

1. The use of srgb as the color space in the color-mix() gave it symmetry.
2. The use of the color(srgb ...) syntax gives more precision in WebKit, and therefore a mix could be more precise.

I agree with point 1, and point 2 was accepted by WG Resolution and is now explicit in the spec:

For the predefined color spaces,

the minimum precision for round-tripping is as follows:

color space	Minimum bits
srgb	10

Either way, I think this should be clarified in the spec.

Yes, Color 5 needs a serialization section.

[svgeesus]

Yes, lets have the tentative tests committed to wpt

[svgeesus]

@weinig does this look okay to you

[weinig]

Sorry for the delay in response.

This looks ok to me, but has one oddity, though I am not sure it is actual a problem and might be a good thing. The oddity is that normal hsl() and hwb() colors currently serialize as rgb(), and therefore this would be the first place where hsl() and hwb() are being serialized out. I actually prefer this, but I wanted to call it out as an interesting difference. WebKit doesn't currently do this, but supporting it would be trivial, and I am happy to update to this serialization.

We may also want to specify the minimum precision (number of bits-per-channel) for these forms as is done for the main color serialization - https://drafts.csswg.org/css-color-4/#serializing-color-function-values.

[svgeesus]

this would be the first place where hsl() and hwb() are being serialized out. I actually prefer this, but I wanted to call it out as an interesting difference.

Good point and we should indeed discuss which outcome we want and why.

We may also want to specify the minimum precision (number of bits-per-channel)

Yes, good catch, we should.

[svgeesus]

The oddity is that normal hsl() and hwb() colors currently serialize as rgb(), and therefore this would be the first place where hsl() and hwb() are being serialized out.

The more I think about this, the more it seems unintentional and should be replaced by a reference to the Color 4 serialization algorithm (which would mean hsl() and hwb() would serialize as rgb(num num num))

If we want the higher precision color(srgb float float float) then that should be changed in Color 4 first, and we should be sure implementers agree to use the higher precision form.

[svgeesus]

Agenda+ as relevant to #7310

[css-meeting-bot]

The CSS Working Group just discussed [css-color-5] Clarify serialization of color-mix(), and agreed to the following:

• RESOLVED: color-mix() returns color() for sRGB mixes

The full IRC log of that discussion

<fantasai> Topic: [css-color-5] Clarify serialization of color-mix()
<fantasai> github: https://github.com//issues/6206
<bradk> I just shared a rendering that I **think** is what fantasai was proposing
<bradk> Shared in WebEx
<fantasai> chris: agreement in general, remaining issue is should things like hsl come out as themselves, come out as rgb, or use the color() function which retains more precision
<bradk> Ok
<fantasai> chris: Emilio said it would be harder to ship, but could see the value of it, so not sure where we are on that
<fantasai> emilio: That's still my opinion
<fantasai> emilio: slight preference to serialize as input color
<fantasai> chris: I can see arguments both ways
<fantasai> chris: I have a slight preference for serializing as color()
<fantasai> jensimmons: any visual difference in the result?
<fantasai> chris: there could be, but very slight
<fantasai> chris: if only 8-bit, and do mix of a mix, lose some precision and could result in banding
<fantasai> emilio: that's also an implementation detail
<fantasai> emilio: no reason why colors can't be more precise than 8-bit
<fantasai> chris: that's not what implementations do
<fantasai> chris: spec mandates are higher precision for newer color spaces
<fantasai> chris: of course can implement at higher precision
<fantasai> chris: but concerned we'll get some degradataion
<fantasai> jensimmons: screens are getting better, and color precision going better, seems we should go with higher precision
<astearns> ack fantasai
<chris> qq+
<emilio> fantasai: can be confusing to give two hsl colors and get a different color
<emilio> ... from the precision argument I don't see why we won't just encourage implementations to have more precision
<astearns> ack chris
<Zakim> chris, you wanted to react to fantasai
<emilio> ... I don't understand why you'd have different precision on color() vs rgb()
<fantasai> chris: not just giving two colors, you specified color space to mix in and you get back in that color space
<fantasai> chris: shouldn't be that surprising
<emilio> q+
<fantasai> chris: wrt precision, implementations have been stuck on 8-bit for a long time
<fantasai> chris: but we've also written for other color spaces need 10-bit or 12-bit, or 16-bit for xyz
<fantasai> chris: so implementations going into those color spaces need more precision
<fantasai> chris: we did say that if you're giving a 0255 value in rgb you can get ?? when you serialize
<astearns> s/??/decimal places/
<fantasai> chris: but saying hope that everyone upgrades from 8-bit... harder than requiring upgrade for new stuff
<fantasai> emilio: I agree with fantasai
<fantasai> emilio: we use 8-bit colors for space-efficiency
<fantasai> emilio: so you can store an RGB color in one integer
<fantasai> emilio: but if we need more precision for htis feature, we can increase
<fantasai> emilio: if we implement high-precision sRGB we would do it both for color() and rgb()
<fantasai> emilio: there's no point in having two different representations for the same color space
<fantasai> astearns: just having higher precision for rgb() and color() wouldn't be sufficient, because color() can give you color spaces that are higher precision
<fantasai> fantasai: if I mix 2 rgb colors in xyz space, do I get a color in rgb or xyz space?
<fantasai> chris: xyz space
<fantasai> faceless: if I mix 2 rgb colors in rgb space, I get rgb space back right?
<fantasai> chris: yes
<fantasai> s/faceless/fantasai/
<fantasai> [missed]
<fantasai> astearns: so that you can plug that function into a nother property and not lose precision
<emilio> q+
<astearns> ack emilio
<fantasai> fantasai: if color(rgb) has a particular precision, no reason for rgb() to have different precision
<fantasai> emilio: ...
<fantasai> emilio: given you need to return a color in ?? color space, I don't think it we serialize as color() or rgb()
<lea> q?
<fantasai> emilio: maybe color() is more consistent with other colorspace outputs?
<lea> q+
<lea> q-
<fantasai> emilio: I'd be fine serializing as color() if easier for e.g. WebKit, for us it would be the same
<fantasai> astearns: I'm hearing a lot of, yeah, either way is fine I gues
<fantasai> astearns: so should we pick serializing as a color() function?
<fantasai> chris: you're going to get color() function anyway in any of the other color spaces
<fantasai> chris: if you just happen to pick srgb, need to pick what to do there
<fantasai> chris: imho more consistent to say get a color() function back
<fantasai> astearns: so proposed resolution is to serialize as a color() function
<chris> +1
<fantasai> lea: It's not always [missed]
<fantasai> lea: it's not always possible to serialize everything as color() function, there are functions only available in their own function e.g. lab() lch()
<fantasai> chris: That's true, but you won't see them in rgb() form either
<emilio> q+
<fantasai> lea: so does proposed resolution affect only mixing in rgb()?
<fantasai> lea: because right now that is the only color available both in functional notation and a color() function, and these are distinct color formats
<fantasai> lea: color() function has 10-bit and I think it can go beyond the 0-1 range
<fantasai> lea: I'm not sure if browsers want to use 10-bit format every time someone mixes in sRGB
<fantasai> lea: want to get clarity if this resolution is only about sRGB or about every color space ... which is not even possible
<fantasai> chris: If you choose to mix in sRGB then you'll get in sRGB color space
<fantasai> lea: so interpolation token in sRGB, then ?? interchangeable?
<fantasai> lea: does the syntax allow both?
<astearns> s/??/interpolation token/
<fantasai> lea: You specify which color space you interpolate is "in <colorspace>", in gradients or color-mix() or whatever
<fantasai> lea: does that mean that "in rgb" is same as "in sRGB" ?
<fantasai> chris: you can't say "in rgb"
<fantasai> chris: we don't have a color space called "rgb"
<fantasai> lea: are you sure?
<fantasai> chris: yes
<fantasai> -> https://www.w3.org/TR/css-color-4/
<astearns> ack emilio
<fantasai> emilio: is there any good reason why lab colors can't be specified in color() notation?
<fantasai> chris: because color() started out as predefined rgb spaces
<fantasai> chris: it's a lot shorter for lab/lch to have their own functions
<fantasai> chris: we do have an open issue about throwing everything into color() function
<fantasai> chris: but that would just take existing syntax and make it longer
<fantasai> emilio: benefit is that color-mix() would have consistent output
<fantasai> jensimmons: want to get through these issues so can start shipping
<fantasai> astearns: proposed resolution is that we serialize as a color() function for color-mix that is being mixed in rgb
<fantasai> lea: no rgb, only sRGB, so makes sense to return color()
<fantasai> astearns: any objections to this resolution?
<fantasai> RESOLVED: color-mix() returns color() for sRGB mixes
<chris> q+

[svgeesus]

CSS Color 5 already implements the resolution