- From: Brad Neuberg <bkn3@columbia.edu>
- Date: Fri, 22 Apr 2005 10:14:17 -0700
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.
Received on Friday, 22 April 2005 10:14:17 UTC