There is nothing to stop browser developers using the same underlying
implementation for canvas and svg rendering, so the overlap in
function becomes a plus point from a programming point of view.
Until either Canvas or SVG become completely available there will be
a place for both.
GazHay
On 12 Mar 2007, at 22:34, ddailey wrote:
Maciej wrote:
<canvas> is a programmatic immediate mode drawing surface. For
retained-mode structured graphics, SVG would be your solution.
Both things are useful.
I would like to believe that Canvas is useful, but being both naive
and stubborn, I don't yet see why.
In reading through the WHATWG draft, there are about N things that
it seems to be talking about. I see N-2 of those as redundant with
the SVG specs. The two components that jump out at me as missing
from SVG are getImageData and putImageData -- the former being
used, as I understand it, by Opera and perhaps others, to
interrogate pixel values and to gather rectangular sub-bitmaps.
Both of these are things that it would be nice (for me) if SVG had.
The other N-2 things are already present in SVG, in addition to
N*5 other things that are not in Canvas.
Those who have worked with Canvas for the past several years have
probably written documents somewhere to explain just why the two
specs (SVG and Canvas) should not be merged. If someone could point
me toward that rationale, I will emerge enlightened and grateful
(having shed both my naivite and my stubbornness).
In the meantime asking browser developers to implement both SVG and
Canvas (given what looks like a high percentage of overlap in
function) just seems like a way to artificially pump up staffing
levels on browser development projects.
ddailey
