<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Feb 3, 2010, at 11:54 AM, Tim Hutt wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div>On 3 February 2010 19:23, Oliver Hunt <<a href="mailto:oliver@apple.com">oliver@apple.com</a>> wrote:<br><blockquote type="cite"><blockquote type="cite">1. Support more length specifiers for the width and height of a<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">canvas(%, em, etc.).<br></blockquote></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">This doesn't really make sense for the backing buffer as it is logically defined in terms of pixel.<br></blockquote><br>The layout engine would decide how many pixels big it is, in exactly<br>the same way that it decides how big to draw a image that has width<br>specified in non-pixel units.<br></div></blockquote><div><br></div><div>But that's css scaling the image, which is what currently happens with canvas: the natural width/height of the canvas is specified and is used as the default css size. </div><blockquote type="cite"><div><blockquote type="cite"><font class="Apple-style-span" color="#000000"><br></font></blockquote><blockquote type="cite"><blockquote type="cite">3. CSS size specifiers resize rather than scale the canvas. I.e. it<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">should always be that 1 unit = 1 pixel initially.<br></blockquote></blockquote><blockquote type="cite">This would break content<br></blockquote><br>On 3 February 2010 18:07, Boris Zbarsky <<a href="mailto:bzbarsky@mit.edu">bzbarsky@mit.edu</a>> wrote:<br><blockquote type="cite">#3 would break existing canvas content.<br></blockquote><br>True, but:<br><br>a) Otherwise width:100% in CSS and width="100%" in HTML would have<br>different meanings. Confusing!<br></div></blockquote><div><br></div><div>width="100%" makes no sense for canvas as it means you're no longer specifying the size of the backing buffer, which is inherently pixel based.</div><br><blockquote type="cite"><div>b) Nobody uses it currently anyway - there's no content to break! I'm<br>not exaggerating - look through <a href="http://canvasdemos.com">canvasdemos.com</a> and I bet you won't<br></div></blockquote><div><br></div><div>Because <a href="http://canvasdemos.com">canvasdemos.com</a> is the only site in the world that uses canvas.</div><br><blockquote type="cite"><div>find a single case where the canvas is sized using CSS, for the very<br>reasons I have given, specifically:</div></blockquote><blockquote type="cite"><div>c) It's slow, and looks rubbish.<br></div></blockquote>This sounds like you want SVG not canvas -- by definition canvas is a bitmap, scaling behaviour is identical to scaling of an image.</div><div><br><blockquote type="cite"><div><br>I suppose an alternative might be to have some way of retrieving the<br>true size of the canvas, then you could do something like:<br><br> canvas.width = canvas.trueWidthInPixels;<br><br><blockquote type="cite">#2 would work if all elements supported onresize (as has been proposed),<br></blockquote><blockquote type="cite">right?<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">Given that, a resize handler could simply reset the canvas width/height<br></blockquote><blockquote type="cite">attrs if desired (thereby achieving #1 and the clearing aspect of #2), no?<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">Hence my question: what use cases here would not be covered simply by having<br></blockquote><blockquote type="cite">a general resize event on all elements?<br></blockquote><br>Well, yes it would be good to have onresize for all elements. But you<br>still need to add width="...%" support to the canvas tag otherwise it<br>will never *be* resized, so you couldn't achieve #1 with #2. I may<br>have misunderstood you here.<br></div></blockquote></div><br><div>The onresize event would fire on the css size changing, not the canvas resolution changing -- size != resolution.</div><div><br></div><div>--Oliver</div><div><br></div><div><br></div></body></html>