- From: Justin Novosad <junov@google.com>
- Date: Thu, 19 Jun 2014 15:32:36 -0400
- To: Dean Jackson <dino@apple.com>
- Cc: Rik Cabanier <cabanier@gmail.com>, Ian Hickson <ian@hixie.ch>, Stephen White <senorblanco@chromium.org>, Robert O'Callahan <robert@ocallahan.org>, WHAT Working Group <whatwg@whatwg.org>
+1 from me too. But I have one concern in terms of future proofing, because I would like to keep the door open for auto-resizing as a possible future improvement. In an eventual auto-resize proposal, we will want to make the "preferredsizechange" event cancelable. If we make the event non-cancelable initially, does that lock us in forever in terms of spec backward compatibility? If the answer is no, then +1 to Robert's proposal as is. In terms of accommodating the possibility of auto-resizing with a command buffer backed implementation, we should be able to add the necessary signals for short-circuiting a full JS redraw by adding event attributes and/or new event types on top of the current proposal. On Thu, Jun 19, 2014 at 3:05 PM, Dean Jackson <dino@apple.com> wrote: > > > On 20 Jun 2014, at 12:54 am, Stephen White <senorblanco@chromium.org> > wrote: > > > > On Thu, Jun 12, 2014 at 11:42 PM, Robert O'Callahan < > robert@ocallahan.org> wrote: > > I think I'd rather not take control of canvas resizing away from > applications, even opt-in. That leads to complexity such as extra API for > slaving other canvases. I also think we'd be better off sticking to the > invariant that the units of canvas coordinate space are single pixels in > the canvas bitmap; I think that simplifies things for implementers and > authors. > > > > I agree. > > +1 from me too.... and for the rest of Robert's proposal. > > Dean > >
Received on Thursday, 19 June 2014 19:33:04 UTC