Re: [whatwg] Questions regarding Path object

On Fri, 20 Sep 2013, Jürg Lehni wrote:
> On Aug 20, 2013, at 11:32 , Ian Hickson <ian@hixie.ch> wrote:
> > 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?
> 
> It is quite a problem for us really because many people choose to inject 
> the scoped library into the global scope, for simpler code. That is also 
> the way one writes code in PaperScript (which is executed in its own 
> scope where these constructors appear global, but do not pollute the 
> actual global scope), and thus how all our examples and tutorials are 
> written.
> 
> Path is the most important constructor in Paper.js, a lot is built on 
> top of it. Changing it now would be a huge nuisance for us.

Changing the constructor from "Path" to something less pithy would be a 
nuissance to all future users of the API, too. :-)

We have to balance the cost of a longer name with the cost of conflicts.


On Fri, 20 Sep 2013, Jürg Lehni wrote:
>
> PS: iOS 7 is barely released, but the first bug reports are already 
> coming in, because the new Mobile Safari now defines Path, and clashes:
> 
> https://twitter.com/danetag/status/380636739251220480

Looks like this user solved the problem pretty quickly.

I tried to find more evidence of problems now that iOS7 is out with this, 
but I'm not finding much. (I did a bunch of searches on Google.) 

Having said that, I'm not saying there's no conflicts. If Chrome and 
Safari want to change to a different name, we can definitely still do 
that, it's early days yet. DOMPath, maybe? Or Path2D, or CanvasPath.

Still, on the long term it'd be sad that we can't just use Path.


On Fri, 20 Sep 2013, Jürg Lehni wrote:
> >
> > 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 would like to argue that Path2D is more precise and accurate than 
> simply Path. It is about two dimensional vector graphics after all, and 
> about performing geometric operations with / on it (hit testing, boolean 
> operations, drawing). Path2D makes as much sense in a Canvas context as 
> it does in SVG.

It might not remain 2D, though.


> >> - 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.
> 
> Maybe we can be of help there: We have put a lot of thought and work 
> into how Paper.js allows users to directly draw and manipulate Path 
> data, and tried to come up with solutions to make that as easy and 
> convenient as possible. I believe we could contribute insight to that 
> discussion.
> 
> Also, thanks to Harikrishnan Gopalakrishnan, since a couple of months 
> Paper.js has a working implementation of fat bezier clipping for very 
> fast path intersections, and a very resourceful implementation of 
> boolean operations (both in amount of code, and execution speed). 
> Perhaps this could serve as an example implementation?
> 
> We are currently working on implementing stroke expansion also.

If you do have any suggestions on expanding the path API, please do send 
them to this list of file bugs with suggestions: http://whatwg.org/newbug


> >> 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?
> 
> Google, Foursquare and the NY Times have used Paper.js for interactive 
> features, games and dynamic graphics on their websites, just to name a 
> few. I'm not sure if they were used in a scope manner or not, though.

Any of them break in iOS7 or Chrome?

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