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

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

> Thanks for the discussion and for pointing out [HTML-in-Canvas](https://github.com/WICG/html-in-canvas). I was drawing on ideas from that proposal, but had forgotten what it was called and so failed to credit it.
> 
> We have a [principle not to "extend a platform feature that has known defects, without considering how to address those defects"](https://www.w3.org/TR/design-principles/#leave-the-web-better:~:text=Do%20not%20extend%20a%20platform%20feature%20that%20has%20known%20defects%2C%20without%20considering%20how%20to%20address%20those%20defects), and the TAG is worried about how much this addition to [`measureText()`](https://developer.mozilla.org/en-US/docs/Web/API/CanvasRenderingContext2D/measureText) and [`fillText()`](https://developer.mozilla.org/en-US/docs/Web/API/CanvasRenderingContext2D/fillText) violates that, and whether the benefits are worth the violation. Basically, making the text-drawing canvas features more powerful will attract more developers to use them, and if the easiest path leads to non-accessible outcomes, that'll hurt overall accessibility on the web.

Yes, point well taken.
 
> It seems likely to be better overall to finish an accessible replacement for these features (hopefully HTML-in-Canvas) and then implement this new feature on top of that accessible replacement.

I agree that any accessibility improvements could be driven by HTML-in-Canvas, and those could then be pushed to "regular" canvas text rendering. Guessing about the future, we may end up in a situation where most text in canvas is HTML-in-Canvas and the only text rendered directly in canvas is special in some way.

> What kinds of problems will be caused by delaying this feature like that, and how should we think about how to balance them against the accessibility (and maybe internationalization) harm from implementing this feature as proposed?

That's an interesting question. The use cases I'm aware of are related to editing text and geometric effects that require individual glyphs. Folks from Google would have a better idea on specific use cases, beyond "make it easier to edit text in canvas" and "make it easier to implement existing animation engines, specifically Lottie, on the web". We could also decompose this proposal if that would make things simpler.

> On the API as proposed:
> 
> 1. Thanks for aligning on code units and for the explanation that this is fundamentally about post-ligature glyphs. That seems fine to us, with 2 caveats:
>    
>    1. If one of the use cases for this is to help editors position their carets, the feature of disabling ligatures in canvas rendering seems like it needs to be part of this feature, and not postponed. (It does make sense to tell editors that they ought to disable ligatures instead of trying to position inside of them.) As discussed above, it might be better to do this by rendering fully-CSS-able HTML onto canvas instead of copying individual CSS features into [`CanvasTextDrawingStyles`](https://github.com/fserb/canvas2D/blob/master/spec/text-modifiers.md).

I think we can position cursors within ligatures. Chrome at least supports breaking ligatures for selection and other editing operations, so canvas can hook into that. But also yes, HTML-in-Canvas theoretically makes text editing in canvas even easier (although it doesn't "just work" yet).

>   You'll want to get the explainer updated to avoid "grapheme clusters" before asking the internationalization folks for a review.

Noted.

>  Even though current implementations only use a single dimension of position to implement things like `getIndexFromOffset()`, the TAG thinks it's likely to be more future-proof to provide a whole point as input, like `caretPositionFromPoint()`.

Sounds good. Thanks.

> The question of how to deal with vertical text probably deserves a [review from the Internationalization WG](https://www.w3.org/guide/documentreview/#how-to-get-horizontal-review).

I have just filed an HTML issue to address vertical writing mode rendering in canvas. https://github.com/whatwg/html/issues/11449 We'll get that resolved before bring up internationalization review. The question has come up multiple times on Stack Overflow with no good answer ever, so it's clearly a pain point.

It seems likely that we will re-igniting the canvas accessibility discussion in the coming months. I'm hopeful that we can make a real progress now that we have stronger forcing functions and specific new APIs to provoke new ideas.

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

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