Created attachment 1388 [details]
test html

Created attachment 1389 [details]
expected result image file

Could you elaborate on what it is about "The points at startAngle and endAngle along this circle's circumference, measured in radians clockwise from the ellipse's semi-major axis, are the start and end points respectively" and "the arc is the path along the circumference of this ellipse from the start point to the end point, going anti-clockwise if the anticlockwise argument is true, and clockwise otherwise" that is ambiguous?

(In reply to comment #3)
> Could you elaborate on what it is about "The points at startAngle and
> endAngle along this circle's circumference, measured in radians clockwise
> from the ellipse's semi-major axis, are the start and end points
> respectively" and "the arc is the path along the circumference of this
> ellipse from the start point to the end point, going anti-clockwise if the
> anticlockwise argument is true, and clockwise otherwise" that is ambiguous?

To me, it is not ambiguous. So I fixed chromium in https://codereview.chromium.org/18286007/

However, WebKit, Firefox and IE still determine the end point that equals the start point when the sweep angle is greater than 2pi. It said that someone might be confused. no offense.

I'll file this issue to WebKit, Firefox and IE.

(In reply to comment #3)
> Could you elaborate on what it is about "The points at startAngle and
> endAngle along this circle's circumference, measured in radians clockwise
> from the ellipse's semi-major axis, are the start and end points
> respectively" and "the arc is the path along the circumference of this
> ellipse from the start point to the end point, going anti-clockwise if the
> anticlockwise argument is true, and clockwise otherwise" that is ambiguous?

It's still confusing in that you can't tell if the arc should be a closed path when the angle is equal or greater than 2pi.
The text is unclear which is why browsers have different behavior.

I filed this issue in FF.
https://bugzilla.mozilla.org/show_bug.cgi?id=910142

I filed this issue in IE.
http://social.msdn.microsoft.com/Forums/ie/en-US/9855adb4-fcc1-4017-9188-d30261c0b97a/canvas-the-end-point-of-canvas-arc-is-incorrect

I filed this issue in WebKit.
https://bugs.webkit.org/show_bug.cgi?id=120429

I believe that the reporter is arguing that an "arc" should wrap around an ellipse more than once.

(In reply to comment #7)
> I believe that the reporter is arguing that an "arc" should wrap around an
> ellipse more than once.

I don't think so. 
the confusion lies in that when the angle is equal or greater than 2π, should the path be closed.

(In reply to comment #8)
> (In reply to comment #7)
> > I believe that the reporter is arguing that an "arc" should wrap around an
> > ellipse more than once.
> 
> I don't think so. 
> the confusion lies in that when the angle is equal or greater than 2π,
> should the path be closed.

You are right. Your summary is easy :)
In my opinion, arc should not be closed because the spec does not say about it.

Yeah there's nothing in the spec that I can see that would imply the path is closed. Why would it be closed?

So I finally figured out the confusion. The spec says that the arc is 2π in circumference if the points are more than 2π apart, but also says that the arc's start and end points are at the given points, even if they aren't a multiple of 2π apart. When they're more than 2π apart, these two conditions are mutually exclusive, if the subpath is to be continuous.

Here's a test case: http://goo.gl/CxK0ic

Most browsers (IE, Firefox, Safari) agree that the end point gets ignored in this case, so I've updated the spec to say that too.

Checked in as WHATWG revision r8294.
Check-in comment: Make arc() match reality better and contradict itself less.
http://html5.org/tools/web-apps-tracker?from=8293&to=8294

Created attachment 1416 [details]
line-arc-line-expected-results

The picture is the results of following script:

c.clearRect(0, 0, 640, 480);
c.save();
try {
  c.beginPath();
  c.moveTo(100,100);
  c.arc(200, 100, 50, Math.PI, 9/2*Math.PI, false);
  c.lineTo(200,200);
  c.stroke();
} finally {
  c.restore();
}

Chrome results in the left one.
IE, Firefox and Safari result in the right one.

The spec is changed to the right one.

Besides current browser status, I think the left one is more intuitive result. Do you think the right one is really better?

I think the right one is better because it's what most browsers do.

(Also, I don't really understand what the left one would mean. Does the line overlap itself? If so, it's clearly violating the part of the spec that says you can't draw an arc that's more than 2π in length. Is it creating a new subpath? In that case, would you get a cap in the middle of the arc suddenly?)

(In reply to Ian 'Hixie' Hickson from comment #14)
> I think the right one is better because it's what most browsers do.
> 
> (Also, I don't really understand what the left one would mean. Does the line
> overlap itself? If so, it's clearly violating the part of the spec that says
> you can't draw an arc that's more than 2π in length. Is it creating a new
> subpath? In that case, would you get a cap in the middle of the arc
> suddenly?)

I see. I'll apply this spec changes to Chrome.

As explaining chrome's implementation, arc path overlapes itself, but does not draw twice on the overlaped part.

(In reply to Dongseong Hwang from comment #15)
> 
> As explaining chrome's implementation, arc path overlapes itself, but does
> not draw twice on the overlaped part.

How does that work when the path is dashed?

(In reply to Ian 'Hixie' Hickson from comment #16)
> (In reply to Dongseong Hwang from comment #15)
> > 
> > As explaining chrome's implementation, arc path overlapes itself, but does
> > not draw twice on the overlaped part.
> 
> How does that work when the path is dashed?

Wow, it's very important question. overlapped.
http://jsfiddle.net/LDWBX/3/

I DID test only stroke with alpha. Now, I totally agree with this spec change. Thank you.