[whatwg] Canvas element - Keep It Simple

[Brad Neuberg]

One thing I'm worried about is if we make canvas too generic, we will make 
it very difficult to implement as well as have all sorts of boundry 
conditions that we won't completely realize until the spec has been tested 
in the wild, leading to bugs.  For example, if we allow any element to be 
drawn on, let's say on an absolutely positioned div that is located in a 
relative one, and this absolutely positioned div has overflow: auto in it's 
CSS, and someone uses it as a canvas and draws on it in such a way that its 
content goes beyond the elements containing space, scroll bars will have to 
appear.  What if some browsers forget this boundry condition? How many 
other boundry conditions are there?

I'm all for exactness and purity, but I'm for simplicity too ;)

Here's another proposal:

In your source you simply have an IMG tag.  Then, either through CSS, an 
HTML attribute, or JavaScript you 'turn' this IMG tag into a canvas and can 
start drawing on it.  So browsers that support IMGs as canvases will get a 
nice surface to draw on, while those that don't will degrade nicely into 
some already retrieved image.

An example use:

In the HTML:

<img id="someImage" src="http://example.com/degraded_image.gif" />

In the CSS:

#someImage {
     drawable: true;
}

Now in our JavaScript:

var someImage = document.getElementById("someImage");
// now start drawing

What do y'all think? Seems easy for implementors, and the underlying 
rendering engine can still treat it as an image but one in which the image 
data is generated by code, which should make it easier to put together (I 
think ease of implementation and simplicity should definently be a target 
of the WHAT-WG; we don't want to end up with a DSSSL-like standard that 
takes forever to implement and work the kinks out of).

One thing I can imagine is that some people will want IMG tags that are 
canvases that _don't_ show up in older browsers (i.e. they don't even want 
a way for it to degrade, because it can't be implemented using a normal IMG 
src value).  Any ideas on how to do this using the kind of pseudocode above?

Brad Neuberg

At 08:09 AM 4/22/2005, Rob Mientjes wrote:
>On 4/22/05, Jim Ley <jim.ley at gmail.com> wrote:
> > > It has the semantics of a rendering context to which scripts can draw.
> >
> > So it only has presentational semantics, so should be in a rendering
> > language like CSS?
>
>That's the endless quandry. 'CSS can only do so much!' 'Markup should
>be about content, not presentation.'
>
>Maybe someone else can think of a suitable description that doesn't
>get in the way of anti-presentational markup purists.
>--
>Cheers,
>Rob.
>
>http://zooibaai.nl  |  http://digital-proof.org  |  http://chancecube.com

Brad Neuberg, bkn3 at columbia.edu
Senior Software Engineer, Rojo Networks
Weblog: http://www.codinginparadise.org

=====================================================================

Check out Rojo, an RSS and Atom news aggregator that I work on.  Visit 
http://rojo.com for more info. Feel free to ask me for an invite!

Rojo is Hiring!  If you're interested in RSS, Weblogs, Social Networking, 
Java, Open Source, etc... then come work with us at Rojo.  If you recommend 
someone and we hire them you'll get a free iPod!  See 
http://www.rojonetworks.com/JobsAtRojo.html.