[whatwg] Canvas element - Keep It Simple
bkn3 at columbia.edu
Fri Apr 22 10:14:17 PDT 2005
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
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:
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?
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.
>http://zooibaai.nl | http://digital-proof.org | http://chancecube.com
Brad Neuberg, bkn3 at columbia.edu
Senior Software Engineer, Rojo Networks
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
More information about the whatwg