Intent to Ship: Enhanced Canvas TextMetrics

[Florin Malita]

Contact emails

jlav...@google.com, andres...@chromium.org, fma...@chromium.org, sche...@chromium.org

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

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?

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.

[Yoav Weiss (@Shopify)]

Can you ask for a review on the "adoption" checkbox?

[Rick Byers]

Igalia and Google have been trying to solve real problems for web developers in this space for several years now. While this is far from done, given that we now have at least 2 independent developers who have succeeded with this OT and would like to see it ship, AND given that we're probably nearing the maximum time we'd be comfortable running an OT for this, I feel it would be less bad to ship an imperfect solution which is working for some people here than it would be to let the OT expire. It's great that Apple has now proposed another way to solve this problem, but I don't think it's reasonable for us to start the clock all over and suggest it'll be another year or two until people can deploy their solutions broadly.

At the same time I am very sympathetic to the TAG feedback suggesting we should ship low- and high-level solutions simultaneously to avoid biasing developers toward a low-level one when a high-level one would suffice. @Chris Harrelson does your team have a timeline for when you think you might be able to send an I2S for HTML-in-Canvas? Might it make sense to try to ship both features about the same time?

Rick

[Florin Malita]

On Wed, Sep 9, 2026 at 6:49 AM Yoav Weiss (@Shopify) <yoav...@chromium.org> wrote:

Can you ask for a review on the "adoption" checkbox?

Done, thanks!

--
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 blink-dev+...@chromium.org.
To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/02084c06-53d9-4257-b947-1367d706c41cn%40chromium.org.

[Alex Russell]

LGTM1. Let's make sure we get a Web Feature ID to track it with.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[Rick Byers]

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

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Chris Harrelson]

I also see that WebKit has engaged with an alternate API shape proposal that likely needs consideration.

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.

[Stephen Chenney]

I updated the WHATWG Issue with my findings from comparing the WebKit and Blink proposals. 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.