- From: Eduardo Casais <casays@yahoo.com>
- Date: Thu, 3 Sep 2009 11:45:28 -0700 (PDT)
- To: public-bpwg@w3.org
> well > I *do* try to point out > the basic decision-elements > > SVG if you need DOM access and richness > Canvas if you don't The decision elements must be based on application functionality, performance issues, portability, security, accessibility, usability, in other words, requirements -- not on the features of the technology. "Use SVG if you need DOM, canvas if you do not" is as interesting and instructive as stating "use XHTML if you need strong markup validation, use HTML if you do not" -- or "use C++ if you need object-oriented functions, C if you do not". Why would you need the features under consideration? Why would it be a good practice to rely upon them or conversely to forgo them? > got a suggestion that puts canvas and SVG in the > same heading-phrase? Alas no, except that at this point I would slightly tend to propose "Use SVG for dynamic graphics; generate static graphics on the server; avoid canvas". > the choice of whether to generate stuff > server-side or client-side > seems to me beyond the scope of this little section That is a pretty limited view of the affair. If canvas are not good for dynamic graphics (there, use SVG), and are just ok "to whip up something lightweight and fairly static" then one can as well pre-generate the fairly static content (with whatever suitable: Flash, GIF...) on the server, and send a simple file to the terminal, instead of having to send a file AND running code on the terminal. The sum of these considerations would be that there are compelling reasons NOT to use canvas -- because it either does not provide dynamics, or because of its presumably inferior performance. Once again, if there are cases where canvas implements some categories of application functionality with better peformance, or usability, or portability, or security, etc, etc, than other technologies, then these should be made clear, since they would be the basis for a best practice. To put the question in another light: what were the compelling reasons and use cases to include canvas in HTML 5 (excluding a natural craving for creeping featurism)? E.Casais
Received on Thursday, 3 September 2009 18:46:09 UTC