Intent to Prototype - SVG Path Data API
Virali Purbey
Contact emails
Explainer
https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/SVG/SVGPathDataAPI/explainer.md
Specification
https://svgwg.org/specs/paths/#DOMInterfaces
Design docs
https://docs.google.com/document/d/1uCVUqYGKgsCCu7LEtEdO3Yuea-MT-I2XsU6Eoe3mlQI/edit?usp=sharing
Summary
Implement `getPathData()`, `setPathData()`, and `getPathSegmentAtLength()` on `SVGPathElement`, three methods that give developers structured, segment-level access to <path> data as simple ` {type, values} ` dictionaries. A `getPathData({normalize: true}) ` option reduces all commands to the absolute M, L, C, Z subset.
```
dictionary SVGPathSegment {
required DOMString type;
required sequence<unrestricted float> values;
};
dictionary SVGPathDataSettings {
boolean normalize = false;
};
partial interface SVGPathElement {
sequence<SVGPathSegment> getPathData(optional SVGPathDataSettings settings = {});
undefined setPathData(sequence<SVGPathSegment> pathData);
SVGPathSegment? getPathSegmentAtLength(unrestricted float distance);
};
```
Blink component
Web Feature ID
No information provided
Motivation
Web developers working with SVG paths currently have no programmatic way to inspect or manipulate individual path segments in Chrome. The only available interface is the `d` attribute string (e.g., "M 0 0 C 30 90 25 10 50 10"), which requires manual string parsing with regex or third-party libraries to extract segment data. This makes common tasks like path animation, hit-testing, bounding-box calculation, and programmatic path construction unnecessarily complex and error-prone.
The `SVGPathSegList` interface that previously provided structured access was removed from Chromium in M48 (January 2016) due to its complexity - live mutation semantics, 20+ factory methods, and poorly specified edge cases. Since then, developers have relied on polyfills, most notably path-data-polyfill (https://github.com/jarek-foksa/path-data-polyfill), to fill the gap.
The SVG Working Group has since specified a cleaner replacement API in the SVG Paths specification which is what we are looking to implement now. See the explainer for additional details on the improvements made to the API shape.
Initial public proposal
Re: PathSeg interface from Erik Dahlström on 2015-02-16 (www...@w3.org from February 2015)
Goals for experimentation
No information provided
Requires code in //chrome?
False
Tracking bug
https://issues.chromium.org/issues/40441025
Estimated milestones
No milestones specified
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).
A few spec issues have already been agreed upon but are not yet reflected in the spec text (e.g., using `dictionary` instead of `interface`, `unrestricted float`, `required` keywords). We plan to address those as part of the prototyping phase.
Additionally, there are a few open areas, such as CSS `d` property vs. attribute resolution, animated vs. base value semantics, and `getPathSegmentAtLength()` edge-case behavior, where we need to file spec issues and drive consensus in the SVG Working Group before I2S.
Link to entry on the Chrome Platform Status
https://chromestatus.com/feature/4787972240179200?gate=5478126676213760
This intent message was generated by Chrome Platform Status.
From <https://chromestatus.com/feature/4787972240179200/gate/5478126676213760/intent>