[whatwg] Questions regarding Path object
ian at hixie.ch
Tue Aug 20 11:32:36 PDT 2013
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:
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,
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
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. `._.-(,_..'--(,_..'`-.;.'
More information about the whatwg