Re: ACTION-924: canvas and SVG draft text / comments

> I was just asked to write
> about the question of
> when to choose Canvas and when to choose SVG

I am 100% with you on this -- a best practice
should make clear the circumstances that 
constitute a compelling reason to prefer a
specific technology over another one -- or
to utilize a technology in a certain way 
rather than in another way. 

However, the proposed text, in its current 
form, does not constitute a best practice in
this sense. There are several problems with 
it:

1) It is rather tautological. Basically, it
states "use SVG if you need the features of
SVG, and use canvas if you only need the 
features of canvas".

2) The heading is "Use canvas for dynamic
graphics". Considering that SVG can do 
everything canvas does, AND has additional 
features for dynamic graphics (animation,
built-in scaling, dynamic modifications via
DOM manipulations), AND there are no obvious
performance counter-indications to SVG, AND
it is better established than the recent HTML5
feature, the legitimate question is whether
the recommendation should not be rather "Use
SVG for dynamic graphics"?

3) At the other extreme, this means canvas is
merely a 2D-drawing bitmap drawing tool, 
suitable for simpler, graphics with very 
limited dynamics.
But then the legitimate question becomes "why
not produce or pre-generate these graphics on
the application server (with GIF, Flash, etc)
and then deliver them with the rest of HTTP
responses?"

In short, the proposed text leaves me in the
dark as to what are the compelling reasons to
use canvas at all.

> when you just want to swap out
> the whole "graphical element" stuck in that page
> Canvas is lightweight and pretty fast to write
>
> Canvas quick and dirty and pretty much write-only

All right, so what are the applications for
which canvas is a compelling technology,
considering (2) and (3) above? A couple of
concrete, realistic examples would really
help.

> I do not have the time and energy
> to gather that data
> or to test actual performance...

I misunderstood your remark in the proposed
text -- I thought you had already scattered 
raw performance data, but had not been able to
make a statistically meaningful analysis of
them yet.

> this is just a hint to the developer
> and seems to me appropriate for inclusion...
> that it may be treated in other documents as well
> is a good thing
> but should not preclude inclusion in this document

I meant it is an important hint that might
warrant its own small section in the document
because of its relevance and generality.


E.Casais

Received on Thursday, 3 September 2009 13:56:22 UTC