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.
> 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. 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'm kind of surprised that people think this element is orthogonal to
HTML. It is just a dynamic <img>.
dave
(hyatt@apple.com)