On 3 February 2010 19:23, Oliver Hunt <oli...@apple.com> wrote: >> 1. Support more length specifiers for the width and height of a >> canvas(%, em, etc.). > > This doesn't really make sense for the backing buffer as it is logically > defined in terms of pixel.
The layout engine would decide how many pixels big it is, in exactly the same way that it decides how big to draw a image that has width specified in non-pixel units. >> 2. Add an onresize event to the canvas tag. When the canvas is resized >> it is reset and this event is fired. > We actually need this for webgl as well. > >> 3. CSS size specifiers resize rather than scale the canvas. I.e. it >> should always be that 1 unit = 1 pixel initially. > This would break content On 3 February 2010 18:07, Boris Zbarsky <bzbar...@mit.edu> wrote: > #3 would break existing canvas content. True, but: a) Otherwise width:100% in CSS and width="100%" in HTML would have different meanings. Confusing! b) Nobody uses it currently anyway - there's no content to break! I'm not exaggerating - look through canvasdemos.com and I bet you won't find a single case where the canvas is sized using CSS, for the very reasons I have given, specifically: c) It's slow, and looks rubbish. I suppose an alternative might be to have some way of retrieving the true size of the canvas, then you could do something like: canvas.width = canvas.trueWidthInPixels; > #2 would work if all elements supported onresize (as has been proposed), > right? > > Given that, a resize handler could simply reset the canvas width/height > attrs if desired (thereby achieving #1 and the clearing aspect of #2), no? > > Hence my question: what use cases here would not be covered simply by having > a general resize event on all elements? Well, yes it would be good to have onresize for all elements. But you still need to add width="...%" support to the canvas tag otherwise it will never *be* resized, so you couldn't achieve #1 with #2. I may have misunderstood you here.