[whatwg] Questions regarding Path object

[Ian Hickson]

On Sat, 23 Mar 2013, Jürg Lehni wrote:
> 
> - Paper.js has its own share of classes, and one of them is called Path. 
> We normally run scoped but allow people to inject into the global scope. 
> This would override the new Path constructor.

This was last considered last October:

   http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2012-October/037548.html

My conclusion then was that we didn't have much evidence that Path was 
going to work, but we also didn't have much evidence that it was going to 
be an insurmountable problem.

How much of a problem is the paper.js case?

The name "Path" is generic, but that's kind of the point -- this interface 
might get used by SVG and other contexts, which is why I didn't call it 
CanvasPath, Path2D, or some variant of Shape.


> - I see there are many ways to construct paths from different type of 
> data, and perform manipulations on them. addPathByStrokingPath() and 
> addPathByStrokingText() are both very welcome, for example. Will there 
> be a way to access the resulting path description again, for example as 
> SVG-style pathData? I have not seen a description of any such property 
> on the object, but would strongly suggest that one is added, since 
> having access to the result of such path manipulations would hugely 
> increase the usefulness of the Path object.

Manipulating paths is something I am punting on until browsers implement 
what's in the spec already, but I imagine at some point we'll add that, 
yeah.


On Sat, 23 Mar 2013, Rik Cabanier wrote:
> 
> The current path APIs suffer from conflating path segments and geometry. 
> To fix this, I proposed to modify the API so path just describe the path 
> segments.
>
> http://blogs.adobe.com/webplatform/2013/01/31/revised-canvas-paths/

I disagree with the premise of this post -- it's not the case that you 
never want to add segments. It is in fact quite common to add segments to 
a path -- that's what constructing a path is.

Also, it's not at all clear to me that there's really a distinction 
between a "shape" and a "path". They're really the same thing -- sets of 
path segments. What distinguishes them is not anything intrinsic to them, 
it's the behaviour when you combine segments.

Thus the clearer solution, IMHO, insofar as there's a problem, is to add 
methods that describe the various ways to combine paths.

Right now we have two options (ignoring the text parts of the path API): 
concatenating path segments, and concatenating path segments after having 
first outlined one of them.

On the long run I think it would make sense to add other methods, e.g. one 
combining two or more paths together such that the resulting path would 
outline the union of the "insides" of the provided paths, or the 
intersections, or whatnot.


On Tue, 9 Apr 2013, Jürg Lehni wrote:
> 
> Path, Shape, Gradient, Matrix all seem way too generic, and will 
> definitely clash with many libraries.

It's not that clear that this is true. There really haven't been that many 
reports of clashes, all things considered -- and it's not clear that 
Path2D, GraphicsPath, CanvasPath, or any number of other variants, would 
really be any more or less likely to clash.


> It was pointed out before that Path could also be a object describing a 
> file path, not necessarily a (2D) gemoetric path.

True, but if the argument is we can't use Path, then we couldn't use it 
for that either, so there'd be no clash.


On Mon, 17 Jun 2013, Jürg Lehni wrote:
> 
> And what is required to get such a proposal through?

Convince the browser vendors. At the end of the day, the spec will follow 
whatever the browsers do. (There's no process to convince them; one way is 
to argue here and hope they care and agree; another is to approach them 
directly, e.g. via their development discussion fora.)


On Mon, 24 Jun 2013, Jürg Lehni wrote:
>
> Well I know there will be problems: Paper.js has a Path class since 
> 2011, and these will clash when using the library without scoping, which 
> is what many people do.

How many is many? How high-profile are they?


> I was hoping that a more specific name could be adopted before the 
> standard is set in stone

We are never going to set the standard in stone. The only thing that 
prevents changes to the standard, really, is whether there's content that 
depends on it (which is usually the same as saying, whether there's 
browsers that implement it).


> I doubt we're the only library that clashes.

Do we have any data on this? Do any libraries use Path2D?

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'