Re: [whatwg] "resize" events on elements

2015-02-25 Thread Elliott Sprehn
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

2015-02-24 Thread Dean Jackson

> 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

2015-02-24 Thread Anne van Kesteren
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

2015-02-24 Thread Simon Pieters

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

2015-02-24 Thread Ryosuke Niwa

> 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

2015-02-23 Thread David Flanagan
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

2015-02-23 Thread Anne van Kesteren
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

2015-02-23 Thread Tab Atkins Jr.
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

2015-02-23 Thread Michael A. Peters



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

2015-02-23 Thread Ryosuke Niwa

> 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