- From: Jeffrey Yasskin <notifications@github.com>
- Date: Wed, 02 Jul 2025 10:18:58 -0700
- To: w3ctag/design-reviews <design-reviews@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <w3ctag/design-reviews/issues/1095/3028642555@github.com>
jyasskin 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. 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. 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? ---- 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). 2. You'll want to get the explainer updated to avoid "grapheme clusters" before asking the internationalization folks for a review. 1. 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()`. 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). 1. [covered above] 1. That's a good justification for copying `align` and `baseline`. Thanks. Re @mbeganyi-a11y's second point: it's always going to be possible for authors to write inaccessible pages (in this case, for people who can read text visually, but need it to be ~"simple"). We just need to make them work for it. 😃 This is worth an [APA review](https://www.w3.org/guide/documentreview/#how-to-get-horizontal-review), but the TAG's guess is that it's acceptable to provide this ability to draw hard-to-read text. However, there might be a need for a configuration knob, like [`prefers-reduced-motion`](https://developer.mozilla.org/en-US/docs/Web/CSS/@media/prefers-reduced-motion) and [`prefers-reduced-transparency`](https://developer.mozilla.org/en-US/docs/Web/CSS/@media/prefers-reduced-transparency) to ask sites to tone it down. `prefers-reduced-visual-complexity`? (On the privacy/fingerprinting front, we could imagine asking browsers to push users toward giving `prefers-reduced-visual-complexity` and `prefers-reduced-motion` the same value, but it doesn't seem quite right to say that `prefers-reduced-motion` should imply that sites should avoid circular non-moving text.) -- Reply to this email directly or view it on GitHub: https://github.com/w3ctag/design-reviews/issues/1095#issuecomment-3028642555 You are receiving this because you are subscribed to this thread. Message ID: <w3ctag/design-reviews/issues/1095/3028642555@github.com>
Received on Wednesday, 2 July 2025 17:19:02 UTC