[prev in list] [next in list] [prev in thread] [next in thread] 

List:       whatwg
Subject:    Re: [whatwg] Questions regarding Path object
From:       <lists () scratchdisk ! com>
Date:       2013-10-29 17:46:46
Message-ID: 2CAF7A40-77EF-4342-8FC1-00E94276D0F3 () scratchdisk ! com
[Download RAW message or body]

Regardless of good practices, I still believe that Path is too general a name for a \
new prototype that is introduced at this point. Option and Image come to mind, but \
those are from the early days. More recently, things appear to have been named a bit \
more specifically, often with prefixes, e.g. HTMLCanvasElement, DOMParser, \
XMLHttpRequest (which is wrongly named, since it's used for much more than XML), \
XMLSerializer, RGBColor (not just Color!), etc. Naming it simply Path feels wrong.

I am quite convinced that the Path object will remain in 2D, as you are discussing \
the addition of stroke expansion and boolean operations. I don't see any reasonable \
way to do this both in 2D and 3D in one constructor. The addition may really be the \
right way to go, it would allow you to add a Path3D at a later point and be \
consistent API wise.

We do scope the library, by the way, but offer a paper.install(window) method to make \
the prototypes global. So far there were no clashes, and the injection happened \
respectfully, meaning it wasn't overriding existing properties on window.

Now it will override existing properties in order to avoid these iOS7 issues with \
existing content, but we will stop encouraging people to use the library globally in \
such a way. 

The problem that we're facing is with code examples: These are all written in \
PaperScript, where the paper constructors appears to be global, as PaperScript code \
gets executed inside a PaperScope object.

I wish JavaScript offered a way to import values into a local scope without having to \
copy them one by one (and without using the dirty "with(scope) {}" trick), but that's \
another story.

for now I guess we'll have to tell people to do this:

function() {
    var Path = paper.Path,
        Group = paper.Group,
        ...;
    // Your Paper code here.
}();

I wanted to avoid a situation where Paper is even shadowing a global Canvas \
constructor when used in such a way, since it's a library built for Canvas. We can of \
course now rename Path to something else, but who knows that our other constructors \
will not face the same issue at a later point?

Jürg

On Oct 18, 2013, at 21:06 , Dean Jackson <dino@apple.com> wrote:

> On 17 Oct 2013, at 9:20 am, Ian Hickson <ian@hixie.ch> 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.
> 
> FWIW, many new specifications are hitting issues like this (well…
> at least Web Animations!). It’s a pain that new classes can
> clash with existing content, but I think we have to act
> as if the future is bigger than the past and thus pick the best
> name for the job.
> 
> As someone else said, the rule of not injecting into the global
> namespace from a JS library has been known for a few years now,
> and if you’re still not doing it you’re asking for trouble.
> 
> Dean
> 


[prev in list] [next in list] [prev in thread] [next in thread]