Canvas 2D context color serialization

[annevk]

Presumably the goal of #6562 was to enable new kind of color values. And these can be set. But they cannot be serialized as both fillStyle and strokeStyle use https://html.spec.whatwg.org/#serialisation-of-a-color which has not been updated. That serialization probably needs to switch on the color space?

cc @ccameron-chromium @whatwg/canvas

[ccameron-chromium]

The fillStyle and strokeStyle parameters are CSS colors. The color space in which those parameters are specified is independent of the color space of their CanvasRenderingContext2D. Serialization of non-sRGB colors is covered in CSS Color Level 4.
https://www.w3.org/TR/css-color-4/#serializing-color-values

The scope of #6562 is 2D canvas and ImageData.

The WebGL API with analogous scope is drawingBufferColorSpace/unpackColorSpace.

[annevk]

It is indeed covered there, but that's not what the fillStyle and strokeStyle getters use, right? (I'm also not sure if we can directly use that or if there are some differences in serialization for the sRGB space.)

[ccameron-chromium]

To the original question:

That serialization probably needs to switch on the color space?

No. The values of fillStyle and strokeStyle are independent of the color space of CanvasRenderingContext2D.

Is there disagreement on this?

[annevk]

I meant the color space of the color.

[ccameron-chromium]

Then this is in the context of CSS Color Level 4's new color syntax, and not #6562.

It appears that canvas prefers serializing to hex notation over rgb syntax for opaque colors (but not for non-opaque colors, which use rgba). In CSS Color Level 4's serialization, both rgb and rgba are preferred over hex notation. We should probably have the canvas color serialization carve out "here is the area where we are different", and then explicitly fall back to regular CSS serialization.

[annevk]

I guess in my mind that issue made using non-sRGB color values more meaningful and therefore we should have considered this.

[mysteryDate]

CSS Color 4 has a concept of legacy color syntax. Essentially, pre-css color 4 colors (rgb, rgba, hsl, hsla) get serialized as they always have. Non-legacy colors are serialized as described in csswg.sesse.net/css-color-4.

The simplest solution would just be to do exactly what CSS is doing, while preserving "opaque colors are hex" quirk from https://html.spec.whatwg.org/#serialisation-of-a-color.

ctx.fillStyle = "rgb(255, 0, 255)";
ctx.fillStyle;   // '#ff00ff'
ctx.fillStyle = "rgb(255, 0, 255, 0.5)"
ctx.fillStyle;   // 'rgb(255, 0, 255, 0.5)'
ctx.fillStyle = "color(dIsPlAy-P3  0.964  0.763  0.787)"
ctx.fillStyle;   // 'color(display-p3 0.96 0.76 0.79)'

Could we even link to https://csswg.sesse.net/css-color-4/#serializing-color-function-values?
We obviously need some tests in wpt to cover this.

[annevk]

Yeah, it's fine to link CSS's algorithms and the more we can reuse the better I think. As long as sRGB continues to do the same thing I think we're good.

[mysteryDate]

Yeah, it's fine to link CSS's algorithms and the more we can reuse the better I think. As long as sRGB continues to do the same thing I think we're good.

Great! Should we add this to some sort of agenda or should I just make a PR with the spec changes to this repo?

[annevk]

Just a PR is fine. And you can count WebKit as supportive of fixing this.

[Loirooriol]

Browsers aren't interoperable:

	Gecko	Blink/WebKit
rgb(255, 0, 255)	#ff00ff	#ff00ff
rgba(255, 0, 255, 1)	#ff00ff	#ff00ff
rgba(255, 0, 255, 0)	rgba(255, 0, 255, 0)	rgba(255, 0, 255, 0)
color(srgb 1 0 1)	#ff00ff	color(srgb 1 0 1)
color(srgb 1 0 1 / 1)	#ff00ff	color(srgb 1 0 1)
color(srgb 1 0 1 / 0)	rgba(255, 0, 255, 0)	color(srgb 1 0 1 / 0)
color(srgb none -1 2 / 3)	#0000ff	color(srgb none -1 2)
color(display-p3 0.96 0.76 0.79)	#febfc9	color(display-p3 0.96 0.76 0.79)

[annevk]

I think ideally we do whatever requires keeping around the least amount of state while retaining full precision.

From that perspective it seems nice that if color(srgb ...) is compatible with #... you'd serialize to the latter (so you can parse into the same model). However, maybe implementations already keep around some of the input state anyway for some CSS-related reason and therefore what Blink/WebKit do is overall simpler and preferable.

What Gecko does for inputs that are not compatible with #... does not seem acceptable as they lose precision.

@tabatkins @svgeesus what are the chances of the CSS WG taking over the definition of canvas CSS color serialization? It doesn't seem good for us to continue maintaining this. Looking at https://csswg.sesse.net/css-color-4/#serializing-color-values we'd have to special case quite a bit to get our desired results.