Re: Canvas

On Apr 7, 2007, at 5:40 PM, Andrew Fedoniouk wrote:

>>
>> <canvas> is a dynamic image that can be generated on the fly via  
>> JS. There is usefulness to this model, since it allows you to  
>> build the bitmap once and then treat it like an image from that  
>> point on.
>
> If it is just an image then what was/is wrong with existing Image  
> object
> and <img> that are there from the primordial Navigator?

The Image object is actually the same as an <img> element. It's just  
not in the document initially.

> <img id="canvas" src="placeholder.gif" />
>
> <script>
>   var img = $("#canvas");
>   var gfx = img.graphics( 300,300, "white" );
>   gfx.line(...);
> </script>
>
> or so.

Or you can do <canvas><img src="placeholder.gif"></canvas>. And then  
the placeholder only gets loaded in browsers that don't support  
canvas or when script is off.

Anyway, whether or not it would have been better to put a drawing API  
on <img>, there's not much benefit to changing how this works now.

>
>>
>>> I would expect that any DOM element have getGraphics() method.
>>>
>>
>> I agree with this conceptually (that the 2d-context API would be  
>> the  way to draw in both cases).
>>
>> However <canvas> still serves a useful purpose for one-time bitmap  
>> generation.
>
> I am personally not against client side bitmap generation but
> this canvas design and how it was injected in HTML gives an impression
> of it as a "foreign matter" or some quick fix of some particular  
> problem in
> some particular application/situation.
>
>> The kind of custom drawing that would work on arbitrary  DOM  
>> elements would (in my opinion) be a bit different, since you   
>> would probably process actual paint events and not force the   
>> retention of a separate bitmap buffer.  Forcing a separate buffer   
>> would not make much sense for containers where you have to paint  
>> your  children as well.
>
> I don't think that processing actual paint events is really required.
>
> See:
>
> We do have the Image object so we can:
> 1) Change its constructor to support creation of bitmaps/buffers:
>    var canvas = new Image(300,300, "orange");
> 2) Add to it getGraphics() method:
>    var gfx = canvas.getGraphics(...);
> 3) By using Image.src method we can attach it as src of the <img>
> or <object> or as CSS: background-image to any DOM element.
> so any element can get custom image.

The <canvas> API proposed in HTML5 includes a call to get a bitmap of  
the contents as a data: URI which you can then use with an <img> or  
as a CSS background. So your request is already supported. You can  
even draw on a <canvas> that is not in the document.

> <canvas> is a synonym of <img> element that has no
> reasonable backward or no-script compatibility - that
> is why it creates such an impression.

It has compatibility through fallback content. This actually works  
better than using <img> with a source image intended as fallback,  
since you have more choice of what the fallback can be. Instead of an  
image you could use arbitrary markup, or perhaps an <object> element  
embedding Flash or Java.

> IMO, <img src="noscript.gif"> with scriptable graphics
> makes significantly more sense in context of html
> then the <canvas>.

I don't think it's significantly better, in some ways it is worse.  
And it is also not worth changing now.

Regards,
Maciej

Received on Sunday, 8 April 2007 07:09:27 UTC