I updated the WHATWG Issue with my findings from comparing the WebKit and Blink proposals <https://github.com/whatwg/html/issues/10677#issuecomment-5767686355>. We can get the same functionality with a strict subset of WebKit's proposed APIs. If it makes getting agreement easier we could iterate on the common pieces and update our implementation to match.
Cheers, Stephen. On Wed, Sep 23, 2026 at 11:11 AM Chris Harrelson <[email protected]> wrote: > I also see that WebKit has engaged with an alternate API shape proposal > <https://github.com/WebKit/explainers/pull/137> that likely needs > consideration. > > On Wed, Sep 23, 2026 at 8:06 AM Rick Byers <[email protected]> wrote: > >> Update from API owners: If it doesn't cause too much of a delay, >> we'd like to ship things alongside HTML-in-canvas (instead of ahead of it) >> in order to help mitigate the TAG concerns. Florin is OOO but I confirmed >> with him that he thought that was a good idea. So let's circle back in a >> week or two and hopefully we'll know more about HTML-in-canvas timelines >> then. >> >> Rick >> >> On Mon, Sep 14, 2026 at 2:17 PM Alex Russell <[email protected]> >> wrote: >> >>> LGTM1. Let's make sure we get a Web Feature ID to track it with. >>> >>> On Wednesday, September 9, 2026 at 1:48:12 PM UTC-7 Florin Malita wrote: >>> >>>> On Wed, Sep 9, 2026 at 6:49 AM Yoav Weiss (@Shopify) < >>>> [email protected]> wrote: >>>> >>>>> Can you ask for a review on the "adoption" checkbox? >>>>> >>>> Done, thanks! >>>> >>>> On Monday, September 7, 2026 at 2:57:49 PM UTC+2 Florin Malita wrote: >>>>> >>>>>> Contact emails >>>>>> >>>>>> [email protected], [email protected], [email protected], >>>>>> [email protected] >>>>>> >>>>>> Explainer >>>>>> >>>>>> >>>>>> https://github.com/fserb/canvas2D/blob/master/spec/enhanced-textmetrics.md >>>>>> >>>>>> >>>>>> https://github.com/Igalia/explainers/blob/main/canvas-formatted-text/text-metrics-additions.md >>>>>> >>>>>> https://github.com/whatwg/html/issues/10677 >>>>>> >>>>>> Specification >>>>>> >>>>>> https://github.com/whatwg/html/pull/11000 >>>>>> >>>>>> Summary >>>>>> >>>>>> Expand the TextMetrics Canvas API to support selection rectangles, >>>>>> bounding box queries, and glyph cluster-based operations. >>>>>> >>>>>> This new functionality should enable complex text editing >>>>>> applications with accurate selection, caret positioning, and hit testing. >>>>>> Additionally, cluster-based rendering facilitates sophisticated text >>>>>> effects such as independent character animations and styling. >>>>>> >>>>>> Blink component >>>>>> >>>>>> Blink>Canvas >>>>>> <https://issues.chromium.org/issues?q=customfield1222907:%22Blink%3ECanvas%22> >>>>>> >>>>>> Web Feature ID >>>>>> >>>>>> Missing feature >>>>>> >>>>>> Motivation >>>>>> >>>>>> The existing TextMetrics API provides measurements for atomic text, >>>>>> but offers no facilities to break down that information to a more >>>>>> granular >>>>>> level. >>>>>> >>>>>> Sophisticated text applications (editors in particular) require such >>>>>> granular information in order to support accurate selection, caret >>>>>> positioning and hit testing at a grapheme level. Currently they are >>>>>> resorting to various inaccurate approximations to work around API >>>>>> limitations. >>>>>> >>>>>> Another complex use case involves rendering fragments of pre-shaped >>>>>> text with different attributes - e.g. different colors or different >>>>>> transforms. This is of particular interest to animation frameworks which >>>>>> allow characters to be animated independently. Such functionality is not >>>>>> directly supported in existing APIs, and implementers must again resort >>>>>> to >>>>>> approximate workarounds. >>>>>> >>>>>> The enhanced TextMetrics proposal aims to address the current API >>>>>> shortcomings and to offer first class support for the above use cases. >>>>>> >>>>>> Initial public proposal >>>>>> >>>>>> https://github.com/whatwg/html/pull/11000 >>>>>> >>>>>> TAG review >>>>>> >>>>>> https://github.com/w3ctag/design-reviews/issues/1095 >>>>>> >>>>>> TAG review status >>>>>> >>>>>> Issues open >>>>>> >>>>>> The TAG review was closed as unsatisfied. The TAG raised concerns >>>>>> regarding canvas accessibility defaults and suggested waiting for >>>>>> HTML-in-Canvas or using DOM element wrappers. We evaluated these >>>>>> alternatives in the explainer, but concluded that they are technically >>>>>> infeasible for the intended user base (low-level shaping and framework >>>>>> engines like Flutter Web). We agreed to disagree with the TAG on the >>>>>> scope >>>>>> of low-level Canvas primitives. >>>>>> >>>>>> Origin Trial Name >>>>>> >>>>>> Enhanced Canvas TextMetrics >>>>>> >>>>>> Goals for experimentation >>>>>> >>>>>> Partners have implemented prototypes based on the available runtime >>>>>> feature, with positive feedback. They are now interested in expanding the >>>>>> scope, and testing the API with real users. >>>>>> >>>>>> This experiment will provide valuable validation in real-world use >>>>>> scenarios, and should help us gauge the proposed API's fitness, >>>>>> ergonomics, >>>>>> and performance. >>>>>> >>>>>> Chromium Trial Name >>>>>> >>>>>> ExtendedTextMetrics >>>>>> >>>>>> Origin Trial documentation link >>>>>> >>>>>> >>>>>> https://github.com/Igalia/explainers/blob/main/canvas-formatted-text/text-metrics-additions.md >>>>>> >>>>>> WebFeature UseCounter name >>>>>> >>>>>> kExtendedTextMetrics >>>>>> >>>>>> Risks >>>>>> >>>>>> >>>>>> Interoperability and Compatibility >>>>>> >>>>>> Interoperability Risk: >>>>>> >>>>>> The primary interoperability risk is that other browser engines >>>>>> (Gecko and WebKit) have not yet committed to implementing this specific >>>>>> API >>>>>> surface. WebKit has expressed interest in exploring alternative, >>>>>> higher-level text shaping and line formatting abstractions. This risk is >>>>>> mitigated by several factors: >>>>>> >>>>>> >>>>>> - >>>>>> >>>>>> Strictly Additive & Feature Detectable: The feature consists >>>>>> entirely of new methods on TextMetrics (getSelectionRects(), >>>>>> getActualBoundingBox(), getTextClusters(), getIndexFromOffset()) and >>>>>> CanvasRenderingContext2D (fillTextCluster(), strokeTextCluster()). >>>>>> Existing >>>>>> Canvas behavior is completely unaffected. Developers can trivially >>>>>> feature-detect support (e.g., 'getTextClusters' in >>>>>> TextMetrics.prototype) >>>>>> and maintain existing DOM-based fallbacks on non-supporting browsers. >>>>>> - >>>>>> >>>>>> Standard String Semantics: All index and range inputs/outputs >>>>>> (start, end, and hit-test results) are explicitly specified as 0-based >>>>>> UTF-16 code units, aligning with ECMAScript string operations, DOM >>>>>> Range/Selection, and Intl.Segmenter. >>>>>> - >>>>>> >>>>>> Future Extensibility: If cross-engine consensus converges on >>>>>> higher-level formatting abstractions (e.g., multi-style TextLine or >>>>>> ShapedText) in the future, these low-level cluster and selection >>>>>> primitives >>>>>> can cleanly coexist as foundational shaping utilities without creating >>>>>> backwards-incompatible syntax collisions. >>>>>> >>>>>> >>>>>> Compatibility Risk: None. >>>>>> >>>>>> The changes are entirely additive and introduce no breaking changes >>>>>> to existing Canvas 2D measurement or rendering behavior. >>>>>> >>>>>> Gecko: No signal ( >>>>>> https://github.com/mozilla/standards-positions/issues/1144) >>>>>> >>>>>> WebKit: Negative ( >>>>>> https://github.com/WebKit/standards-positions/issues/436) >>>>>> >>>>>> WebKit supports the general problem space (enabling canvas text >>>>>> shaping, cluster rendering, and selection) but has expressed reservations >>>>>> regarding the specific API design in this proposal (see WHATWG issue >>>>>> #10677). Specifically, WebKit prefers exploring an alternative, >>>>>> line-level >>>>>> abstraction (e.g., TextLine) to handle multi-style text and BiDi >>>>>> interleaving, rather than extending TextMetrics. >>>>>> >>>>>> Web developers: Positive >>>>>> >>>>>> There is strong demand from canvas-heavy frameworks and applications >>>>>> that implement custom text layout and text editing. Canvas text rendering >>>>>> currently suffers from significant performance and memory overhead >>>>>> because >>>>>> applications are forced to synchronize offscreen DOM elements just to >>>>>> measure selection rectangles, bounding boxes, and caret positions. Key >>>>>> validation from the ~8-month Origin Trial: >>>>>> >>>>>> - >>>>>> >>>>>> Flutter Web: Integrated and validated the API in their production >>>>>> engine (WebParagraph) throughout the Origin Trial. They rely on >>>>>> getTextClusters() and getSelectionRects() to drive their web text >>>>>> layout >>>>>> and hit-testing, and are strongly advocating for shipping this >>>>>> capability. >>>>>> - >>>>>> >>>>>> Canvas Tooling & Creative Coding: Successfully demonstrated in >>>>>> complex single-line typography scenarios, such as interactive >>>>>> text-on-a-path editors and per-glyph animations, without requiring >>>>>> DOM-based synchronization. >>>>>> >>>>>> >>>>>> Other signals: >>>>>> >>>>>> Ergonomics >>>>>> >>>>>> None. >>>>>> >>>>>> Activation >>>>>> >>>>>> None. >>>>>> >>>>>> Security >>>>>> >>>>>> There is always a fingerprinting concern with HTML canvas. The new >>>>>> features expose no novel fingerprinting surface (text metrics are >>>>>> already a >>>>>> fingerprinting concern). >>>>>> >>>>>> WebView application risks >>>>>> >>>>>> Does this intent deprecate or change behavior of existing APIs, such >>>>>> that it has potentially high risk for Android WebView-based applications? >>>>>> >>>>>> No information provided >>>>>> >>>>>> >>>>>> Debuggability >>>>>> >>>>>> DevTools supports querying the APIs by default. >>>>>> >>>>>> Will this feature be supported on all six Blink platforms (Windows, >>>>>> Mac, Linux, ChromeOS, Android, and Android WebView)? >>>>>> >>>>>> Yes >>>>>> >>>>>> Is this feature fully tested by web-platform-tests >>>>>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> >>>>>> ? >>>>>> >>>>>> Yes >>>>>> >>>>>> html/canvas/[element|offscreen]/text... >>>>>> 2d.text.measure.index-from-offset* 2d.text.measure.selection-rects* >>>>>> 2d.text.measure.text-clusters* >>>>>> https://wpt.fyi/results/html/canvas/element/text?label=master&label=experimental&aligned&q=tentative >>>>>> https://wpt.fyi/results/html/canvas/offscreen/text?label=master&label=experimental&aligned&q=tentative >>>>>> >>>>>> Flag name on about://flags >>>>>> >>>>>> Experimental Web Platform Features >>>>>> >>>>>> Finch feature name >>>>>> >>>>>> ExtendedTextMetrics >>>>>> >>>>>> Rollout plan >>>>>> >>>>>> Will ship enabled for all users >>>>>> >>>>>> Requires code in //chrome? >>>>>> >>>>>> False >>>>>> >>>>>> Tracking bug >>>>>> >>>>>> https://issues.chromium.org/issues/341213359 >>>>>> >>>>>> Measurement >>>>>> >>>>>> Usage is tracked via the Blink UseCounter >>>>>> WebFeature::kExtendedTextMetrics (ID: 5729). >>>>>> >>>>>> Estimated milestones >>>>>> >>>>>> Shipping on desktop >>>>>> >>>>>> 156 >>>>>> >>>>>> Origin trial desktop first >>>>>> >>>>>> 144 >>>>>> >>>>>> Origin trial desktop last >>>>>> >>>>>> 149 >>>>>> >>>>>> Origin trial extension 1 end milestone >>>>>> >>>>>> 152 >>>>>> >>>>>> DevTrial on desktop >>>>>> >>>>>> 141 >>>>>> >>>>>> Shipping on Android >>>>>> >>>>>> 156 >>>>>> >>>>>> Origin trial Android first >>>>>> >>>>>> 144 >>>>>> >>>>>> Origin trial Android last >>>>>> >>>>>> 149 >>>>>> >>>>>> DevTrial on Android >>>>>> >>>>>> 141 >>>>>> >>>>>> Shipping on WebView >>>>>> >>>>>> 156 >>>>>> >>>>>> >>>>>> Anticipated spec changes >>>>>> >>>>>> There are stalled discussions in WHATWG regarding the long-term >>>>>> evolution of Canvas text styling and line layout: >>>>>> >>>>>> - >>>>>> >>>>>> https://github.com/whatwg/html/pull/11000 >>>>>> - >>>>>> >>>>>> https://github.com/whatwg/html/issues/10677 >>>>>> >>>>>> >>>>>> Potential Future Evolution & Compatibility Assessment: >>>>>> >>>>>> 1. >>>>>> >>>>>> Higher-Level Line Abstractions: WebKit has expressed interest in >>>>>> eventually standardizing a higher-level, multi-style line abstraction >>>>>> (e.g., a TextLine or dedicated shaping object). If the web >>>>>> standards community converges on such an API in the future, we >>>>>> anticipate >>>>>> it will be strictly additive, introducing new interfaces rather >>>>>> than altering or removing the TextMetrics methods being shipped >>>>>> here. >>>>>> 2. >>>>>> >>>>>> Low-Level Coexistence: The cluster inspection (getTextClusters), >>>>>> range selection (getSelectionRects, getActualBoundingBox), and >>>>>> hit-testing (getIndexFromOffset) primitives shipped in this >>>>>> release serve as foundational, single-style shaping queries. They can >>>>>> cleanly coexist alongside any future line-formatting abstractions. >>>>>> >>>>>> Conclusion on Compat Risk: >>>>>> We do not anticipate any non-backward-compatible changes to the >>>>>> proposed API surface. If future standards work introduces an alternative >>>>>> design favored by developers, the current API will either remain as a >>>>>> low-level building block or follow the standard deprecation process if >>>>>> ever >>>>>> superseded. >>>>>> >>>>>> >>>>>> Link to entry on the Chrome Platform Status >>>>>> >>>>>> >>>>>> https://chromestatus.com/feature/5075532483657728?gate=5118769432887296 >>>>>> >>>>>> Links to previous Intent discussions >>>>>> >>>>>> Intent to Prototype: >>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADgYMVdqo4PBs4OkGqVncRizs8vtX4YtFLDcK%2BRxdYo_wnaRJQ%40mail.gmail.com >>>>>> >>>>>> Ready for Trial: >>>>>> https://groups.google.com/a/chromium.org/g/blink-dev/c/OLCCI0ExvIk >>>>>> >>>>>> Intent to Experiment: >>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADgYMVfC-Naw8pFVaUUPMSfW-u3kC7SMdDeHJgwU5YmSHOOeeA%40mail.gmail.com >>>>>> >>>>>> Intent to Extend Experiment 1: >>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADgYMVfjd5mbDkm16_Xf4fxfnrEeiAXLhjiBCXWik0GaNJGE2Q%40mail.gmail.com >>>>>> >>>>>> >>>>>> This intent message was generated by Chrome Platform Status >>>>>> <https://chromestatus.com/>. >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>> You received this message because you are subscribed to the Google >>>>> Groups "blink-dev" group. >>>>> To unsubscribe from this group and stop receiving emails from it, send >>>>> an email to [email protected]. >>>>> To view this discussion visit >>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/02084c06-53d9-4257-b947-1367d706c41cn%40chromium.org >>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/02084c06-53d9-4257-b947-1367d706c41cn%40chromium.org?utm_medium=email&utm_source=footer> >>>>> . >>>>> >>>> -- >> You received this message because you are subscribed to the Google Groups >> "blink-dev" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> To view this discussion visit >> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY_N0pZd%3DHeYo%3DR%3DPPyf1Mu-eYYB5naVB9K9%2BCOsGXfnGg%40mail.gmail.com >> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY_N0pZd%3DHeYo%3DR%3DPPyf1Mu-eYYB5naVB9K9%2BCOsGXfnGg%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> > -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGsbWzQvADnXTAWsbt%2BiSCnLYrhN7wezEZhedMuHZKei4zLqnA%40mail.gmail.com.
