> Out of curiosity, how are the ellptical arc path commands converted to M, L, C and Z? The spec doesn't say anything about the necessary approximation.
I filed a SVG spec issue <https://github.com/w3c/svgwg/issues/1227>for this omission. I'll follow up with a spec PR soon. The WPTs cover path normalization <https://wpt.fyi/results/svg/path/interfaces/getPathData-normalize.html?label=experimental&label=master&aligned>, which both Firefox and Chromium pass. In Chromium, SVGPathNormalizer::EmitSegment() <https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/core/svg/svg_path_parser.cc;drc=689c4fe9f23645596a2c5cfba414cad67fd5d7c9;l=145> decomposes the arc to a cubic bezier using this note in the SVG spec <https://www.w3.org/TR/SVG/implnote.html#ArcConversionEndpointToCenter>. On Monday, October 26, 2026 at 3:54:53 PM UTC-7 Stephen Chenney wrote: > On Wed, Oct 21, 2026 at 12:43 PM Chromestatus < > [email protected]> wrote: > >> *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. > > > Out of curiosity, how are the ellptical arc path commands converted to M, > L, C and Z? The spec doesn't say anything about the necessary approximation. > > >> *Blink component* >> Blink>SVG >> <https://issues.chromium.org/issues?q=customfield1222907:%22Blink%3ESVG%22> >> >> *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 >> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>?* >> 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 (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). >> 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 >> <https://chromestatus.com>. >> >> -- >> 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 >> >> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/6ad8eba6.a6e82b8f.de7e0.01e9.GAE%40google.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/5f8b55e3-9671-4f54-b56d-8ebe4981eb94n%40chromium.org.
