[whatwg] Canvas element

We have been thinking about this feature for WebCore.  In addition to  
primitive drawing operations, you really want higher level  
programmatic drawing control as well.  For example, it would be  
interesting to be able to programmatically draw the background of  
your element, the border of your element, the outline of your  
element, etc., knowing that the image would be drawn in the  
appropriate z-index relative to the other components of your element  
(or children).  For example, it would be particularly convenient to  
have APIs like "drawCSSBorderLine" that could automatically draw a  
line using the correct CSS-specified border style, or a method like  
"drawCSSBackground" that could be used to tile the background image  
into a specified rect.

In addition of course to custom painting is the need to allow control  
over layout itself, so that people can easily define their own custom  
layouts.  It is not clear to me that this work should be  
standardized, however, as browsers may need to come up with somewhat  
engine-specific solutions based off how they happen to implement  
these concepts (and the tie-in to native code like Objective-C may  
result in differences as well).

dave
(hyatt at apple.com)

On Apr 21, 2005, at 10:24 PM, Brad Neuberg wrote:

> +1 on the canvas API being able to be applied to any
> block-level element; this would be a very powerful
> capability, and its true that a specialized CANVAS
> element doesn't really mean anything in terms of
> semantic markup.
>
> Can we also apply this API to inline elements? As a
> matter of fact, why should the 'display' property
> affect this at all? I might want to use an absolute or
> relative positioned block as a surface to draw on.  It
> doesn't seem like whether it is inline, block, fixed,
> absolute, etc. is what influences whether it is a
> drawable surface.
>
> Should we specify in CSS that some element is
> "drawable"? This sounds like a straightforward way:
>
> someElement {
>   drawable: true;
> }
>
> This then tells the browser to initialize the canvas
> API on this element and to expect that its drawing
> surface might be updated through script.
>
> Sure seems like an appropriate place to put this,
> since it is a style-like property that one would
> attach to with CSS.
>
> One issue with this is that the actual canvas API
> calls would happen with JavaScript, which is seperate
> from the CSS.  So another alternative for this would
> be that any element can have the canvas API on it,
> without having to go through CSS.  Instead, you either
> start the canvas API up through JavaScript with an
> explicit method or attribute call:
>
> var someElement =
> document.getElementById("someElement");
>
> // alternative 1
> someElement.setDrawable(true);
>
> // alternative 2 - these are very similar from
> // javascripts perspective
> someElement.drawable = true;
>
> // alternative 3 - you just start using the canvas API
> // on any element
> someElement.canvas.moveTo(33);
>
> Does it affect performance that the rendering engine
> won't know before hand that some elements can be
> arbitrarily drawn on and others can't? Also, how does
> the canvas API on an element's surface affect other
> CSS properties, like 'overflow'?
>
> Brad Neuberg
>
> --- Dean Jackson <dean at w3.org> wrote:
>
>> 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
>>>>
>>>>
>>>>
>>
>>
>

Received on Thursday, 21 April 2005 23:16:58 UTC