[canvas] How are context dependent values resolved in canvas colors

[Calme1709]

What is the issue with the HTML Standard?

When colors (i.e. fillStyle, strokeStyle and shadowColor) are set on a canvas the spec says:

"If the value of other properties on the element a is on is required to do the resolution (such as resolving a currentcolor or system color), use element if it was passed, or the initial values of the properties if not."

This implies font-relative lengths (e.g. em) should be relative to the font of the element (or the initial font in the case of OffscreenCanvas) but this differs from how they are handled on other values (e.g. letterSpacing) which resolve them relative to the canvas' font (this is unspecified and in discussion in #10893 but consistent across browsers).

It also doesn't specify how values dependent on context other than the properties of the context element, such as root-font/viewport relative lengths (e.g. rem or vw) or light-dark(), should be resolved.

Existing implementations aren't consistent in how they handle these values:

Value	Chromium	Gecko	WebKit
rgb(calc(7px / 1px) 1 0)	accepted	rejected	accepted
rgb(calc(1em / 1px) 1 0)	resolves as though em was 0px	rejected	rejected
rgb(calc(1rem / 1px) 1 0)	resolves as though rem was 0px	rejected	rejected
rgb(calc(1vw / 1px) 1 0)	resolves as though vw was 0px	rejected	rejected
currentColor	resolves to #000000	resolves to element color (black for OffscreenCanvas)	resolves to #000000
light-dark(red, green)	rejected	always resolves to light option for <canvas>, rejected for OffscreenCanvas	rejected

[Kaiido]

cc @whatwg/canvas

Regarding currentColor, there was #9940 which seems related, though it apparently missed a few cases: https://jsfiddle.net/pau1bt6k/

• Safari will honor the <canvas>'s current color, if it's set through the element's style attribute, but not if it's set through a stylesheet.
• Firefox will honor the actual current color, but doesn't support color-mix() in there, and thus fails the tests.
• Chrome will only honor the current color if it's set through the style attribute, and part of a color-mix() call. They pass the tests...

There is also the question of CSS custom properties (var(--)), which no browser support.

[SaffronDuke]

In canvas rendering, context-dependent color values are usually resolved at the moment the color is assigned to the drawing state (for example, via fillStyle or strokeStyle).

Examples of context-dependent values include:

• currentColor — resolves to the computed CSS color value of the associated canvas element.
• CSS custom properties (var(--color)) — are resolved using the element's computed styles before the final color is used.
• System colors and theme-dependent colors — are resolved according to the browser's current UI/theme settings.
• Relative color functions (color-mix(), hsl(from ...), etc.) — are computed into an absolute color before drawing. ([MDN Web Docs]1)

For a 2D canvas:

1. The browser parses the supplied color string as a CSS <color> value.
2. Any context-dependent references are resolved against the canvas element's current computed style and environment.
3. The resulting color is converted into the canvas context's color space (typically srgb, though display-p3 can be requested). ([TypeError]2)
4. The resolved color is stored in the canvas drawing state and used for subsequent drawing operations.

For example:

canvas.style.color = "blue";
ctx.fillStyle = "currentColor";
ctx.fillRect(0, 0, 100, 100);

Here, currentColor resolves to blue based on the canvas element's computed color property before the rectangle is painted. ([MDN Web Docs]1)

If you're referring to a specific framework or platform called "Canvas" (for example, Figma Canvas, Power Apps Canvas, or Flutter Canvas), I can explain how that environment resolves color values as well.

[patrron]

Aký je problém so štandardom HTML?

Keď sú farby (t. j. fillStyle, strokeStylea shadowColor) nastavené na plátne, špecifikácia hovorí:

Ak je na vykonanie rozlíšenia potrebná hodnota iných vlastností elementu a (napríklad rozlíšenie aktuálnej farby alebo systémovej farby), použite element , ak bol odovzdaný, alebo počiatočné hodnoty vlastností, ak nie.

To znamená, že dĺžky relatívne k písmu (napr. em) by mali byť relatívne k fontprvku (alebo k pôvodnému písmu v prípade OffscreenCanvas), ale to sa líši od toho, ako sa s nimi zaobchádza pri iných hodnotách (napr. letterSpacing), ktoré ich riešia relatívne k písmu plátna (toto nie je špecifikované a je o tom diskutované v #10893 , ale je konzistentné vo všetkých prehliadačoch).

Taktiež nešpecifikuje, ako by sa mali riešiť hodnoty závislé od kontextu iného ako vlastnosti elementu kontextu, ako napríklad relatívne dĺžky koreňového písma/výrezu (napr. remalebo vw) alebo light-dark().

Existujúce implementácie nie sú konzistentné v spôsobe, akým spracovávajú tieto hodnoty:

Hodnota Chróm Gekón WebKit
rgb(calc(7px / 1px) 1 0) prijaté zamietnutý prijaté
rgb(calc(1em / 1px) 1 0) rieši sa, akoby embolo0px zamietnutý zamietnutý
rgb(calc(1rem / 1px) 1 0) rieši sa, akoby rembolo0px zamietnutý zamietnutý
rgb(calc(1vw / 1px) 1 0) rieši sa, akoby vwbolo0px zamietnutý zamietnutý
currentColor rozhoduje sa na #000000 rozhoduje sa o farbe elementu (čierna pre OffscreenCanvas) rozhoduje sa na #000000
light-dark(red, green) zamietnutý vždy sa rozpozná ako svetelná možnosť pre <canvas>, zamietnuté pre OffscreenCanvas zamietnutý

What is the issue with the HTML Standard?

When colors (i.e. fillStyle, strokeStyle and shadowColor) are set on a canvas the spec says:

"If the value of other properties on the element a is on is required to do the resolution (such as resolving a currentcolor or system color), use element if it was passed, or the initial values of the properties if not."

This implies font-relative lengths (e.g. em) should be relative to the font of the element (or the initial font in the case of OffscreenCanvas) but this differs from how they are handled on other values (e.g. letterSpacing) which resolve them relative to the canvas' font (this is unspecified and in discussion in #10893 but consistent across browsers).

It also doesn't specify how values dependent on context other than the properties of the context element, such as root-font/viewport relative lengths (e.g. rem or vw) or light-dark(), should be resolved.

Existing implementations aren't consistent in how they handle these values:

Value	Chromium	Gecko	WebKit
rgb(calc(7px / 1px) 1 0)	accepted	rejected	accepted
rgb(calc(1em / 1px) 1 0)	resolves as though em was 0px	rejected	rejected
rgb(calc(1rem / 1px) 1 0)	resolves as though rem was 0px	rejected	rejected
rgb(calc(1vw / 1px) 1 0)	resolves as though vw was 0px	rejected	rejected
currentColor	resolves to #000000	resolves to element color (black for OffscreenCanvas)	resolves to #000000
light-dark(red, green)	rejected	always resolves to light option for <canvas>, rejected for OffscreenCanvas	rejected

[Calme1709]

There is also the question of CSS custom properties (var(--)), which no browser support.

I think, as written currently, the spec is pretty clear that var() (and any other arbitrary substitution function) is invalid here, whether that is the desired behavior is another question:

Unless otherwise specified, arbitrary substitution functions can be used in place of any part of any property’s value (including within other functional notations); and are not valid in any other context.