[whatwg] Questions regarding Path object

Jürg Lehni lists at scratchdisk.com
Mon Nov 4 02:07:50 PST 2013

Thinking more about this discussion, I had an idea for an approach that would avoid such future clashes all together:

Instead of exposing constructors, why not simply expose the methods that create them?

There already are such functions for gradients:


Wouldn't it have been more aligned with this existing API also to have a ctx.createPath() ?


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

> On 17 Oct 2013, at 9:20 am, Ian Hickson <ian at 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

More information about the whatwg mailing list