[whatwg] Suggestions for <canvas> deferred to a future version

[Ian Hickson]

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.   `._.-(,_..'--(,_..'`-.;.'