- From: Kenneth Russell <kbr@google.com>
- Date: Wed, 15 Apr 2015 22:22:44 -0700
- To: Dean Jackson <dino@apple.com>
- Cc: Justin Novosad <junov@google.com>, Rik Cabanier <cabanier@gmail.com>, Elliott Sprehn <esprehn@chromium.org>, Stephen White <senorblanco@chromium.org>, WHAT Working Group <whatwg@whatwg.org>, Ian Hickson <ian@hixie.ch>, Robert O'Callahan <robert@ocallahan.org>
On Wed, Apr 15, 2015 at 1:46 PM, Dean Jackson <dino@apple.com> wrote: > > On 16 Apr 2015, at 6:42 am, Elliott Sprehn <esprehn@chromium.org> wrote: > > 3. Accessing rendered pixel size is layout-inducing. To avoid layout >> >> thrashing, we should consider making this an asynchronous getter (e.g. >> asyncGetBoundignClientRect). This would also prevent renderedsizechanged >> events from firing from within the evaluation of the >> renderedPixelWidth/Height >> attributes, which is weird. > > > renderedsizechanged feels like it's related to the general per element > resize event problem. It'd be unfortunate to add an event to the browser > specifically for canvas instead of solving the general problem. In that case > authors will start resorting to hacks where they insert canvases into the > page to listen for resizes (we've seen this with other events like > overflowchanged). > > Perhaps we should add per element resize events and spec that they fire > after the layout, but before the paint, during normal frame creation. That > does mean you can cause an infinite loop if your resize handler keeps > mutating the page, but there's so many other ways to cause that already. > > > +1 If that's a viable option let's do that. It would solve many longstanding problems. -Ken
Received on Thursday, 16 April 2015 05:23:09 UTC