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
Re: [whatwg] Event loop processing model, and current time
> On Feb 23, 2015, at 5:26 PM, James Robinson wrote: > > On Mon, Feb 23, 2015 at 4:57 PM, Simon Fraser wrote: > >> https://html.spec.whatwg.org/multipage/webappapis.html#processing-model-9 >> says: >> >> 1. Let now be the value that would be returned by the Performance object's >> now() method >> 2. Let docs be the list of Document objects associated with the event loop >> in question… >> ... >> 4. For each fully active Document in docs, run the resize steps for that >> Document, passing in now as the timestamp >> ... >> >> This makes no sense, as performance.now() is per-document (it’s relative >> to the document start time), so passing the same value to all documents in >> the browsing context is bogus. >> >> What may be intended is to “freeze” the performance.now() time in all >> documents before processing those documents, but give each document its own >> performance.now() time. >> > > That is the intent. The algorithm should grab a timestamp for each > document "at the same time" (which is really just a matter of grabbing one > timestamp and applying the correct offset for each document). In that case, step 1 should probably define a list of timestamps, not the value. Alternatively, "now" should be defined for each document. - 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] Event loop processing model, and current time
On Mon, Feb 23, 2015 at 4:57 PM, Simon Fraser wrote: > https://html.spec.whatwg.org/multipage/webappapis.html#processing-model-9 > says: > > 1. Let now be the value that would be returned by the Performance object's > now() method > 2. Let docs be the list of Document objects associated with the event loop > in question… > ... > 4. For each fully active Document in docs, run the resize steps for that > Document, passing in now as the timestamp > ... > > This makes no sense, as performance.now() is per-document (it’s relative > to the document start time), so passing the same value to all documents in > the browsing context is bogus. > > What may be intended is to “freeze” the performance.now() time in all > documents before processing those documents, but give each document its own > performance.now() time. > That is the intent. The algorithm should grab a timestamp for each document "at the same time" (which is really just a matter of grabbing one timestamp and applying the correct offset for each document). - James
[whatwg] Event loop processing model, and current time
https://html.spec.whatwg.org/multipage/webappapis.html#processing-model-9 says: 1. Let now be the value that would be returned by the Performance object's now() method 2. Let docs be the list of Document objects associated with the event loop in question… ... 4. For each fully active Document in docs, run the resize steps for that Document, passing in now as the timestamp ... This makes no sense, as performance.now() is per-document (it’s relative to the document start time), so passing the same value to all documents in the browsing context is bogus. What may be intended is to “freeze” the performance.now() time in all documents before processing those documents, but give each document its own performance.now() time. Simon
