Re: [svgwg] `getPathSegmentAtLength()`: Define which segment is returned at exact boundary (#1129)

Pardon me, but from a practical dev perspective the current `getPathSegmentAtLength()` API concept itself is of questionable usefulness.   

As a reference I use the only currently existing implementation in Firefox.

###  `path.getPathSegmentAtLength(len)` doesn't return any self contained data
This is a huge problem especially when dealing with **relative path data commands**.
Things obviously, get worse when we're dealing with repetitive patterns – so the **returned segment data is identical to preceding ones**.

#### Proposals
If we understand, `path.getPathSegmentAtLength(len)` as an »extension«  of the proposed standardized native [path data API](https://svgwg.org/specs/paths/#__svg__SVGPathData__getPathData)  it should at least return:  
* a **segment index** – so we can map the segment e.g to a normalized path data segment list
* ideally, the segment's path data as normalized/absolute values
* ... even better if it would also return the previous on-path point with absolute x/y coordinates 

So rather something like this:    
```js   
const segmentdata = 
{
  index: 1, 
  pathData: [ 
    {"type": "M", "values": [0, 50] },
    {"type": "A", "values": [25, 25, 0, 0, 1, 50, 50] }
  ]
}
```

[example codepen](https://codepen.io/herrstrietzel/pen/jEyVejr)  – requires Firefox!

<img width="727" height="658" alt="Image" src="https://github.com/user-attachments/assets/31b8ebcd-4fe1-4cb9-be4f-32f1dc570e67" />  


Including an index and/or the segments pathData is required for pretty much any practical application such as segment highlighting or segment perimeter measurements. Otherwise we only have an »orphaned« command that's just a peace of meta text data.   


### Ambiguities: between two segments?

> [...] exactly on the boundary between two segments

Pardon me again, but from the core concept of SVG commands – always relating to the previous command final on-path coordinates (... wow , even applies to `arc` elliptic commands=) – I'd argue **there is no such thing as »in-between« points/coordinates**.

Therefore I'd argue these »coinciding/in-between« point would clearly be the 1st commands final on-path point and should also be mapped to the 1st *not* the 2nd command.   

As illustrated before the way more severe problem is the lack of data for any practical visual application.  

#### Ambiguities in length approximations
When we're dealing with SVG path manipulations or measurements another problem is the predictability across browsers in regards to length approximations – also significantly affecting the correct segment detection.  
Apart from linetos we mostly need approximations for cubic Béziers and ... thing escalate quickly for the beloved elliptic arcs (circlular arcs are cool=). 

Measure the perimeter of a simple `<circle>` or a `<path>` element using "exact" radii parameters and test it in Firefox vs Chromium.   [See example codepen](https://codepen.io/herrstrietzel/pen/yygVGZd).   

Sure, length difference are to be expected since each browser is using slightly different approximation algorithms
But worth noting, the above example is using the exact same circle properties. With regards to the geometry parameters both SVG elements should return consistent approximations for both primitive and path within the same browser – which is not the case.

While this accuracy issue clearly exceeds the original topic it kinda begs the question whether the SVG spec could or should recommend certain algorithms or minimal accuracies. Most likely, this should be the responsibility of implementers/vendors – however it's worth noting with regards to implementation/rendering tests.








-- 
GitHub Notification of comment by herrstrietzel
Please view or discuss this issue at https://github.com/w3c/svgwg/issues/1129#issuecomment-4725478677 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Wednesday, 17 June 2026 02:58:52 UTC