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

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

I'm involved in the implementation of both the Extended Text Metrics discussed here and the HTML-in-Canvas effort. I'd like to add my thoughts on the feedback.

* Regarding the internationalization improvements that arose from this discussion, the canvas text `lang` attribute is already in the HTML spec. The `writingMode` and `textOrientation` attributes for canvas text are explained in https://github.com/Igalia/explainers/tree/main/canvas-writing-mode. I'm implementing them in Chromium and working on moving the spec changes through WHATWG. They are independent of the Extended Text Metrics proposal in both their spec path and shipping status. I view them as a very useful outcome of the discussion here and in the working group.

* I view the text metrics proposal here to cover two primary use cases: one around canvas text editing support and interaction, and one around significant improvement to text animation capabilities. The former could be covered by HTML-in-Canvas. Personally I would be fine dropping the editing (bounding box and position-from-point) portions of this proposal to help move animation capabilities forward. I have not spoken to developers who may have use cases I don't know about.

* The per-glyph styling and animation capabilities of text clusters are not resolved by using HTML-in-Canvas, nor would the accessibility issues around animated glyphs be directly addressed. HTML doesn't provide such functionality.

* Assuming both HTML-in-Canvas and text clusters exist, we currently envision an accessibility tree that has the HTML-in-canvas content available "by default" along with a node in the DOM containing text describing the glyph animation, e.g. "Game Over", but not itself rendered into the canvas. This is one way to do what @jyasskin is suggesting above. One of the accessibility benefits we expect from HTML-in-Canvas is a greater  focus on the children of canvas elements and the accessibility features they already provide. This potential benefit would apply to any graphical and animated canvas content, including glyph animations enabled by extended text metrics.

* Layering per-glyph functionality on top of HTML-in-Canvas is technically not feasibly given the current proposals. To enable adequate performance (a significant concern for the browser vendors discussing the proposal) the DOM content painting structures are passed directly into the canvas drawing stream. There is no way to reach into the opaque structure and modify styles or positions of the elements rendered into it.

I hope that helps explain how the various features fit together. Apologies for the confusing array of canvas proposals all coming at once.

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

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