I've taken note of the suggestions below in the source of the HTML5 spec,
but not added them to the language yet. As we approach last call for the
HTML5 spec, I am trying to reduce the number of new features added, so
that we can stabilise the document and feature set and give implementors a
fixed set of features to aim for.
* Colours set by component
* The equivalent of SVG's fill-rule
* Line styles -- dashed and dotted lines
* Points
On Mon, 21 May 2007, Jordan OSETE wrote:
> Ian Hickson wrote :
> > On Sat, 12 May 2007, Jordan OSETE wrote:
> > >
> > > In that case, why not always return an array, like Philip Taylor
> > > suggested? It would allow the user be able to read color values in
> > > an easy way, and still keep compatibility with this kind of code :
> > >
> > > > var old = context.fillStyle;
> > > > context.fillStyle = 'green';
> > > > context.fillRect(0,0,100,100);
> > > > context.fillStyle = old;
> > >
> > > I don't see many reasons to return strings like #xxxxxx or rgba(...)
> > > in the first place, but if needed, it's way easier for the
> > > application to convert that array[4] to a rgba(...) or #xxxxxx
> > > string than the other way around.
> >
> > One reason to get back CSS values is that it makes it trivial to poke
> > values into CSS sheets.
>
> If CSS values are needed, it can still be converted quite easily:
> var col = context.fillStyle; //get an array
> col.pop(); //no alpha
> var css_col = "rgb(" + col.join(",") + ")";
>
> While parsing the current return values is way harder than that.
>
> > But the real reason is that the attribute takes CSS in, so it
> > returning CSS colours is symmetric and unsurprising. (Surprises are
> > bad in APIs.)
>
> I can understand that, but if it can take an array in, returning an
> array is also symetric. BTW, behaving like an array would be more
> consistent with the way getImageData() and putImageData() work,
> returning an array of 4*w*h integer values between 0 and 255 (in that
> case, alpha could also be returned an integer).
On Fri, 25 May 2007, Vladimir Vukicevic wrote:
>
> I'd like to propose adding a few simple 2D canvas context
> methods/parameters:
>
> attribute string fillRule;
>
> Specifies the algorithm used for filling paths. The options are "winding" or
> "even-odd"; the default is "winding". Good descriptions for these are in the
> SVG spec: http://www.w3.org/TR/SVG/painting.html#FillProperties . Hmm, they
> use "nonzero" and "evenodd"; we could use those instead for consistency.
>
> A more complicated addition is a mechanism for dashed line drawing; I
> see this was discussed a few weeks ago:
>
> attribute variant lineDash; // array of numbers or a single number; default
> 0.0
> attribute float dashOffset;
>
> [...]
On Wed, 3 Oct 2007, Stefan G�ssner wrote:
>
> One possible use case of canvas are technical drawings. For even
> extremely simple drawings - think of a circle with centerlines and a
> diameter dimension - dash-dotted lines are needed
On Mon, 4 Feb 2008, Simon Pieters wrote:
>
> See: http://forums.whatwg.org/viewtopic.php?t=141
>
> urbanjost wrote:
>
> > My first attempt at using the element to support vector-based graphics
> > produced by a program that dates back at least three decades was
> > actually more difficult to implement in a <canvas> element that it was
> > on an HP pen plotter many years ago.
> >
> > Even though I quickly became a fan of the HTML5 element because of the
> > ease with which I could interface with standard HTML documents and
> > ECMAScript/JavaScript, I was surprised there was no built-in support
> > for dashed lines, Hershey/vector fonts, even-odd polygon fill rules,
> > and points. And yet gradient fill patterns, opacity control, image
> > manipulation, and complex clipping regions were all supported (which I
> > consider more advanced graphic features than a dashed line!).
> >
> > Yet I found I could quickly create server-side applications or JavaScript
> > functions that let me get around these problems. The document found at
> > http://home.comcast.net/~urbanjost/canvas/vogle4.html shows some simple XY
> > plots containing simple labels, dotted grids, and dashed lines. This was
> > done with the help of a server-side library, but the functionality is all
> > very plausibly portable to JavaScript functions.
> >
> > But everyone does not have routines laying around to do sofware-based
> > dash codes, ASCII text strings, and grids. However, it looks like
> > others have already raised these issues except for the topic of points
> > (although I don't think anyone brought them up together, pointing out
> > that they are all common elements of any simple XY-plot utility).
> >
> > Since the other topics have already been breached, I'll make my point
> > about points!
> >
> > It is common practice in many graphic formats to represent a polyline
> > composed of a simple "move2(x,y)" or "move2(x,y) draw2(x,y)" as a
> > point. Another common solution is to provide a marker(x,y,"name",sz)
> > routine that can draw various markers at points.
> >
> > It is quite common for a technical plot to be a so-called "scatter"
> > plot where the data is marked purely by marker symbols or points. It
> > is also common to unpredictably have a polyline be just a single
> > point. If dashed lines are going to be supported, it is important to
> > note that almost all dash code models support points as part of the
> > dash-code pattern. Every graphing utility I can thing of supports
> > dotted grids, and so on. Points are so common in technical plots that
> > I strongly prefer that a polyline that has no length is represented as
> > a filled circle with a diameter equal to the current line width or as
> > a square centered on the point with an edge length equal to the
> > current line width.
> >
> > Inconveniently, the current <canvas> standard says to ignore a
> > polyline with no length. This means any code drawing simple curves has
> > to detect such lines and render them as circles or squares or give
> > them a false non-zero length.
> >
> > If others have reasons for not wanting to render lines with zero
> > length, perhaps the solution would be a new graphics state option that
> > would let you toggle between the two behaviors.
> >
> > The other surprise was that there was no display list or object
> > definition capability. Simple plots usually don't make much use of
> > these, except to define a marker style, but I find them invaluable in
> > nearly any nteractive program.
> >
> > All that being said, I find the <canvas> element a welcome and overdue
> > addition to the Web ( I actually liked VML better than either SVG or
> > PDF or CANVAS because there was a common editor, browser, and drawing
> > utility immediately available that supported it, but I'm practical
> > enough to know VML is now destined to be a proprietary MS-centric
> > product).
--
Ian Hickson U+1047E )\._.,--....,'``. fL
http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
