- From: Charles Pritchard <chuck@jumis.com>
- Date: Tue, 2 Oct 2012 17:03:41 -0700
- 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. -Charles
Received on Wednesday, 3 October 2012 00:04:15 UTC