[whatwg] Questions regarding Path object
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:
>> 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.
More information about the whatwg