RE: PathSeg interface

I think this is a definite keeper. Please do not remove. So much has been removed already in order to follow browser implementations rather than setting a spec that might be the next best thing to cheese. This is more an example of unknown makes unloved. Had I known it existed it would have made life quite a bit easier, but before this discussion and the examples of Paul, I'd never seen it used before. It just proves to me that just spec documents are not enough to make lesser gods like me understand what they are all about. In all the books I read about the topic, I've never come across this before whereas it certainly opens up interesting possibilities. Reading specs is often similar to reading law books. Unless you're a lawyer or extremely interested, you don't get it. At first glance it draws a blank. Only when reading a case implementing these laws it becomes understandable for the lay men. If we would apply the same reasoning on applying knowledge of SVG Specs, you'd probably end up near to zero too. How about deprecating the whole spec?  Or all specs for that matter?
> From: phrogz@me.com
> Date: Thu, 12 Feb 2015 19:23:44 -0700
> CC: www-svg@w3.org
> To: paul.lebeau@gmail.com
> Subject: Re: PathSeg interface
> 
> On Feb 12, 2015, at 3:14 AM, Paul LeBeau <paul.lebeau@gmail.com> wrote:
> > > RESOLUTION: Drop the SVGPathSeg* interfaces if Erik verifies
> >    the use counter values are correct
> > 
> > I'm surprised it is zero - even though the API interface is a bit unwieldy and has only very basic support from the browsers.
> 
> I…whaaa? It’s certainly not exactly zero. Here are some of my own pages that use SVGPathSeg:
> http://phrogz.net/svg/animation_on_a_curve.html
> http://phrogz.net/svg/constant-length-bezier.xhtml
> http://phrogz.net/svg/convert_path_to_absolute_commands.svg
> http://phrogz.net/svg/convert_path_to_polygon.xhtml
> http://phrogz.net/svg/convert_polys_to_paths.svg
> http://phrogz.net/svg/draggable-bezier.xhtml
> http://phrogz.net/svg/progressively-cloning-svg-path.html
> http://phrogz.net/svg/transforming_paths.xhtml
> http://phrogz.net/svg/transformations.js
> http://phrogz.net/svg/libraries/SVGPathToPoly.js
> 
> And here are two answers I’ve posted that use it to good effect:
> http://stackoverflow.com/questions/8053487/scripting-path-data-in-svg-reading-and-modifying
> http://stackoverflow.com/questions/9677885/convert-svg-path-to-absolute-commands
> 
> 
> I know, no one likely was suggesting that it was exactly zero. However, this is a useful feature that I have used in the past. I’m quite surprised and skeptical that this is not used.
> 
> I would like to hear a detailed proposal for exactly what would be removed, and what scripters are expected to use in its place. Right now this seems a drastic action that I would personally advocate against.