Re: [whatwg] resize events on elements
On Tue, Feb 24, 2015 at 12:34 AM, 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. 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
Re: [whatwg] resize events on elements
On Tue, Feb 24, 2015 at 9:20 AM, Ryosuke Niwa rn...@apple.com wrote: However, there is nothing that forces child elements not to dirty their parents' size again once scripts are involved. One idea that has been floating around is that if you opt into isolation (whereby children cannot affect you), you can get resize events for yourself. You might still get pathological cases if everyone opts into isolation I suppose, but then you've really done it to yourself. -- https://annevankesteren.nl/
Re: [whatwg] resize events on elements
On Feb 23, 2015, at 11:34 PM, David Flanagan dflana...@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
Re: [whatwg] resize events on elements
On Tue, 24 Feb 2015 02:40:10 +0100, 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. If we settle on a solution fairly soon I will implement it in WebKit nightly builds so people can play. I'd like to point out that the video element fires a resize event when the video resource changes size, per spec. I don't know if this is implemented by anyone, though; likely that event can be renamed. https://html.spec.whatwg.org/multipage/embedded-content.html#the-video-element:event-media-resize -- Simon Pieters Opera Software
Re: [whatwg] resize events on elements
On 24 Feb 2015, at 6:32 pm, Anne van Kesteren ann...@annevk.nl wrote: On Tue, Feb 24, 2015 at 2:40 AM, Dean Jackson d...@apple.com wrote: 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. It seems this should be defined by the CSS WG, no? None of the standards WHATWG publishes have much bearing on when an element resizes so there's no place to put fire a resize event. I'd expect that somewhere within a layout standard. That's a good point, and I'm happy to keep it in CSS. The reason I sent the request here is because I figured HTML was the place that had the existing 'resize' event (for iframe... although maybe it doesn't - I've never read the HTML spec :) The only change I would expect here is a change to HTML to make sure such an event can be animation frame synchronized. OK. We'll send an update if we think HTML needs to change. Dean
Re: [whatwg] resize events on elements
On 02/23/2015 05:40 PM, Dean Jackson 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. If we settle on a solution fairly soon I will implement it in WebKit nightly builds so people can play. Dean Yes, I desperately need this! Right now I have to try to trigger off of a bunch of things that can change the size of the parent (e.g. a details node opening or closing) - it would be much easier to just have a resize event on the parent node itself.
Re: [whatwg] resize events on elements
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. - R. Niwa
[whatwg] resize events on elements
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. If we settle on a solution fairly soon I will implement it in WebKit nightly builds so people can play. Dean
Re: [whatwg] resize events on elements
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
Re: [whatwg] resize events on elements
On Tue, Feb 24, 2015 at 2:40 AM, Dean Jackson d...@apple.com wrote: 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. It seems this should be defined by the CSS WG, no? None of the standards WHATWG publishes have much bearing on when an element resizes so there's no place to put fire a resize event. I'd expect that somewhere within a layout standard. The only change I would expect here is a change to HTML to make sure such an event can be animation frame synchronized. -- https://annevankesteren.nl/
Re: [whatwg] resize events on elements
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
