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.
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.