[whatwg] Canvas element

[Brad Neuberg]

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