Re: [whatwg] Why Canvas?

[WeBMartians]

Sorry, Andrew. I missed seeing your email and did not include it in my latest - 
I haven't had my orange juice yet, and while I may be standing with my eyes 
open, my brain hasn't yet caught up.

I completely missed the CSS aspect and the foreground/background image slant as 
well. Good call.

The introduction of foreground images as well as background images makes things 
a lot more complicated:

- Which one is selected by
var cvs = document.getElementById();?
- If you have one foreground image, why not have many in layers?
- If you have layers, what about transparency (or alpha) and what about Z-order 
changes?
Wow! World of Warcraft superimposed over the nightly news video!
...given 3D ... Halo superimposed over WWft over nightly news...

Shudder... I think this will require more than orange juice. It may be best to 
let this monster snooze until HTML 6.

-Original Message-
From: Andrew Fedoniouk [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, 2007 July 31 20:44
To: WeBMartians; [EMAIL PROTECTED]
Subject: Re: [whatwg] Why Canvas?


- Original Message -
From: "WeBMartians" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, July 31, 2007 4:34 PM
Subject: [whatwg] Why Canvas?


> With  a relatively stable (and implemented, actually) tag, this 
> may be a doubtful question. However, I can't think of any answer, so here 
> goes...
>
> Why ?
>
> Why not allow the graphics primitives to operate on any element (not just 
> ) 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)?
>

I think this discussion
http://lists.w3.org/Archives/Public/public-html/2007Apr/0355.html
is related to the subject.

Image (object) has pixel buffer so it is pretty logical to add
Graphics interface to it. The only feature left is 
style.setBackgroundImage() method:

var el = document.getElement;
el.style.setBackgroundImage( el );

In this case it would be possible to render graphics on any element.

And if we will add 'foreground-image' CSS attribute & friends (similar to
backround-*** attributes) then you would have an option to choose where
to draw it - on background or on foreground layer (on top of the content)

Andrew Fedoniouk.
http://terrainformatica.com

Re: [whatwg] Why Canvas?

[Anne van Kesteren]

On Wed, 01 Aug 2007 13:06:30 +0200, WeBMartians <[EMAIL PROTECTED]>  
wrote:
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.


If a standard doesn't consider practical contraints it will never become a  
standard as it will not be implemented.



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  
?


There are lots of potential problems, such as how it would interact with  
plugins or some video if both render to the same context. Or if you allow  
it on elements such as  what would happen if text resizing caused the  
canvas to rescale, et cetera.



--
Anne van Kesteren

Re: [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 ?

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

BtW - Even against  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  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 ) 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  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

Re: [whatwg] Why Canvas?

[Anne van Kesteren]

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 ) 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  today  
(although, like CSS, it's still usable).



--
Anne van Kesteren

Re: [whatwg] Why Canvas?

[Křištof Želechovski]

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

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of WeBMartians
Sent: Wednesday, August 01, 2007 1:34 AM
To: [EMAIL PROTECTED]
Subject: [whatwg] Why Canvas?

With  a relatively stable (and implemented, actually) tag, this may
be a doubtful question. However, I can't think of any answer, so here
goes...

Why ?

Why not allow the graphics primitives to operate on any element (not just
) 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)?

The utility is amazing: a tutorial option could then lead a user through a
page or series of pages, circling/outlining an input item ("Fill in this,
first!"), then circling a set of, say, radio buttons ("Now, select one of
these!"), and, finally, circling the Submit button ("Congratulations! You
did it!"). You can see how this would give an instant advantage in
Total-Ownership-Cost to Web Applications.

===
B. de Graaf - [EMAIL PROTECTED] 

Re: [whatwg] Why Canvas?

[Andrew Fedoniouk]

- Original Message - 
From: "WeBMartians" <[EMAIL PROTECTED]>

To: <[EMAIL PROTECTED]>
Sent: Tuesday, July 31, 2007 4:34 PM
Subject: [whatwg] Why Canvas?


With  a relatively stable (and implemented, actually) tag, this 
may be a doubtful question. However, I can't think of any answer, so here 
goes...


Why ?

Why not allow the graphics primitives to operate on any element (not just 
) 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)?




I think this discussion
http://lists.w3.org/Archives/Public/public-html/2007Apr/0355.html
is related to the subject.

Image (object) has pixel buffer so it is pretty logical to add
Graphics interface to it. The only feature left is 
style.setBackgroundImage() method:


var el = document.getElement;
el.style.setBackgroundImage( el );

In this case it would be possible to render graphics on any element.

And if we will add 'foreground-image' CSS attribute & friends (similar to
backround-*** attributes) then you would have an option to choose where
to draw it - on background or on foreground layer (on top of the content)

Andrew Fedoniouk.
http://terrainformatica.com