[whatwg] Dashed strokes on <canvas>

[Ian Hickson]

On Wed, 9 May 2007, David Flanagan wrote:
> > 
> > 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.

...which would have to be defined, including error handling logic, 
including how to handle corners, including how to do dot distribution to 
have nice symmetry, etc, etc, etc. It's actually quite complex.


> I assert that every possible underlying graphics library already 
> supports dashes, and I haven't heard a counter example from you.

I haven't suggested otherwise.


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

miterLimit is needed to define how you render acute corners, which occur 
when you allow corners at all. Dashed lines don't occur if you don't allow 
them, so they are easier to omit. (Also, miterLimit was in the original 
Apple implementation, and dashed lines were not.)


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

Like I said, many things are omitted; they may be added in the future. 
We're not trying to be a complete graphics library here. Small steps.


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

A lot of things are "just one more method". We still have to draw the line 
somewhere.


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

When we see this demand, we can add the dashes. There are other features 
that people will want, for example skew and reflect transformations, 
applying transforms to patterns, and ways to extend the clip region, have 
all been requested already. There are notes in the spec for what has been 
requested; when demand for those features go up, we can add them. (Search 
for XXXv3 in the canvas section.)


> 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 don't really see that SVG is relevant here; <canvas> and SVG have quite 
different use cases; content written in one isn't likely to be written in 
the other.


> I really think you're making a mistake here.

I understand that.

So far the arguments in favour of dashed lines seem to be that they are 
sometimes used on graphs and that they are trivial to do. Given that there 
are plenty of other ways to do lines on graphs (and that they look better 
than dashes anyway), and that dash styles aren't trivial to define, this 
is not very compelling. That's not to say canvas will never have dashes, 
but it does mean that it isn't an urgent addition.


On Wed, 9 May 2007, David Flanagan wrote:
>
> You have a reasonable point. I still think that an implementation would 
> be trivial, but you're right that there is more complexity for the 
> specification than simply defining one more method API.  On the other 
> hand, I think it is legitimate to take the SVG-Tiny route and leave 
> specific rendering details to the implementation.  After all, you're not 
> specifying line and curve drawing algorithms down to the pixel, are you?

Anything that isn't specified to the virtual pixel is an error in the 
spec. (The canvas section is especially prone to these given my lack of a 
graphics background.) In theory, the canvas section is supposed to specify 
everything down to the level just before anti-aliasing.


> The problem of layering text on top of a canvas is a solvable one, so 
> people are solving it.  I don't think that dashed lines can really be 
> worked around. If there is no native support, they're not worth doing.

I've seen people work around the lack of dashed lines in <canvas> 
occasionally, so it's certainly possible, at least on straight lines.


On Thu, 10 May 2007, Philip Taylor wrote:
>
> e.g. the curve drawing section should give the equation for computing 
> the points on the curve

For arc() and arcTo() the definition seems complete, but I'm not familiar 
enough with graphics theory to know what quadraticCurveTo() and 
bezierCurveTo() need. Could you suggest some text?


> http://canvex.lazyilluminati.com/misc/dash.html

Nice!

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'