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.
