Re: [whatwg] "resize" events on elements
On Tue, Feb 24, 2015 at 12:34 AM, Tab Atkins Jr. wrote: > On Mon, Feb 23, 2015 at 8:16 PM, Ryosuke Niwa wrote: > >> On Feb 23, 2015, at 5: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. > > > > 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 24 Feb 2015, at 6:32 pm, Anne van Kesteren wrote: > > On Tue, Feb 24, 2015 at 2:40 AM, Dean Jackson 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 ... 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 Tue, Feb 24, 2015 at 9:20 AM, Ryosuke Niwa 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 Tue, 24 Feb 2015 02:40:10 +0100, 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. I'd like to point out that the 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 Feb 23, 2015, at 11:34 PM, David Flanagan 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
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. wrote: > On Mon, Feb 23, 2015 at 8:16 PM, Ryosuke Niwa wrote: > >> On Feb 23, 2015, at 5: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. > > > > 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 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
On Mon, Feb 23, 2015 at 8:16 PM, Ryosuke Niwa wrote: >> On Feb 23, 2015, at 5: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. > > 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 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 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
