[whatwg] canvas elements <rect> <polygon> etc

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
>

Received on Monday, 12 March 2007 15:42:47 UTC