[whatwg] Dashed strokes on <canvas>

Ian Hickson wrote:
> On Wed, 17 May 2006, David Flanagan wrote:
>> What surprises me about the omission of dashed lines is that every 
>> graphics API I'm familiar with (Xlib, PostScript, Java 2D) supports 
>> dashed lines. Unless there is some important platform out there that 
>> does not support them in the underlying graphics library, it seems to me 
>> that it would have been trivial to add dashed lines to the API.
>>
>> And, I can't think of any simple or efficient way to simulate dashed 
>> lines without having them in the API.  And while dashed lines may not be 
>> a high-use feature, I wouldn't say they're infrequently used.  For 
>> example: when drawing a line chart with multiple lines which is intended 
>> to be printed on a black-and-white laser printer.
> 
> There are many styles that aren't supported -- dashes aren't an exception. 
> For example, there's no support for having defined markers repeated around 
> the stroke. Similarly, we don't havenative  support for rounded corners, 
> or for many shapes (e.g. circles).

Dashes would be trivial to add--it is just a single additional line 
style property. I assert that every possible underlying graphics library 
already supports dashes, and I haven't heard a counter example from you. 
  You support the miterLimit property--something that is hardly ever 
used, but won't support dashed lines, which is a relatively common thing 
to use.  It just seems bizarre.

I believe that dashed lines have universal support in native graphics 
libraries.  Markers around the stroke do not.  Rounded corners are more 
common, but are not universal.  Lack of support for ellipses is a 
shortcoming of the API, and I hope you'll address it, but it does not 
excuse the omission of dashed lines.

> You can do dashed lines using paths. 

This is true only in theory. Way too much computation is necessary to 
transform a path into a dashed path.  How do dashes go around corners, 
for example?  Give that *every single platform supports dashes 
natively*, do you really want to argue that people who want dashed lines 
  should compute them in JavaScript?

Writing a method to draw a circle using only the arc and arcTo methods 
is pretty trivial and can be done efficiently.  Defining your own dashed 
path is not.  We really cannot do dashed lines in a Canvas without API 
support.

Without more demand for this feature,
> it's not clear that it's worth us putting it into the language.

It is just one more method on CanvasRenderingContext2D.  And the 
implementation would almost certainly be trivial.  You'll see the demand 
for dashed lines when Canvas becomes standardized without it, and people 
start wondering how to do dashes.  It truly seems strange to me that 
this feature has been omitted.

> 
> On Sat, 20 May 2006, Peter Hall wrote:
>> Flash is an example of a platform that does not support dashed lines in 
>> its drawing API. Dashed lines created in the Flash Authoring tool are 
>> actually exported into a swf as a series of short curves.
>>
>> However, this is a huge limitation, when it comes to drawing lines 
>> dynamically, so I don't think one platform's omission of the feature is 
>> a good argument anyway.
> 
> There apparently isn't much demand for it for Flash either.
> 

I think you're completely misunderstanding Peter's point.  Flash authors 
can use dashed lines whenever they want to.  Because their authoring 
environment does the expensive compilation required to transform their 
paths into dashed paths.  Then their *compiled* SWF files are executed 
on the Flash VM, which supports only a highly restricted set of graphics 
primitives.  Flash is a VM, not an API, and trying to draw dynamic 
graphics (as opposed to pre-compiled graphics) using Flash is expensive 
and tedious.  It is completely inappropriate to compare the Canvas API 
to the Flash API.


>> It is a reasonable and worthwhile goal to natively support emulation of 
>> all style attributes that are specifiable in CSS.
> 
> Why? CSS' styles are the result of a pretty arbitrary set of decisions in 
> committee meetings. (I know, I've been on the CSSWG for ~7 years.)

Okay, if you don't like CSS, how about this argument: it would be 
foolish and obstinate to purposely obstruct compatibility between Canvas 
and SVG-Tiny (see the stroke-dasharray property in 
http://www.w3.org/TR/SVGMobile12/painting.html#StrokeProperties), 
especially over something that is so trivial to add to the specification 
and so trivial to implement.

I really think you're making a mistake here.

   David Flanagan

> 
> On Sat, 20 May 2006, Peter Hall wrote:
>>> Correct, it doesn't have stroke styles other than gradients, patterns, 
>>> and solid colours. It was an intentional omission since it was not 
>>> considered a high-use feature. (Similarly, text is not available in 
>>> Canvas; you have to overlay HTML if you want to mix text with the 
>>> graphics.)
>> May I assume that the inclusion of gradients is solely because they are 
>> implemented for fills aleady?
> 
> Pretty much, I think.
>

Received on Wednesday, 9 May 2007 11:37:10 UTC