[whatwg] Canvas size and double buffering.

[Boris Zbarsky]

On 2/3/10 2:54 PM, Tim Hutt wrote:
> a) Otherwise width:100% in CSS and width="100%" in HTML would have
> different meanings. Confusing!

I'm not suggesting that.  I'm saying we keep supporting only integers in 
the width attribute and if you put width:100% in your CSS and the canvas 
resizes you can do whatever you want (change the width attribute or not, 
whatever you want).

> 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

And no UA stylesheets?  No user stylesheets?  No non-demo things 
actually using canvas for something?

I actually have a hard time believing this, honestly.

> c) It's slow, and looks rubbish.

While true, repainting the whole canvas from scratch on resize is not 
likely to be faster.  And will look like rubbish by default (as in, look 
blank) unless the author writes script to make it otherwise.  If the 
author is writing such script it's two extra line to set the canvas size 
too.

> I suppose an alternative might be to have some way of retrieving the
> true size of the canvas

Like getBoundingClientRect()?

>      canvas.width = canvas.trueWidthInPixels;

Yep.  canvas.width = canvas.getBoundingClientRect().width;

> Well, yes it would be good to have onresize for all elements.

Which is why it's being worked on anyway.

> 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.

You put the % sizing in your CSS and reset the canvas width/height 
attributes if you want to.

-Boris