- From: Jürg Lehni <lists@scratchdisk.com>
- Date: Wed, 6 Nov 2013 12:30:42 +0100
- To: Rik Cabanier <cabanier@gmail.com>
- Cc: "whatwg@whatwg.org" <whatwg@whatwg.org>, Ian Hickson <ian@hixie.ch>
On Nov 4, 2013, at 20:25 , Rik Cabanier <cabanier@gmail.com> wrote: > On Mon, Nov 4, 2013 at 1:49 AM, Jürg Lehni <lists@scratchdisk.com> wrote: > > What's the use case? > > > > I intentionally didn't add this to the spec when I was adding the last set > > of path-related features, because it seems entirely redundant with Path > > objects. I thought we'd want people to move away from using the implicit > > path, rather than making it more powerful. > > I like this feature a lot. One advantage to not underestimate is the amount of effort it takes to change existing code to make use off the new Path feature, while staying backward compatible with older browsers that don't implement this spec. For example, in Paper.js it took only three added lines of code to use cached paths if they exist rather than redrawing them each time > > Do you think getCurrentPath should return a path in user space or in the current transformation matrix? I think it should be in user space, without the transformations factored in. The current behavior is confusing, and I wonder what it's use case would be. In the meantime I realized I have to revert the change that I've outlined above for exactly this reason... Jürg
Received on Wednesday, 6 November 2013 11:31:23 UTC