Re: [whatwg] "resize" events on elements

> On Feb 23, 2015, at 11:34 PM, David Flanagan <dflanagan@mozilla.com> wrote:
> 
> 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.

As I understand it, this is precisely why we haven't spec'ed such an event.  It's very easily to end up with O(n^2) layout if each element's resize event handler triggers a new "layout" of elements.

> 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.

That's tricky.  CSS layout is mostly top-down so it's more natural for a parent element to be laid out first, and then notify its child that they need to be resized.  However, there is nothing that forces child elements not to "dirty" their parents' size again once scripts are involved.

The only mechanism I can think of that can solve both of above problems is along the line of firing "resize" event exactly once per element per rAF so that we would end up with at most two path layout instead of O(n^2) per rAF.  i.e. elements can't get more resize events in response to a layout caused by an earlier resize event.  This is somewhat fragile though because it would mean that we can't have a hierarchy of elements that respond to parent's element resizing in response to "resize" events in a single frame.  But arguably, such a relationship would result in O(n^2) layout anyways so authors shouldn't be doing that.  Your canvas (or my inline SVG) use case would totally work under this restriction.

- R. Niwa

Received on Tuesday, 24 February 2015 08:21:11 UTC