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
- Re: [whatwg] canvas elements <rect> <polygon>... ddailey
-
