Burningbird

Anne Van Kesteren:

A new survey reveals that at least Microsoft and IBM think the HTML charter does not cover the canvas element.

I have to wonder, when reading the survey results, how much the people who voted actually used either SVG or the Canvas element. I covered both SVG and the Canvas Element in the book, but I focused more on SVG. Comparing the two–SVG and Canvas–is like comparing the old FONT element with CSS.

The Canvas element requires scripting. The SVG element doesn't, even for animation if you use the animate elements. In addition, mistakes in SVG can be fun, as I found when I missed a parameter value in mistaken animation. A couple lines of markup. No script. Both Opera and Safari do an excellent job with the animation elements. I'm expecting Firefox to join this group in the next year.

If you use scripting, you can access each element in the SVG document as a separate element. You can't do that with Canvas.

I still don't think the Canvas element should be part of a new HTML 5, whatever the grand plans. However, since all but IE supports the Canvas element, it would be foolish to drop it. A better option would be to consider the Canvas element a bitmapped version of SVG and create a separate group to ensure it grows in a standard manner.

I did like what David Dailey wrote in the survey results:

I have considerable ambivalence about <canvas> as I have noted previously. If we were designing HTML 5 from the ground up , SVG and canvas ought to share syntax and ought not to duplicate so much functionality. <canvas> brings a few needed things with it, though it seems rather a bit of poor planning on the part of the advocates of <canvas> that has gotten us to this point. Those historically frustrated with W3C chose to ignore SVG and now seem to want W3C to ignore SVG in favor of a lesser technology. At the same time, <canvas> does enable client-side image analysis by giving the developer access to pixel values, and that alone allows for some tolerance of what otherwise seems to be a curious decoupling of reason from politics. Does it re-invent the wheel? — only about 95% of it is redundant with 20% of SVG.

As for all the discussion about semantic API…years ago I, and others, made a fight for a model and associated XML vocabulary, RDF, we said would stand the test of time and hold up under use. The road's been rough, and few people are going to defend reification, but RDF fuels the only truly open social graph in existence. Five years ago. That was about the time when everyone believed that all we'd need for semantics was RSS. Including Microsoft.

I've moved on from SVG to the Canvas element, and am still suffering whiplash at the downward steepness of the step. Leaving aside that one can defeat canvas easily just by turning off script, about the best documentation I found on the element is Mozilla's implementation. The specification is buried within the HTML5 work, which if you think on it, defeats every last bit of argument about not including SVG because it's "presentational".

About the only negative associated with SVG is how to include it in the pages–the specification, itself, is really nice. Once all of the features are supported in the main browsers, you're going to see some amazing stuff.

You don't realize how nice SVG is, until you look at the Canvas element. For instance, I created an SVG example on how quadratic bèzier curves work in SVG. The canvas element also supports the same type of curves, so I went to re-create the example. I hit a wall immediately. Why? Two words:

"dashed lines"

No, there is no way of adding either dashes or dots or combination to lines in canvas. You can use a custom function and create tiny little lines using lineTo and/or one of the curve functions, but there's no way to actually just specify the dash-dot pattern to use, and forget about it. My canvas demonstration of quadratic bèzier curves ended up looking a tad bit different.

I went searching on HTML5, the canvas element, and dashed line support and found a couple of discussions about supporting dashed lines in canvas. The official word is: not trivial to implement, no one really wants them.

Considering that one of the first implementations on the canvas element I created uses dashed lines, I beg to differ on the 'no one really wants' assumption. Sure, I can use a custom function, such as the one I'm using to emulate a rounded corner rectangle, but I can't help thinking this isn't the most efficient approach. The user agent should be able to optimize for dashes in line drawing if these are part of the specification, but there is no real optimization for functions that create hundreds of little dashes based on rotate, curve, line, move.