Can you ask for a review on the "adoption" checkbox? 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.
