- From: Eduardo Casais <casays@yahoo.com>
- Date: Thu, 3 Sep 2009 06:55:41 -0700 (PDT)
- To: Jeff Sonstein <jxsast@rit.edu>
- Cc: public-bpwg@w3.org
> 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