[whatwg] canvas elements <rect> <polygon> etc
gazhay at gmail.com
Mon Mar 12 15:42:47 PDT 2007
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.
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.
More information about the whatwg