Re: PathSeg interface

I'm okay with removing if it gets replaced with something simpler.  Your
proposal looks good.


> * is there a need for having a canvas-like pathbuilding API,

I don't have a strong opinion either way on this.  Although I guess it
would be nice if there was a parallel API.


> * is there a need for the full name of each pathseg type?

I think just the letter would be fine.  It's a concept people are very
familiar with.


> * which important use-cases does the draft API not address?

I'm not very familiar with how WebIDL constructs map to JS.  Does a
sequence<T> map to an array, or something similar to an HTMLCollection?  I
imagine people would like to be able to concat(), splice(), push() etc.


Paul



On 17 February 2015 at 03:53, Erik Dahlström <ed@opera.com> wrote:

> Hello lovers of PathSegList :)
>
> I'm sympathetic to the arguments put forward in this thread, but I would
> like to understand the actual use-cases better.
>
> Also, there seems to be some confusion over what a UseCounter is, so let's
> see if I can clarify that bit first:
>
> A UseCounter measures the usage of a given feature on pages loaded in
> Chrome where the user has opted in to sharing the UseCounter data. Nothing
> says that just because it shows zero usage there aren't pages out there
> that use the given feature.
>
> Now, on to the main reasons for wanting to remove these interfaces:
>
> * the animatedNormalizedPathSegList and normalizedPathSegList accessors
> lack implementations
> * the combined measured actual usage is very low according to Chrome's
> UseCounter data
> * they force "live" synchronization (which is expensive and complex)
> * they're verbose (due to the many interfaces) and cumbersome to use in
> script
>
> Assuming we want to have a new API, here's a draft for an API that could
> replace the existing one:
>
> [NoInterfaceObject]
> interface SVGPathSegment {
>   DOMString type; // this would be e.g 'M', 'c', 'L' and so on
>   sequence<float> values;
> };
>
> dictionary SVGPathDataSettings {
>   boolean normalize = false;
> }
>
> [NoInterfaceObject]
> interface SVGPathData {
>   sequence<SVGPathSegment> getPathData(optional SVGPathDataSettings
> settings);
>   void setPathData(sequence<SVGPathSegment> pathData);
> };
>
> SVGPathElement implements SVGPathData;
>
>
> Some benefits of the draft API:
>
> * simpler interface which provides easier data manipulation/inspection due
> to not having differences in the various pathseg interfaces
> * it removes the "live" synchronization between the various lists
> * offers a way to implement a rudimentary polyfill for the old interfaces
> using the new API (I've intentionally excluded the animation aspect)
>
> Questions:
>
> * if there is a need for the animated state, would it be sufficient to
> have a path "blending" method instead, that takes two SVGPathData objects
> and a blend-value between 0 and 1 for getting a new SVGPathData object at
> the given point (where 0 means return path A and 1 means return path B, and
> anything in between is an interpolated path C)?
> * is there a need for having a canvas-like pathbuilding API, or would the
> draft interface presented above be sufficient?
> * is there a need for the full name of each pathseg type? most scripts
> I've seen only switch on the type, so what is there doesn't really matter.
> Scripts could easily provide this if needed.
> * which important use-cases does the draft API not address?
>
>
>
>
> On Fri, 13 Feb 2015 17:20:49 +0100, Jelle Mulder <
> jelle.mulder2@outlook.com> wrote:
>
>  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.
>>>
>>
>>
>
>
> --
> Erik Dahlstrom, Web Technology Developer, Opera Software
> Co-Chair, W3C SVG Working Group
>
>