[whatwg] Why Canvas?

[WeBMartians]

I "copy." So, it's essentially a question of expediency. Is that proper for a standard? Don't read me wrong - faced with getting the bloody document out, I'd opt for what is running today, too.

Formally stated, my position is "leave it as is," but out of curiosity, do you see any obvious holes (especially security ones) with extending the graphics primitives to handle any rectangular entities, not just <canvas>?

The code snippet to detect canvas functionality
	var cvs = document.getElementById(<elementIdentity>);
	if (cvs.getContext){
		var ctx = cvs.getContext('2d');
		// drawing code here
	}
I suppose would work to detect canvas functionality on non-<canvas> entities as well.

BtW - Even against <canvas> entities, I like this script approach (with or without the use of fallback content) because it can yield a more predictable presentation over a wide range of browsers, which may or may not support the closing </canvas> tag.

The draft specification seems to imply (but does not state - I'll reread to make sure) that the script sees the backing store for the canvas rather than the rendered image itself. As long as the browser's script engine does not support image manipulation (input) or does not resize images, this is no big deal. As soon as either or both are implemented, the distinction becomes critical and must be the backing store. ...or so I claim... Correct?
-----Original Message-----
From: Anne van Kesteren [mailto:annevk at opera.com] 
Sent: Wednesday, 2007 August 01 03:51
To: WeBMartians; whatwg at whatwg.org
Subject: Re: [whatwg] Why Canvas?

On Wed, 01 Aug 2007 01:34:01 +0200, WeBMartians <webmartians at verizon.net>
wrote:
> Why not allow the graphics primitives to operate on any element (not 
> just <canvas>) that has a height and width that may be expressed in 
> picture elements... ...even window.screen with its .availHeight, 
> .availWidth, .height, and .width (yeah, I know, the Screen object is 
> actually a JavaScript object, not an HTML DOM object)?

Because that would lead to many small nasty bugs on different elements.  
Having it on a dedicated element makes it easier to implement which is a big plus given the interoperability issues we have with <canvas> today (although, like CSS, it's still usable).
--
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>
===
-----Original Message-----
From: Křištof Želechovski [mailto:giecrilj at stegny.2a.pl] 
Sent: Wednesday, 2007 August 01 01:01
To: 'WeBMartians'; whatwg at whatwg.org
Subject: RE: [whatwg] Why Canvas?

I think it can already be done using DHTML overlays.  Thus no instant amazing breakthrough is to be expected.
Chris