LGTM3 On Monday, February 9, 2026 at 11:17:56 AM UTC-8 [email protected] wrote:
> 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/fbf84dcd-8b7d-459e-9fa1-cd1274dcc7dfn%40chromium.org.
