- From: herrstrietzel via GitHub <sysbot+gh@w3.org>
- Date: Mon, 07 Apr 2025 23:35:49 +0000
- To: public-svg-issues@w3.org
I agree, ideally we should have constructors like `new PathSegment()`. > [...] in similar fashion to DOMPoint.fromPoint() which accepts DOMPoint or point-like object. Not to forget the previously deprecated [`pathSegList` API model.](https://www.w3.org/TR/SVG11/paths.html#InterfaceSVGPathSeg). From a – highly subjective – dev perspective (and also highly speculative): * a more complete interface specification is more likely to be implemented (I'm probably being too romantic ... kudos to Mozilla for making the first step!) * the main benefit of a native/spec-compliant pathData API might actually be to **establish a standardized structure/notation for parsed path data** – similar to defacto standards like point objects (e.g used in `DOMPoint` or the current SVG polygon points property). This ultimately helps to make scripts and libraries more interoperable. Worth noting: this is currently a pretty mess across libraries which unnecessarily complicates interoperability (we have nested arrays, overly descriptive object structures etc. to express path data). Sure, they may already use the SVG2 recommended path data structure – but it's currently rather a neat methodology concept unless it's widely implemented * a native path data parser is obviously appealing as it can take advantage of better "low-level" optimizations – foremost faster execution times (compared to JS parsing) * fortunately, we have some rock-solid parsers (yeah, [jarek-foksa](https://github.com/jarek-foksa) I'm looking at you but also at Vitaly Puzrin =) but it's worth noting we also have quite a few – otherwise excellent libraries – that fail on many highly optimized paths (I mean mainly `a` arc commands) -- GitHub Notification of comment by herrstrietzel Please view or discuss this issue at https://github.com/w3c/svgwg/issues/974#issuecomment-2784862608 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Monday, 7 April 2025 23:35:50 UTC