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/CADgYMVeN2Z2_VqySk17jjXR33wPcEXv1kMPQ-Am69_B7hAXuWw%40mail.gmail.com.
