W3C home > Mailing lists > Public > public-bpwg@w3.org > September 2009

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

From: Eduardo Casais <casays@yahoo.com>
Date: Thu, 3 Sep 2009 11:45:28 -0700 (PDT)
Message-ID: <109555.66269.qm@web45016.mail.sp1.yahoo.com>
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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:09:02 UTC