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:[EMAIL PROTECTED]
Sent: Wednesday, 2007 August 01 03:51
To: WeBMartians; [EMAIL PROTECTED]
Subject: Re: [whatwg] Why Canvas?
On Wed, 01 Aug 2007 01:34:01 +0200, WeBMartians <[EMAIL PROTECTED]>
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:[EMAIL PROTECTED]
Sent: Wednesday, 2007 August 01 01:01
To: 'WeBMartians'; [EMAIL PROTECTED]
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
