Re: [w3ctag/design-reviews] Canvas Text Metrics for Editing, Art and Design (Issue #1095)

matatk left a comment (w3ctag/design-reviews#1095)

Thank you @schenney-chromium for the reply, and again sorry for taking a while to get back to you.

We're glad to hear that the internationalization improvements are already happening.

We think that HTML has an important default that everything shown to fully-sighted users is also represented in the accessibility tree. It's good that developers can override this default, when necessary, but disabled users appreciate that inattentive HTML developers still produce something they can minimally access.

We appreciate the work on improving text animation capabilities, but we're concerned that the proposal in this issue leads to visible text being represented only in a Javascript string that's passed to a `<canvas>`, and not in the accessibility tree (AT). On the other hand, if the animated text needs to appear in a node inside a [`<canvas layoutsubtree>`](https://github.com/WICG/html-in-canvas?tab=readme-ov-file#1-the-layoutsubtree-attribute), it does wind up in the AT. These nodes will need to be marked `display:none` when they're not drawn, and all of the tools that browsers develop to help with that for nodes intended for [drawElementImage()](https://github.com/WICG/html-in-canvas?tab=readme-ov-file#2-drawelementimage-and-webglwebgpu-equivalents) will help with that.

We don't expect [drawElementImage()](https://github.com/WICG/html-in-canvas?tab=readme-ov-file#2-drawelementimage-and-webglwebgpu-equivalents) itself to expose glyph information. Instead, something like the sketch in https://github.com/Igalia/explainers/blob/main/canvas-formatted-text/text-metrics-additions.md#dom-element-inputs seems likely to work well.
* Most developers on the web are less sophisticated than Google Docs or Flutter developers, and we need APIs to serve their needs, and the needs of users they forget, first. The sophisticated developers will be able to make a lot of API shapes work.
* For this side of the API, it might make sense to relax the `drawElementImage()` restriction that "The element must be a direct child of the `<canvas>`." in order to allow sites to "decide to break down the input text for rendering in various ways".
* Incorporating CSS resolution is probably a net positive, since we might be able to stop cloning CSS features one-at-a-time into [`CanvasTextDrawingStyles`](https://html.spec.whatwg.org/multipage/canvas.html#canvastextdrawingstyles).

Therefore, we're resolving this review as `unsatisfied`, and we hope to see a future proposal that allows developers to split `<canvas>` child elements into animatable glyphs.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/1095#issuecomment-3872160989
You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/issues/1095/3872160989@github.com>