Re: Path strings, was: Re: [whatwg] CanvasRenderingContext2D with addPath, currentPath

Path takes an SVG path string, so you can do:
ctx.currentPath = new Path("...");


On Sun, Nov 3, 2013 at 5:27 PM, Charles Pritchard <chuck@jumis.com> wrote:

>  Any forward progress on supporting SVG path strings?
> That is... ctx.setCurrentPath(DOMString path)
>
> The cost for supporting and maintaining strings is minimal in terms of
> computation/ram/code base size, but it's a consistent pain for developers
> to re-implement.
>
> It's not going to happen, but we could have had ctx.currentPath return a
> string. Then == would have worked.
>

It's better to keep the path opaque. That way we can do operations under
the hood that can't be translated to simple paths (such as union'ing
multiple fills/strokes)

http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-July/032705.html
> http://www.w3.org/2011/07/27-svg-minutes.html#action10
>
>
> -Charles
>
>
> On 11/3/13 5:10 PM, Rik Cabanier wrote:
>
>
>
>
> On Sun, Nov 3, 2013 at 6:22 AM, Glenn Maynard <glenn@zewt.org> wrote:
>
>>   On Sat, Nov 2, 2013 at 9:03 PM, Rik Cabanier <cabanier@gmail.com>wrote:
>>
>>>  > Does this mean that ctx.currentPath != ctx.currentPath?
>>>
>>>  Yes
>>>
>>> > That's bad!
>>>
>>> Why would it be bad (apart from being different)?
>>>
>>
>>  It's strange to say "foo.bar.baz = 1" (ctx.currentPath.baz = 1), and
>> for foo.bar.baz to not be 1 the next time you look.  It's also confusing if
>> you use it as a Map key.
>>
>
>  OK. It sounds like this is implemented incorrectly in WebKit then.
> IF we were to implement giving access to the current path, it makes little
> sense to give access to the one that is actively managed by the canvas
> rendering context (= returning it as an attribute) so we should provide
> get/setCurrentPath methods.
>
>
>