Yes, please! At a minimum I'd like to see this as a custom element
lifecycle callback, but a more general resize event of some sort also seems
like it would be useful. I've wanted this the most often when working with
the canvas element.

This seems like the sort of thing that would have been proposed many times
before. Is there history here? Good reasons that we do not already have a
resize event?

If not done carefully, I fear that the introduction of a resize event will
allow infinite layout loop bugs or a more benign situation where a user
change in browser window size causes a ripple effect where many
resize-sensitive components adjust their layout, affecting other
components, and everything takes a while to settle down at the new size.

I'd also note that unlike regular events that propagate up the tree, resize
notifications need to propagate down the tree from container elements to
their children.

  David

On Mon, Feb 23, 2015 at 9:34 PM, Tab Atkins Jr. <jackalm...@gmail.com>
wrote:

> On Mon, Feb 23, 2015 at 8:16 PM, Ryosuke Niwa <rn...@apple.com> wrote:
> >> On Feb 23, 2015, at 5:40 PM, Dean Jackson <d...@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.
>
> ~TJ
>

Reply via email to