Contact emails [email protected], [email protected]
Explainer https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/SVG/SVGPathDataAPI/explainer.md Specification https://w3c.github.io/svgwg/specs/paths/#InterfaceSVGPathData Design docs https://docs.google.com/document/d/1uCVUqYGKgsCCu7LEtEdO3Yuea-MT-I2XsU6Eoe3mlQI/edit?usp=sharing Summary Adds structured JavaScript access to SVG path data through three methods on SVGPathElement: getPathData() reads the path as an array of {type, values} objects containing each segment's command and numeric parameters. setPathData() updates the path from such an array, getPathSegmentAtLength() returns the segment at a specified distance along the path. These methods let developers inspect, edit, and construct paths without manually parsing or serializing the d attribute. The optional getPathData({normalize: true}) setting simplifies path data to absolute move, line, cubic Bézier, and close commands (M, L, C, and Z). All three APIs operate on the base value of the d attribute, not CSS-computed or animated values. Blink component Blink>SVG Web Feature ID No information provided Motivation In Chromium, inspecting or modifying individual SVG path segments requires parsing and serializing the d attribute string, often using third-party libraries. This makes tasks such as path animation, hit-testing, and programmatic path construction unnecessarily complex and error-prone. The previous SVGPathSegList API was removed in Chromium 48 because of its complex live mutation model, numerous factory methods, and underspecified edge cases. Developers have since relied on polyfills to restore structured access. Implementing the SVG Working Group's replacement API provides a simpler, standardized way to read and modify path segments without custom string parsing or polyfills. Initial public proposal No information provided TAG review https://github.com/w3ctag/design-reviews/issues/1292 TAG review status Pending Goals for experimentation Risks Interoperability and Compatibility Low risk. The feature adds new methods to SVGPathElement that developers can feature-detect before use. Representatives from Chromium, Firefox, WebKit, and the web developer community contributed to the API design through the SVG Working Group. Gecko: Shipped/Shipping (https://bugzilla.mozilla.org/show_bug.cgi?id=1934525) Firefox 137 shipped the feature in April 2025. WebKit: No signal (https://github.com/WebKit/standards-positions/issues/731) Web developers: Positive (https://issues.chromium.org/issues/40441025) 45 users upvoted this Chromium issue. A widely used polyfill exists: https://github.com/jarek-foksa/path-data-polyfill Other signals: 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? None. The feature adds new methods to SVGPathElement that developers can feature-detect before use. Debuggability No information provided 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 https://wpt.fyi/results/svg/path/interfaces?label=experimental&label=master&aligned Flag name on about://flags No information provided Finch feature name SVGPathDataAPI Rollout plan Will ship enabled for all users Requires code in //chrome? False Tracking bug https://issues.chromium.org/issues/40441025 Measurement Use counters include: - SVGPathElementGetPathData - SVGPathElementSetPathData -SVGPathElementGetPathSegmentAtLength Availability expectation The feature is available in Chromium and Firefox for the foreseeable future. Microsoft proposed this feature as a focus area for Interop 2027: https://github.com/web-platform-tests/interop/issues/1469, which if accepted, could help extend support to additional browsers. Adoption expectation The feature replaces a popular polyfill that developers use today with thousands of downloads per week. The Chromium issue has 45 votes. Developers have made inquiries, asking when it will become available. Adoption plan MDN already documents this feature. Given the existing developer interest, the feature's adoption should grow organically. Non-OSS dependencies Does the feature depend on any code or APIs outside the Chromium open source repository and its open-source dependencies to function? None. Estimated milestones Shipping on desktop 159 Shipping on Android 159 Shipping on WebView 159 Anticipated spec changes Open questions about a feature may be a source of future web compat or interop issues. Please list open issues (eg links to known github issues in the project for the feature specification) whose resolution may introduce web compat/interop risk (eg, changing to naming or structure of the API in a non-backward-compatible way). None. Representatives from Chromium, Firefox, WebKit, and the web developer community contributed to the API design through the W3C SVG WG. Link to entry on the Chrome Platform Status https://chromestatus.com/feature/4787972240179200?gate=4660848254648320 Links to previous Intent discussions Intent to Prototype: https://groups.google.com/a/chromium.org/d/msgid/blink-dev/KUXP153MB161031AEB43220B1ADB9B41AC1112%40KUXP153MB1610.APCP153.PROD.OUTLOOK.COM This intent message was generated by Chrome Platform Status. -- 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/6ad8eba6.a6e82b8f.de7e0.01e9.GAE%40google.com.
