[whatwg] Dashed strokes on <canvas>
ian at hixie.ch
Tue May 15 16:06:22 PDT 2007
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
> 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
> 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
> 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?
Ian Hickson U+1047E )\._.,--....,'``. fL
http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
More information about the whatwg