W3C home > Mailing lists > Public > whatwg@whatwg.org > October 2012

Re: [whatwg] [canvas] Path object

From: Charles Pritchard <chuck@jumis.com>
Date: Tue, 2 Oct 2012 17:03:41 -0700
Message-Id: <E17F3541-D401-45F5-B207-487B1024838A@jumis.com>
To: "Tab Atkins Jr." <jackalmage@gmail.com>
Cc: WHATWG <whatwg@whatwg.org>, Elliott Sprehn <esprehn@gmail.com>
On Oct 2, 2012, at 3:00 PM, "Tab Atkins Jr." <jackalmage@gmail.com> wrote:

> On Sat, Sep 22, 2012 at 9:17 PM, Elliott Sprehn <esprehn@gmail.com> wrote:
>> I was looking at the canvas Path API and had some concerns. In
>> particular it's inconsistent with the rest of canvas:
>> We already have CanvasGradient and CanvasPattern in the global
>> namespace, so this should probably be called CanvasPath.
>> We also have createLinearGradient() and createPattern(), but this new
>> thing is "new Path".
>> Could we get some consistency here? Like adding new CanvasGradient()
>> (or a createPath() method) to match up with Path and renaming this
>> thing CanvasPath?
> I think the SVGWG would be opposed to that - we rather like the Path
> api and would appreciate being able to appropriate it for our own uses
> (merging with the <path> API).
> I'm fine with gradients/patterns moving to a plain constructor rather
> than a factory method, though.

We could have createPath() on the 2d context object return an opaque CanvasPath object without stepping on any toes with the SVGWG.

Presently, with Canvas, I was hoping for a bit of stability-- the suggestion of deprecating the createGradient and pattern methods seems to be going in the other direction, further blurring the boundaries of the API.

Received on Wednesday, 3 October 2012 00:04:15 UTC

This archive was generated by hypermail 2.3.1 : Monday, 13 April 2015 23:09:17 UTC