Re: PathSeg interface

David,

My implementation of superpath has progressed. I think it is usable, now. a
and t commands are not implemented yet, but a lot can be done with other
primitives.

2015-02-12 12:08 GMT+01:00 David Dailey <ddailey@zoominternet.net>:

> 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
>
>
>
>
>