https://github.com/webcompat/web-bugs/issues/23877 reports that parkrun.com is broken because we have parts of these APIs still (they have a polyfill and some other methods that are defined on the prototype of SVGPathSegList, but only if SVGPathSegList doesn't exist.

Do we have finishing out this bug on our radar, jwatt?

(In reply to Mike Taylor [:miketaylr] from comment #38)

Do we have finishing out this bug on our radar, jwatt?

Comment 34 isn't easy to solve. However newer versions of the polyfill in comment 36 do work with Firefox, can't parkrun.com use that polyfill?

I've emailed them to ask if they can update to the latest version of their polyfill.

Mike, did they get back to you?

(In reply to Jonathan Watt [:jwatt] from comment #41)

Mike, did they get back to you?

Not yet (which doesn't really suprise me). And I just verified they didn't update the polyfill in question.

Adam, do you think you could try to find a better contact (than their contact form)?

Let's try their founder and the head of communications on LinkedIn.

Migrating Webcompat whiteboard priorities to project flags. See bug 1547409.

See bug 1547409. Migrating whiteboard priority tags to program flags.

(In reply to Mike Taylor [:miketaylr] from comment #37)

https://github.com/webcompat/web-bugs/issues/23877 reports that parkrun.com is broken because we have parts of these APIs still (they have a polyfill and some other methods that are defined on the prototype of SVGPathSegList, but only if SVGPathSegList doesn't exist.

Ciprian checked in again on that issue and it has been fixed.

(In reply to Robert Longson [:longsonr] from comment #34)

There is one other problem with this. Chrome have changed their SMIL implementation so that it updates attributes, we haven't. Once we do this there will be no way to access SMIL animated values, this is not the case in Chrome if you use the polyfill.

Might be worth checking whether this is still the case, or filing an crbug.com issue asking them to consider not doing that, since it's clearly not spec conforming.

(In reply to Cameron McCormack (:heycam) from comment #47)

(In reply to Robert Longson [:longsonr] from comment #34)

There is one other problem with this. Chrome have changed their SMIL implementation so that it updates attributes, we haven't. Once we do this there will be no way to access SMIL animated values, this is not the case in Chrome if you use the polyfill.

Might be worth checking whether this is still the case, or filing an crbug.com issue asking them to consider not doing that, since it's clearly not spec conforming.

Gecko doesn't update the attribute for SMIL, but we map the d attribute to CSS d property, so if SMIL updates the d attribute, it should also update the CSS d property as well, and so it's still possible to get the SMIL animated values by the CSSOM (e.g. getComputedStyle(div).d). This bug blocks Bug 1744599, so I would like to finish this bug first. If we would like to do a similar thing as Chrome, how about filing a separate bug to change the SMIL implementation so we also update attributes?

We should check first that Chrome still does work that way. It's been 4 years, they may have changed.

(In reply to Robert Longson [:longsonr] from comment #49)

We should check first that Chrome still does work that way. It's been 4 years, they may have changed.

I did a quick check by <animate>:

<svg viewBox="0 0 20 10">
  <path fill="none" stroke="lightgrey" d="M2,5 H 10 Z" id="animTarget">
    <animate attributeName="d"
             from="M2,5 H5Z" to="M2,5 H15Z"
             dur="2s"
             repeatCount="2" />
  </path>
</svg>

And dump the log by things like this:

    window.setTimeout(()=>{
      console.log("style: " + window.getComputedStyle(animTarget).d);
      console.log("attr:  " + animTarget.getAttribute("d"));
    }, 1000);

At 1s, the CSS d property is "path("M 2 5 H 9.98042 Z")", and the SVG d attribute is still "M2,5 H 10 Z". Does this mean Chrome doesn't update the attribute anymore or do I use the wrong way? Thanks.

As far as I remember (it was 4 years ago) that's roughly what I was doing so I guess they don't and we can stop worrying about that. We just need to ensure that we do what Chrome does now.

(In reply to Robert Longson [:longsonr] from comment #51)

As far as I remember (it was 4 years ago) that's roughly what I was doing so I guess they don't and we can stop worrying about that. We just need to ensure that we do what Chrome does now.

Thanks for these feedback. Let me drop these APIs. :)

This patch removes the following APIs:

1. SVGAnimatedPathData
2. SVGPathSeg
3. SVGPathSegList
4. SVGPathElement::getPathSegAtLength()

Basically, I would like to keep these tests, and change the way to check
the d property. However, the path strings returned from d propety are
complicated, so we need a better way to parse the path string and check
if it goes through the vertices we expected. Now we mark these tests
failed, and leave them in Bug 1745060.

Note: the patch should be merged into the previous one, but I use a
separate patch for review. Will merge this into the previous one once we
get accepted.

https://hg.mozilla.org/mozilla-central/rev/78dad725f8a2

FF97 Docs work for this can be tracked in https://github.com/mdn/content/issues/11597

Can you please confirm what is affected by this change? By inspection of IDL I think it just the following that are hidden behind dom.svg.pathSeg.enabled:

• SVGPathSegList (including .numberOfItems, getItem() and length.
• SVGPathElement.getPathSegAtLength()
• SVGAnimatedPathData .pathSegList and .animatedPathSegList

Is that the full set?

Further MDN lists the following Seg APIs but does not document them. The show up in searchfox, but I just want to make sure that they are still something we should mention/evetually document
SVGPathSeg, SVGPathSegClosePath, SVGPathSegMovetoAbs, SVGPathSegMovetoRel, SVGPathSegLinetoAbs, SVGPathSegLinetoRel, SVGPathSegCurvetoCubicAbs, SVGPathSegCurvetoCubicRel, SVGPathSegCurvetoQuadraticAbs, SVGPathSegCurvetoQuadraticRel, SVGPathSegArcAbs
SVGPathSegArcRel, SVGPathSegLinetoHorizontalAbs, SVGPathSegLinetoHorizontalRel , SVGPathSegLinetoVerticalAbs, SVGPathSegLinetoVerticalRel
SVGPathSegCurvetoCubicSmoothAbs, SVGPathSegCurvetoCubicSmoothRel, SVGPathSegCurvetoQuadraticSmoothAbs, SVGPathSegCurvetoQuadraticSmoothRel, SVGPathSegList,

(In reply to Angelo Borsotti from comment #61)

(In reply to Jonathan Watt [:jwatt] from comment #10)

(In reply to itsupport from comment #9)

Why remove support and break existing pages, just because the Chrome
developers were short-sighted enough to do so?

Because it adds significant complexity to the implementation of SVG <path>,
and because something like 1 in 10,000,000 pages were using it according to
their metrics. They were simply making a pragmatic decision.

I wonder how you can tell that there is only one such page.

Chrome collects anonymized usage stats from the wild, you can see some here: https://chromestatus.com/metrics/feature/popularity

But, even supposing so, suppose that is a page needed in a surgery hospital,
or in a nuclear plant, does that "pragmatic decision" take into account the
damage of breaking it? I guess that such decisions should take all the
consequences into account, and not only the bare usage statistics.

Absolutely that's a consideration, we call that "ease of adaptation" - https://bit.ly/blink-compat. In this case we provided a JavaScript library that worked perfectly as a drop-in replacement in every case we found: https://groups.google.com/a/chromium.org/g/blink-dev/c/EDC3cBg9mCU/m/LDYo5CjfBAAJ

I searched the web for a replacement, and did not find the one mentioned in the Google groups you indicated:
https://groups.google.com/a/chromium.org/g/blink-dev/c/EDC3cBg9mCU/m/LDYo5CjfBAAJ

The only one that one gets from google search is the path-data-polyfill.js, which is an implementation
of the new SVG API: SVGPathData.
This requires to change the existing js code.

If you did not point me to that google group I would have never known that there is such a replacement.

P.S for the ones that have the same problem, the replacement seems to be in:
https://github.com/progers/pathseg/blob/master/pathseg.js

(In reply to Angelo Borsotti from comment #63)

I searched the web for a replacement, and did not find the one mentioned in the Google groups you indicated:
https://groups.google.com/a/chromium.org/g/blink-dev/c/EDC3cBg9mCU/m/LDYo5CjfBAAJ

The only one that one gets from google search is the path-data-polyfill.js, which is an implementation
of the new SVG API: SVGPathData.
This requires to change the existing js code.

If you did not point me to that google group I would have never known that there is such a replacement.

P.S for the ones that have the same problem, the replacement seems to be in:
https://github.com/progers/pathseg/blob/master/pathseg.js

It's a good point that we should probably do more to make this findable, thanks for the feedback. But also note that I provided the GitHub URL in the opening comment of this issue :-)