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

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

Received on Wednesday, 29 April 2009 00:38:36 UTC