Re: [whatwg] Interpretation of CanvasRenderingContext2D.closePath()

2015-11-16 Thread Rik Cabanier
On Mon, Nov 16, 2015 at 9:02 AM, Justin Novosad  wrote:

> Hi All,
>
> The text in the spec:
>
> 
>
> 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.
>
> 
>
> 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.


Re: [whatwg] Interpretation of CanvasRenderingContext2D.closePath()

2015-11-16 Thread Justin Novosad
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.

On Mon, Nov 16, 2015 at 12:38 PM, Justin Novosad  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  wrote:
>
>>
>>
>> On Mon, Nov 16, 2015 at 9:02 AM, Justin Novosad  wrote:
>>
>>> Hi All,
>>>
>>> The text in the spec:
>>>
>>> 
>>>
>>> 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.
>>>
>>> 
>>>
>>> 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.
>>
>
>


Re: [whatwg] Interpretation of CanvasRenderingContext2D.closePath()

2015-11-16 Thread Justin Novosad
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  wrote:

>
>
> On Mon, Nov 16, 2015 at 9:02 AM, Justin Novosad  wrote:
>
>> Hi All,
>>
>> The text in the spec:
>>
>> 
>>
>> 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.
>>
>> 
>>
>> 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.
>


Re: [whatwg] Interpretation of CanvasRenderingContext2D.closePath()

2015-11-16 Thread Rik Cabanier
On Mon, Nov 16, 2015 at 9:41 AM, Justin Novosad  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();




> On Mon, Nov 16, 2015 at 12:38 PM, Justin Novosad  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 
>> wrote:
>>
>>>
>>>
>>> On Mon, Nov 16, 2015 at 9:02 AM, Justin Novosad 
>>> wrote:
>>>
 Hi All,

 The text in the spec:

 

 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.

 

 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.
>>>
>>
>>
>


Re: [whatwg] Interpretation of CanvasRenderingContext2D.closePath()

2015-11-16 Thread Justin Novosad
On Mon, Nov 16, 2015 at 1:40 PM, Rik Cabanier  wrote:

>
>
> On Mon, Nov 16, 2015 at 9:41 AM, Justin Novosad  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?

>
>
>
>
>> On Mon, Nov 16, 2015 at 12:38 PM, Justin Novosad 
>> 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 
>>> wrote:
>>>


 On Mon, Nov 16, 2015 at 9:02 AM, Justin Novosad 
 wrote:

> Hi All,
>
> The text in the spec:
>
> 
>
> 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.
>
> 
>
> 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.

>>>
>>>
>>
>


Re: [whatwg] Interpretation of CanvasRenderingContext2D.closePath()

2015-11-16 Thread Rik Cabanier
On Mon, Nov 16, 2015 at 10:54 AM, Justin Novosad  wrote:

>
>
> On Mon, Nov 16, 2015 at 1:40 PM, Rik Cabanier  wrote:
>
>>
>>
>> On Mon, Nov 16, 2015 at 9:41 AM, Justin Novosad  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  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 
 wrote:

>
>
> On Mon, Nov 16, 2015 at 9:02 AM, Justin Novosad 
> wrote:
>
>> Hi All,
>>
>> The text in the spec:
>>
>> 
>>
>> 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.
>>
>> 
>>
>> 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.
>


>>>
>>
>


Re: [whatwg] Interpretation of CanvasRenderingContext2D.closePath()

2015-11-16 Thread Justin Novosad
On Mon, Nov 16, 2015 at 2:16 PM, Rik Cabanier  wrote:

>
>
> On Mon, Nov 16, 2015 at 10:54 AM, Justin Novosad  wrote:
>
>>
>>
>> On Mon, Nov 16, 2015 at 1:40 PM, Rik Cabanier  wrote:
>>
>>>
>>>
>>> On Mon, Nov 16, 2015 at 9:41 AM, Justin Novosad 
>>> 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?
>

I am referring to the example I started this thread with:
ctx.moveTo(9.8255,71.1829);
ctx.lineTo(103,25);
ctx.lineTo(118,25);
ctx.moveTo(9.8255,71.1829);
ctx.closePath();
ctx.stroke();


>
>
>> On Mon, Nov 16, 2015 at 12:38 PM, Justin Novosad 
 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 
> wrote:
>
>>
>>
>> On Mon, Nov 16, 2015 at 9:02 AM, Justin Novosad 
>> wrote:
>>
>>> Hi All,
>>>
>>> The text in the spec:
>>>
>>> 
>>>
>>> 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.
>>>
>>> 
>>>
>>> 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.
>>
>
>

>>>
>>
>