- From: Charles Pritchard <chuck@jumis.com>
- Date: Tue, 23 Nov 2010 18:42:31 -0800
- To: "Tab Atkins Jr." <jackalmage@gmail.com>
- CC: public-fx@w3.org, robert@ocallahan.org
On 11/23/10 5:46 PM, Tab Atkins Jr. wrote: > On Tue, Nov 23, 2010 at 5:32 PM, Charles Pritchard<chuck@jumis.com> wrote: > >> I'm suggesting that browsers do some magic for "CSS Canvas"; >> I'm stating that authors will/do actually write that code when the use case >> requires it, with HTML Canvas. >> > I don't understand what the distinction is supposed to be between a > "CSS Canvas" and an "HTML Canvas". > > Understood. I'm trying to create one (a distinction). HTML Canvas is the current canvas element. CSS Canvas is a new construct, based on the idea of a Canvas intended for use as a paint server. HTML Canvas has two sets of dimensions: [canvas width="100" height="100" style="width: 100px; height: 100px"]. CSS Canvas has only one set: getCSSCanvasContext('2d', id, '100', '100) ; CSS Canvas use cases are based on the concept of an wider scene graph. HTML Canvas may be used independently. And boiling it down: CSS Canvas could (should?) operate with a dynamic backing store, the backing store of HTML Canvas is, and should remain static. CSS Canvas could even have multiple backing stores, of different dimensions, to speed up rendering, as the paint service may be used multiple times in a document, at different scales. In some part, CSS Canvas is a more high-level abstraction than HTML Canvas. You can't pry HTML Canvas out of my cold dead fingers. That being the case, I wouldn't mind having a 'managed' CSS Canvas element, from the CSS world. I actually do a lot of management of HTML Canvas with CSS, via z-index, clipping, width/height/positioning, display/visibility,opacity. -Charles
Received on Wednesday, 24 November 2010 02:43:00 UTC