Re: PathSeg interface

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

Received on Monday, 16 February 2015 14:54:58 UTC