RE: PathSeg interface

In response apparently to WG’s recent minutes 

> RESOLUTION: Drop the SVGPathSeg* interfaces if Erik verifies
   the use counter values are correct

 

Paul LeBeau writes

>I'm surprised it is zero - even though the API interface is a bit unwieldy and has only very basic support from the browsers.

[…]

>Do we really expect users to write their own d attribute parsers?

 

I probably would have used it, if I knew how to, and if someone had developed an example showing how it is used. Back when people were still working on all the cool, useful (indeed necessary) things of SVG1.2, I was very excited to see that <superpath>’s basic functionality was in the spec from Chris Lilley’s examples for vector effects. I had read the bit of the spec that discussed vector effects and didn’t realize until Chris explained it further that that was what it was. I have had to write many a flawed parser for the d attribute in paths. Truth is: I didn’t know these things pathSegList and animatedPathSegList existed. 

 

Using counter values as a way of justifying not implementing or deprecating things is chicken and egg-like. If browsers refuse to implement things,  if people don’t know what they are, it’s rather hard for those who might use them to want to try.  Not requiring everyone to write their own path parsing and <superpath> are all things that people have wanted for more than a decade. 

 

Cheers

David