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.
