Intent to deprecate and remove SVGPathElement.getPathSegAtLength

Skip to first unread message


Apr 17, 2017, 1:44:12 AM4/17/17
to blink-dev

Primary eng (and PM) emails


Intent to deprecate and remove SVGPathElement.getPathSegAtLength.



This interface is removed from the spec.


Compatibility Risk

This interface should probably have been removed as part of the pathSegList , since it's not very useful without it. There are only 15 hits for this interface in httparchive, making it quite likely that usage will be very low.


Alternative implementation suggestion for web developers



Usage information from UseCounter

None. Usecounter is added recently.


OWP launch tracking bug


Entry on the feature dashboard


Requesting approval to remove too?

Yes. The plan is to show deprecation message and count in M60 and do removal in M62.

Rick Byers

Apr 17, 2017, 3:52:20 AM4/17/17
to Shanmuga, blink-dev
Given that this API is basically useless now (returns an index into an array that no longer exists) removal seems extremely low risk.  Still, given the httpArchive results, a deprecation warning (and double-checking the UseCounter) seems valuable.


Philip Jägenstedt

Apr 17, 2017, 3:58:15 AM4/17/17
to Rick Byers, Shanmuga, blink-dev
15 is a fairly small number in httparchive, so direct removal might have worked out, but there's no urgency here I think. LGTM2 for plan as stated.

Apr 17, 2017, 10:18:52 AM4/17/17
to blink-dev
My first reaction is surprise to discover that it wasn't removed along with the rest of the PathSeg interfaces.  As others have said, this method is kind of useless on its own.

However, two points:

- there is a polyfill (aka "deprefill") for the removed interfaces, which does not currently polyfill this method:

- there was a planned replacement/simplification for the replaced interfaces, which re-introduces this method to the SVGPathElement interface ( Unfortunately, interest in spec'ing and implementing the replacement lagged behind interest in removing the deprecated version. A polyfill (aka "prolyfill") for the proposal does not currently replace the getPathSegmentAtLength method (

I personally was very disappointed that SVG 2 was published with the old methods removed, without having the new methods in the same spec.  I do not know when or if we will get implementer interest in working on that spec.  So as much as I'd like to, I can't argue against removal based on the fact that you'll just have to re-implement it right afterwards.

At the very least, however, please make sure that the maintainers of those polyfills are included in the discussion, so they can provide a replacement for this method before it is removed.


Chris Harrelson

Apr 17, 2017, 11:09:48 AM4/17/17
to, blink-dev

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

Philip Rogers

Apr 17, 2017, 2:32:52 PM4/17/17
to Chris Harrelson, Amelia Bellamy-Royds, blink-dev,
I've filed for implementing this in the pathseg polyfill but it's somewhat difficult to implement because it requires the distance-along-a-path algorithm.

Looking at the 13 results on httparchive (as of April 1st '17), I see two main users of this API:
1) uses matter-js which calls this API ( Matter-js already uses the pathseg polyfill so we could prevent breaking them by implementing this in the polyfill.
2) sie-svg ( which seems to be under active development.

On Mon, Apr 17, 2017 at 8:09 AM, Chris Harrelson <> wrote:

Joe Medley

Apr 17, 2017, 5:30:54 PM4/17/17
to Shanmuga, blink-dev

Chrome for IOS uses webkit, not blink. Can you please remove the version number from that field on Chrome Status.


Joe Medley | Technical Writer, Chrome DevRel | | 816-678-7195
If an API's not documented it doesn't exist.



Apr 18, 2017, 1:53:03 AM4/18/17
to blink-dev,
To unsubscribe from this group and stop receiving emails from it, send an email to

Reply all
Reply to author
0 new messages