[css-paint-api] Decide what to do with 'currentColor' as a fillStyle/strokeStyle on PaintRenderingContext2D

[bfgeek]

There are three different options here:

1. Throw exception on 'currentColor' being set as a style.
2. Try and resolve 'currentColor' based on the current element as the style resolution host.
3. Treat 'currentColor' as fully opaque black (this happens when a CanvasRenderingContext2D is detached from the DOM).

[bfgeek]

I personally favour either 1 or 3. If people want the resolved currentColor people should:

.foo {
  --my-color: currentColor;
  background-image: paint(foo);
}

// main thread
document.registerProperty({name: '--my-color', syntax: '<color>'});

// paint worklet
registerPaint('foo', class {
  static inputProperties = ['--my-color'];
  paint(ctx, geom, styleMap) {
    const myColor = styleMap.get('--my-color'); // Resolved currentColor
    myColor.r; // Can inspect individual components.
  }
});

[tabatkins]

currentcolor isn't turned into a color until used-value time, so you won't have it at variable time. (Our impl currently does it at computed-value time, as the spec used to say that, but Tim Loh just confirmed with me that we should change our impl - all the browsers agreed on the change a while ago.)

We'll need to expose currentcolor as a value type, similar to length keywords. If people want to handle it, they can do it themselves by taking 'color' as an input property. We could provide helpers for the currentcolor case that lie and claim it's opaque black, so naive code will still "work".

[bfgeek]

Oh currentColor is used value time? Thats great.

https://html.spec.whatwg.org/multipage/scripting.html#dom-context-2d-height
^ (nearish) Relevant part of CanvasRenderingContext2D spec, they treat currentColor for fillStyle/strokeStyle as comptued-value of color.

[tabatkins]

It used to be (computed-value-time)! But we changed it, oh, two or three years ago?