Bug 63933 introduced dashed lines support for the <canvas> element. No tests pixel were added, no V8 bindings. Chrome bindings would be simple, and would route to the GraphicsContext line stroker used for SVG dashed paths. For simple lines paths compat b/w browsers is reasonable. However, for complex paths, the interaction of line-joins and path shapes lead to interesting compat issues. knots.svg attached.
Created attachment 130968 [details] complex paths and line joins
Created attachment 130969 [details] Results on 10.6 mac-osx -- chrome 19 dev, firefox 10.0.2, safari 5.1.2
Created attachment 130971 [details] Results on win7 -- chrome 19 dev, firefox 10.0.2, safari 5.1.2, internet explorer 9
The differences in the SVG line-join implementations are clear. Some are bugs, but the required behavior is unspecified in SVG, best I can tell. <canvas> dashed lines would exhibit these same "line-join effects".
Created attachment 130984 [details] Patch: v8 bindings
Created attachment 130985 [details] Patch: test simple line dash and dash offsets
Created attachment 130988 [details] Patch: test line dash and line-width
Created attachment 130990 [details] Patch: test line dash and line-joins
Created attachment 130991 [details] Patch: test line dash and complex path line-joins
Created attachment 130992 [details] Patch: test line dash with gradient stroke style
Created attachment 130994 [details] Patch: test line dash with shaped path (circles)
Created attachment 131269 [details] Patch: test angular line dash with line-joins
http://www.w3.org/TR/SVGTiny12/painting.html#StrokeDasharrayProperty contains a note about the compat issues wrt stroke-dasharray, and my test results confirm it.
HTML spec has been updated with an API for this.
Not sure why this is still open. Seems to be fixed with the exception of issue in bug 80560. Closing bug.
WebKit has implemented the dash-stroke API Ian added per #14 ?
(In reply to comment #16) > WebKit has implemented the dash-stroke API Ian added per #14 ? yes
Meant how stroke depends the trace-a-path-algorithm [1] and the dash-list. [1] http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#trace-a-path
(In reply to comment #18) > Meant how stroke depends the trace-a-path-algorithm [1] and the dash-list. > > [1] http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#trace-a-path Implementations rely on the behavior of graphic libraries which are mostly based on the rendering of PDF. I do not see any need to follow the text in the canvas part of the specification. This makes the results likely less interoperable across other formats as for example SVG and the browser slower.
Can be interoperable by relying on graphics library behavior? Based on SVGTiny1.2's 'stroke-dasharray' note about the incompatibilities caused by graphics libraries, #13 and [1], one SVG 2.0 goal is to define stroke-dash behavior, regardless of graphics library [2]. Why bother? [1] https://www.w3.org/Graphics/SVG/WG/track/issues/2191 [2] https://svgwg.org/svg2-draft/single-page.html#painting-TermDashPositions