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

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

From: Jeff Sonstein <jxsast@rit.edu>
Date: Tue, 1 Sep 2009 16:45:37 -0400
Cc: public-bpwg@w3.org
Message-Id: <63B0EBDC-1B42-4971-AE22-38430F379C8C@rit.edu>
To: Eduardo Casais <casays@yahoo.com>
On Sep 1, 2009, at 11:43 AM, Eduardo Casais wrote:

> I have a few remarks to the draft section on SVG/Canvas
> posted by Jeff Sonstein.

thanks for the review work

> 1.	SCOPE
> The text entirely omits discussing Flash (lite)

Flash is a proprietary product
and I was just asked to write
about the question of
when to choose Canvas and when to choose SVG

people have become enamored of Canvas

> a) "Both SVG and the Canvas tag [...] are useful for their
> generalized drawing capabilities": SVG does not just supports
> drawing; it also features [...]

I was assuming people knew that Canvas
does not do all these other things...
do you think that is a bad assumption
and that I should say so explicitly?

> b) "Use Canvas where drawn contents (blocks) are to be
> under the control of JavaScript": with SVG tiny 1.2, one
> can manipulate the graphical elements with Javascript as
> well.

my point was that you can just
replace the entire contents of a Canvas
you cannot manipulate it like you can SVG

I personally like SVG more
for it's flexibility and richness and being part of the DOM
that is another story  ;^}

> c) "Use Canvas Tag For Dynamic Graphics": from its
> capabilities, SVG appears to be as well-suited as Canvas
> for dynamic graphics. In fact, the proposed text mentions
> "Use SVG where drawn elements (children) must be available
> as data and may be manipulated dynamically" -- clearly
> implying that canvas is not appropriate for dynamically
> handling graphical objects.

see above comment

when you just want to swap out
the whole "graphical element" stuck in that page
Canvas is lightweight and pretty fast to write
and when you need to reach into
that "graphical element" stuck in that page
and fiddle with the child nodes and do cooler stuff
*inside* that "graphical element" stuck in that page
SVG does become a part of the DOM
and SVG is pretty easy to manipulate
and so on

Canvas quick and dirty and pretty much write-only
SVG richer and beautiful and pretty much totally mutable

> [...] it may still
> make sense to mention performance if one can make a
> substantiated, reasonable consideration about the
> spread of performance in both technologies.

I do not have the time and energy
to gather that data
or to test actual performance...
too many combinations and permutations of
handsets and browsers and OSs for me to deal with

feel free

> "Due to the user-interface requirements of mobile devices,
> [...etc...]": This is actually a very relevant
> discussion, but I wonder whether it should not be
> placed on its own section elsewhere, as it is a general
> issue for scripting and markup in mobile devices.

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


"We must hang together, gentlemen... else,
   we shall most assuredly hang separately."
-- Benjamin Franklin (1776)  --
"We must hang together, or most assuredly
   we shall hang separately."
-- The Penguin (1966)  --

Prof. Jeff Sonstein

Received on Wednesday, 2 September 2009 14:13:11 UTC

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