W3C home > Mailing lists > Public > whatwg@whatwg.org > February 2015

Re: [whatwg] "resize" events on elements

From: Elliott Sprehn <esprehn@gmail.com>
Date: Wed, 25 Feb 2015 03:14:22 -0500
Message-ID: <CAPJYB1johBhOJRV907+w+P2FGEK9WxSj4xKAndFzsC4zpqi6QA@mail.gmail.com>
To: "Tab Atkins Jr." <jackalmage@gmail.com>
Cc: WHAT Working Group <whatwg@whatwg.org>, Dean Jackson <dino@apple.com>, Ryosuke Niwa <rniwa@apple.com>
On Tue, Feb 24, 2015 at 12:34 AM, Tab Atkins Jr. <jackalmage@gmail.com>
wrote:

> On Mon, Feb 23, 2015 at 8:16 PM, Ryosuke Niwa <rniwa@apple.com> wrote:
> >> On Feb 23, 2015, at 5:40 PM, Dean Jackson <dino@apple.com> wrote:
> >> At the recent Houdini meeting there was a vague agreement between the
> browser engines on adding a way for elements to be notified when their size
> changes. We've run into a number of scenarios where this is extremely
> useful, and is otherwise difficult or annoying (e.g. checking your size on
> a timer).
> >>
> >> The idea was to allow the resize event on elements. I don't really care
> what the solution is, so maybe someone here can come up with a better idea
> (size observers?). And of course there are a lot of details to be worked
> out.
> >
> > I would like it be an async event on an element although we might want
> it to fire earlier than setTimeout(~, 0) to avoid FOC (maybe the same
> timing as rAF?).  I don't think end-of-microtask makes sense as that may
> force too many layouts.
>
> Yeah, you almost certainly want to tie it to rAF timing.
>

To support this without missing a frame we'd have to force an extra layout
before rAF to queue the event. That does mean we'd do one extra layout per
frame if your resize handler changed anything.

- E
Received on Wednesday, 25 February 2015 08:15:28 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 17:00:27 UTC