[whatwg] Canvas element

[Dean Jackson]

On 21 Apr 2005, at 08:40, Dimitri Glazkov wrote:

> Oh yeah, I agree on programmable image being quite useful. The
> question is why only limit the capability to a special CANVAS element
> (whose semantics are questionable), when any block-level element could
> have this ability.

I agree with this, and with everything else Dimitri says
in his weblog entry. I believe Sjoerd was saying a similar
thing.

Rather than an element itself, canvas should be a behaviour that
is attached to an existing element.

Dean

>
> The thing is, programmable image is with almost 100% certainty will be
> a presentational graphic. And presentational graphic has no place in
> markup. Therefore, if you utilize rendering context to create a
> dynamic image, you won't necessarily be doing it inside of an IMG (or
> CANVAS) element -- the dynamic image will be a presentational graphic
> for the content, expressed in markup.
>
> Take your example with eyes and hair, for instance. This is the markup
> that I would expect seeing instead of a canvas element (I am
> improvising here):
>
> <span class="photorobot">
> <span class="hairColor">green</span>
> <span class="eyeColor">yellow</span>
> <span class="mouthType">puckered</span>
> </span>
>
> Then the behavior would be attached to span.photorobot to create a
> canvas and draw a mug shot.
>
> Oddly enough, I just wrote about this whole graphics and markup thing
> this weekend:
>
> http://glazkov.com/blog/archive/2005/04/18/430.aspx
>
> :DG<
>
> On 4/20/05, Dean Edwards <dean at edwards.name> wrote:
>> dolphinling wrote:
>>> +1
>>>
>>>
>>> I would ask what semantics canvas has. ol means the content is an
>>> ordered list, em means the content is emphasized, span and div mean 
>>> the
>>> content is different, but in a way not associated with any element. 
>>> Even
>>> img and object mean the content is external, (usually) with non-html
>>> semantics.
>>>
>>> At best I can see canvas being equivelant to img and object, but 
>>> without
>>> the use case of the content being external. But even so, they come 
>>> with
>>> default semantics (the image or whatever else is being represented in
>>> them) whereas canvas doesn't, it has to be scripted in.
>>>
>>> So am I missing something here? What semantics does canvas have?
>>>
>>
>> I see the CANVAS element as analogous to the IMG element. It has 
>> similar
>> content (it's ultimately an image) but that content is defined
>> differently (using script).
>>
>> I can certainly see the advantage of having a programmable image. One
>> use may be for generating avatars. It would be easier to combine skin
>> tone, hair colour, eyes etc programmatically than have thousands of
>> images sitting on the server.
>>
>> I agree that it may be open to abuse but I've never been convinced 
>> that
>> this is a good reason to disallow anything.
>>
>> -dean
>>
>>