LGTM2, pending the same reviews Philip mentioned. On Friday, February 6, 2026 at 2:24:43 AM UTC-8 Philip Jägenstedt wrote:
> Oh, can you also please request the > privacy/security/enterprise/debuggability/testing reviews in chromestatus? > I will set my approved bit so I don't forgot, but this needs to be done > before 3xLGTM and shipping. Thank you! > > On Fri, Feb 6, 2026 at 11:21 AM Philip Jägenstedt <[email protected]> > wrote: > >> LGTM1, seems like a straightforward improvement! >> >> Notably https://bugzilla.mozilla.org/show_bug.cgi?id=1446617 says >> "Closed 7 years ago" and it's great to close the gap on these things. >> >> On Thu, Feb 5, 2026 at 6:57 AM 'Virali Purbey' via blink-dev < >> [email protected]> wrote: >> >>> Hi all, >>> >>> >>> >>> Sharing my I2S for review. Please have a look. >>> >>> Thanks, >>> Virali >>> >>> >>> >>> *Contact emails* >>> >>> [email protected] >>> >>> >>> >>> *Specification* >>> >>> https://svgwg.org/svg2-draft/text.html#TextPathElement >>> >>> >>> >>> *Summary* >>> >>> This change adds support for the path attribute on the SVG <textPath> >>> element, allowing authors to define text path geometry inline using SVG >>> path data and reducing the need for separately defined <path> elements. >>> >>> >>> >>> <textPath> resolves its text path geometry using the following rules: >>> >>> >>> >>> 1. If both path and href are present, geometry is resolved from the path >>> attribute. >>> >>> 2. If only the path attribute is present and parses successfully, the >>> inline path definition is used. >>> >>> 3. If the path attribute is absent or fails to parse, and an href >>> attribute is provided, the referenced <path> element is used as a fallback. >>> >>> 4. Existing href‑only behavior is preserved without change. >>> >>> >>> >>> This implementation follows the SVG 2 specification’s definition of the >>> path attribute on <textPath>, and the resolution behavior is consistent >>> with other browser engines, improving interoperability and standards >>> compliance. >>> >>> >>> >>> Note: When both path and href are specified on <textPath>, path now >>> takes precedence, per SVG 2 specification. >>> >>> >>> >>> *Blink component* >>> >>> Blink>SVG >>> <https://issues.chromium.org/issues?q=customfield1222907:%22Blink%3ESVG%22> >>> >>> >>> >>> *Web Feature ID* >>> >>> svg <https://webstatus.dev/features/svg> >>> >>> >>> >>> *Motivation* >>> >>> Before this change, Chromium required <textPath> to reference a separate >>> <path> element via href in order to define text path geometry. While >>> functional, this limitation diverged from the SVG 2 specification and from >>> behavior in other browser engines that support inline path data via the >>> path attribute. As a result, SVG content authored for cross‑browser >>> compatibility frequently rendered incorrectly in Chromium or required >>> duplicating path definitions solely to accommodate Chromium’s lack of >>> support. >>> >>> >>> >>> Supporting the path attribute allows authors to define self‑contained >>> text‑on‑path geometry directly on <textPath>, reducing DOM indirection and >>> improving authoring ergonomics without changing existing href‑based >>> behavior. This aligns Chromium’s behavior with the SVG specification and >>> other engines, eliminates a known source of interoperability issues, and >>> reduces the need for browser‑specific workarounds in real‑world SVG content. >>> >>> >>> >>> *Initial public proposal* >>> >>> *No information provided* >>> >>> >>> >>> *TAG review* >>> >>> Not requested. This change implements an existing SVG 2 feature and does >>> not introduce new web‑exposed APIs or primitives. >>> >>> >>> >>> *TAG review status* >>> >>> Not applicable >>> >>> >>> >>> *Risks* >>> >>> >>> >>> *Interoperability and Compatibility* >>> >>> Behavior change risk: >>> >>> Previously, Chromium ignored the path attribute on <textPath> and always >>> resolved text geometry via href. With this change, when both path and href >>> are specified, the path attribute takes precedence, per the SVG 2 >>> specification. As a result, some existing SVG content that relied on href >>> may render differently post‑ship. This aligns Chromium with other browser >>> engines and improves standards compliance. >>> >>> >>> >>> Mitigation: The feature is guarded by a Finch flag >>> (SvgTextPathPathAttributeEnabled), which can be used as a kill‑switch if >>> unexpected compatibility issues arise. >>> >>> >>> >>> *Gecko*: Shipped/Shipping ( >>> https://bugzilla.mozilla.org/show_bug.cgi?id=1446617) >>> >>> >>> >>> *WebKit*: No signal ( >>> https://github.com/WebKit/standards-positions/issues/606) >>> >>> >>> >>> *Web developers*: Positive >>> >>> One user has noted they are impacted by the CrBug. >>> >>> >>> >>> *Other signals*: >>> >>> >>> >>> *Security* >>> >>> This feature does not introduce new script‑accessible APIs, cross‑origin >>> capabilities, or user‑exposed surface area. It enables use of inline SVG >>> path data in a context that already accepts path geometry via referenced >>> <path> elements. The same SVG path parsing and rendering logic already >>> exercised by <path> elements is reused for the path attribute on >>> <textPath>. No additional memory exposure, network access, or privilege >>> changes are introduced. >>> >>> >>> >>> *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. >>> >>> This change does not deprecate or modify existing APIs. It adds support >>> for a previously unsupported SVG attribute and preserves existing href‑only >>> behavior. >>> >>> >>> >>> *Debuggability* >>> >>> Issues related to this feature are debuggable using existing SVG and DOM >>> inspection tools. The resolved path used by <textPath> can be inspected via >>> the DOM and verified through rendered output. Invalid inline path values >>> gracefully fall back to href, avoiding hard failures and making rendering >>> issues visible rather than silent. No new debugging tooling is required. >>> >>> >>> >>> *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 >>> >>> https://wpt.fyi/results/svg/text/reftests/textpath-path-attr.svg >>> >>> >>> https://wpt.fyi/results/svg/text/reftests/textpath-path-attr-invalid-path-fallback.svg >>> >>> >>> >>> >>> https://wpt.fyi/results/svg/text/reftests/textpath-path-attr-precedence-over-href.svg >>> >>> >>> >>> *Flag name on about://flags* >>> >>> *No information provided* >>> >>> >>> >>> *Finch feature name* >>> >>> SvgTextPathPathAttributeEnabled >>> >>> >>> >>> *Rollout plan* >>> >>> Will ship enabled for all users >>> >>> >>> >>> *Requires code in //chrome?* >>> >>> False >>> >>> >>> >>> *Tracking bug* >>> >>> https://issues.chromium.org/issues/374010056 >>> >>> >>> >>> *Estimated milestones* >>> >>> Shipping on desktop >>> >>> 146 >>> >>> Shipping on Android >>> >>> 146 >>> >>> Shipping on WebView >>> >>> 146 >>> >>> >>> >>> *Anticipated spec changes* >>> >>> *Open questions about a feature may be a source of future web compat or >>> interop issues. Please list open issues (e.g. links to known github issues >>> in the project for the feature specification) whose resolution may >>> introduce web compat/interop risk (e.g., changing to naming or structure of >>> the API in a non-backward-compatible way).* >>> >>> There is an open discussion in the SVG Working Group regarding >>> validation requirements for the path attribute on <textPath>, specifically >>> whether the entire path data must be valid in order for the attribute to be >>> used: https://github.com/w3c/svgwg/issues/393 >>> >>> >>> >>> The current implementation follows the SVG 2 specification as written >>> and aligns with existing behavior in other engines. If the resolution of >>> this issue results in clarified or changed requirements around partial path >>> validity, minor behavior adjustments may be required in the future. At >>> present, no concrete spec changes have been adopted. >>> >>> >>> >>> *Link to entry on the Chrome Platform Status* >>> >>> https://chromestatus.com/feature/5157546589552640?gate=6533295938600960 >>> >>> >>> >>> This intent message was generated by Chrome Platform Status >>> <https://chromestatus.com/>. >>> >>> >>> >>> *From >>> <https://chromestatus.com/feature/5157546589552640/gate/6533295938600960/intent >>> >>> <https://chromestatus.com/feature/5157546589552640/gate/6533295938600960/intent>> >>> >>> * >>> >>> >>> >>> -- >>> 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/KUYP153MB1117D04BB5474CCF72F81DFAC199A%40KUYP153MB1117.APCP153.PROD.OUTLOOK.COM >>> >>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/KUYP153MB1117D04BB5474CCF72F81DFAC199A%40KUYP153MB1117.APCP153.PROD.OUTLOOK.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/54f40bbb-3d19-4546-8897-4fa0b36800fdn%40chromium.org.
