How should non-absolute <length> values be interpreted when used by CanvasTextDrawingStyles's letterSpacing / wordSpacing?

[weinig]

How should non-absolute values be interpreted when used by CanvasTextDrawingStyles's letterSpacing / wordSpacing (https://html.spec.whatwg.org/multipage/canvas.html#dom-context-2d-letterspacing).

Currently, there are few different types non-absolute lengths that CSS defines:

• font-relative lengths: (em, rem, ex, ... https://drafts.csswg.org/css-values-4/#font-relative-lengths)
• viewport-percentage lengths: (*vw, *vh, *vi, ... https://drafts.csswg.org/css-values-4/#viewport-relative-lengths)
• container-percentage lengths: (cqw, cqh, cqi, ... https://www.w3.org/TR/css-contain-3/#container-lengths)

This is well defined for CSS properties, but needs some additional language in HTML to make to clarify how to resolve these units.

(would be great to also clarify how/if calc() should be supported here. If calc() is not intended, maybe using the production and a list of supported units would make more sense).

(ctx.filter has the same issue due to drop-shadow() taking a , though it might need a separate resolution. I can file another issue if that turns out to be the case)

[Kaiido]

Seems like a duplicate of #7847 or do you think even for the <canvas> case there isn't enough info to handle these?

[weinig]

Even for the <canvas> case this undefined. (But perhaps that issue can just be expanded to all contexts)

[annevk]

@whatwg/css any advice?

We have three cases:

1. The document case. This could obtain live information in theory. a) font: I think this is defined. b) viewport: it has a viewport. c) container: this could be the canvas element's CSS size?
2. The OffscreenCanvas case that is created through a document. This could use one-time cached information from the document, similar to what we envision for direction and language. We could also not bother however.
3. The fully detached OffscreenCanvas case. a) font: I think this is defined through its default value? b) viewport: no idea what would make sense here. Perhaps fail to parse? c) container: fail to parse or maybe relative to the bitmap size?

Since I don't think this is super important my initial take would probably be to suggest that we treat 2 and 3 identically and make b) and c) fail to parse, but if there's something easier that would work too. I'm not entirely sure about 1. We've gone through quite some lengths for currentcolor, but whether it's worth it is not entirely clear.

cc @whatwg/canvas

[schenney-chromium]

Thinking of use cases, the font relative metrics seem like they could and should always resolve against whatever font is being used for text operations. I feel authors would expect that and it seems implementable.

There's been no discussion of percentage units, which I presume would resolve against the canvas size (even offscreen canvas has a size). If that's the case then there's not much point in resolving viewport and container units against the canvas size because they can all be achieved with percentages.

I do think we should be consistent between all types of canvas to maximize the chance that code will run the same everywhere.

[weinig]

Thinking of use cases, the font relative metrics seem like they could and should always resolve against whatever font is being used for text operations. I feel authors would expect that and it seems implementable.

We should make sure to specify what the root-font-relative units (rem, etc.) should do explicitly as well (perhaps they just alias the non-root ones)?