Re: Canvas

----- Original Message ----- 
From: "David Hyatt" <hyatt@apple.com>
To: "Andrew Fedoniouk" <news@terrainformatica.com>
Cc: "Doug Schepers" <doug.schepers@vectoreal.com>; <public-html@w3.org>
Sent: Friday, April 06, 2007 1:54 PM
Subject: Re: Canvas


> On Apr 6, 2007, at 1:39 PM, Andrew Fedoniouk wrote:
>
>>
>>
>> ----- Original Message ----- From: "Doug Schepers" 
>> <doug.schepers@vectoreal.com>
>> To: <public-html@w3.org>
>> Sent: Friday, April 06, 2007 12:08 PM
>> Subject: Re: Canvas
>>
>>> Hi, Andrew-
>>> Andrew Fedoniouk wrote:
>>>> I am not sure about legal issues related to the current <canvas>
>>>> propsal. If there are any of them then I propse to use my 
>>>> specification:
>>>> http://www.terrainformatica.com/sciter/Graphics.whtm
>>>> It is a) simpler, b) more technically effective and c) free of  any 
>>>> royalties.
>>> And this is yet another reason that 'canvas' is out of scope for  HTML. 
>>> Let's not derail real HTML issues --a daunting scope as it  is-- with 
>>> inevitably long arguments about a procedural drawing  protocol.
>>
>> Exactly.
>>
>> <canvas> as an entity is otrhogonal to the HTML.
>> I was surprised that people decided to include it even in WHATWG 
>> specification.
>>
>
> Just to be clear, Apple did not propose <canvas> for inclusion in the 
> WHATWG specification.  We invented <canvas> for Dashboard, and then 
> Mozilla/Opera thought it was cool and implemented it.  As multiple 
> implementations emerged, it was then added in to the WHATWG spec.
>
>> If it is pure scripting solution so it should be defined on  scripting 
>> layer/DOM specification. Why dedicated <canvas> element  is there at all? 
>> What is so <semantic> in it?
>
> <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?

<img id="canvas" src="placeholder.gif" />

<script>
   var img = $("#canvas");
   var gfx = img.graphics( 300,300, "white" );
   gfx.line(...);
</script>

or so.

>
>> 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.

For me this is more natural solution at least.

>
> I'm kind of surprised that people think this element is orthogonal to 
> HTML.  It is just a dynamic <img>.

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

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

Andrew Fedoniouk.
http://terrainformatica.com

Received on Sunday, 8 April 2007 00:40:49 UTC