- From: Rik Cabanier <cabanier@gmail.com>
- Date: Mon, 16 Nov 2015 11:16:55 -0800
- To: Justin Novosad <junov@google.com>
- Cc: WHAT Working Group <whatwg@whatwg.org>
On Mon, Nov 16, 2015 at 10:54 AM, Justin Novosad <junov@google.com> wrote: > > > On Mon, Nov 16, 2015 at 1:40 PM, Rik Cabanier <cabanier@gmail.com> wrote: > >> >> >> On Mon, Nov 16, 2015 at 9:41 AM, Justin Novosad <junov@google.com> wrote: >> >>> Also, the part about "repeating the last (possibly implied) moveTo() >>> call" doesn't make much sense if we assume that closePath() applies to the >>> new sub path that was started by the last moveTo() call. >>> >> >> It *is* super confusing. I complained about this in the past but it >> didn't go anywhere. >> > >> For the implied moveTo case, take the following code:: >> >> ctx.lineTo(0,0); // no moveTo, so moveTo(0,0) is implied -> create new >> subpath with points (0,0), (0,0) >> ctx.lineTo(100,100); -> subpath (0,0), (0,0), (100,100) >> ctx.closePath(); // draw line to (0,0) -> subpath (0,0), (0,0), >> (100,100), (0,0) then create new subpath with point (0,0) >> ctx.stroke(); >> >> > To be clear, my problem with the wording is that "(possibly implied)" > implies that the moveTo may also be explicit. In the case where there is an > explicit (non-implied) moveTo, does that make closePath essentially a no-op? > Can you write out the calls so it's clear if we're talking about the current or previous subpath? > On Mon, Nov 16, 2015 at 12:38 PM, Justin Novosad <junov@google.com> wrote: >>> >>>> That makes sense, but the text for closePath() talks about "the last >>>> subpath", which I guess is a bit unclear. >>>> >>>> On Mon, Nov 16, 2015 at 12:30 PM, Rik Cabanier <cabanier@gmail.com> >>>> wrote: >>>> >>>>> >>>>> >>>>> On Mon, Nov 16, 2015 at 9:02 AM, Justin Novosad <junov@google.com> >>>>> wrote: >>>>> >>>>>> Hi All, >>>>>> >>>>>> The text in the spec: >>>>>> >>>>>> <snip> >>>>>> >>>>>> The closePath() method must do nothing if the object's path has no >>>>>> subpaths. Otherwise, it must mark the last subpath as closed, create >>>>>> a new >>>>>> subpath whose first point is the same as the previous subpath's first >>>>>> point, and finally add this new subpath to the path. >>>>>> >>>>>> Note: If the last subpath had more than one point in its list of >>>>>> points, >>>>>> then this is equivalent to adding a straight line connecting the last >>>>>> point >>>>>> back to the first point, thus "closing" the shape, and then repeating >>>>>> the >>>>>> last (possibly implied) moveTo() call. >>>>>> >>>>>> </snip> >>>>>> >>>>>> Problematic use case: >>>>>> >>>>>> ctx.moveTo(9.8255,71.1829); >>>>>> ctx.lineTo(103,25); >>>>>> ctx.lineTo(118,25); >>>>>> ctx.moveTo(9.8255,71.1829); >>>>>> ctx.closePath(); >>>>>> ctx.stroke(); >>>>>> >>>>>> Should this draw a closed triangle or two connected line segments? >>>>>> According to the "Note" (or at least my interpretation of it), this >>>>>> should >>>>>> draw a closed triangle. But it appears that this is not what many >>>>>> browsers >>>>>> have implemented. Chrome recently became compliant (or what I think >>>>>> is >>>>>> compliant), and the change in behavior was reported as a regression. >>>>>> >>>>>> Thoughts? >>>>>> >>>>> >>>>> moveTo creates a new subpath. This means the closePath is going to do >>>>> nothing because the subpath is empty. >>>>> So according to the spec, this should create 2 connected lines. >>>>> >>>> >>>> >>> >> >
Received on Monday, 16 November 2015 19:17:27 UTC