track scroll dimensions in addition to content dimensions

[bmaurer]

I was looking at FB for places where resize observer might benefit us. Today, we manually try to keep our chat tabs scrolled to the bottom (most recent messages) when content within them is resized (for example, if a video preview is loaded). Resize observer seems like it could help this use case. One would set a resize observer on the chat tab and detect if the overall conversation grew in size. If so, it would check if the user was scrolled to the bottom and reset the scroll position.

However, for this to work resize observer would need to monitor the scroll dimensions of an element (and possibly the previous scrollTop) in addition to the content size.

[atotic]

You could do this by adding an extra div. I've added an example.

chattab.txt

[bmaurer]

So the problem is that this works well if you always want to scroll to the bottom. The logic we try to do is "if you were already scrolled to the bottom of the conversation then keep scrolled to the bottom". So you want to get both the old size / scroll position + the new size.

[atotic]

You can use the scroll event to keep track of whether you are scrolled to the bottom. ResizeObserver should not deal with scrolling. Here is an example:

chattab.txt

[bmaurer]

My concern here is that the scroll event is asynchronous. It's possible that an image loads, ajax responses adds content to the dom, before the scroll event arrives and that it is no longer scrolled to the bottom.

The reason why I'd want this to be part of resize observer is because I think we'd want to ensure we're seeing a consistent state of the world and not querying any properties that could cause layout. but maybe i'm missing some ways to string existing pieces together to implement this

[atotic]

Thanks for working on it. Could you expand my code sample so that it demonstrates the problem. According to spec:

• queued 'scroll' events are always dispatched before ResizeObserver runs
• ResizeObserver runs after all events have been dispatched, and before rAF.

Going through your example step by step, I can't come up with sequence to make it fail:

1. we start off with content scrolled to the bottom. notAtBottom is false.
2. image loads, changing the scroll position, and queueing up the 'scroll' event.
3. This step executes only if it is time for rAF: 'scroll' fires followed by ResizeObserver. Everything works.
4. ajax adds content to dom, changing the scroll position, and queueing up the scroll event.
5. at next rAF, 'scroll' fires followed by ResizeObserver. Everything works.

PS: deep dive on how event-loop dispatches events in different browsers: https://rawgit.com/atotic/event-loop/master/rendering-events.html ResizeObserver is not tested here, but would happen right before rAF.

[bmaurer]

In that case I don't have a concrete example :-) I guess I'd just say that:

1) Reasoning through this requires a pretty detailed understanding of the spec. This is an understanding that exceeds what most developers are likely to have. The developer has to reason about the order of all these events, if querying scrollTop will cause a reflow, how to combine multiple divs

2) Your document suggest that browsers are far from consistent in applying the rules :-).

Providing a snapshot of all the old layout information (content size, scroll size, scroll top) as part of resize observer would give developers an easy to understand abstraction that would avoid the need to apply such deep thinking. That said I understand the reluctance to increase the spec surface area.

[atotic]

I'll keep ResizeObserver as is. We've intentionally kept reported properties to a minimum: just the properties that are observed. The only exception were contentRect top/left reporting padding. This was added to accomodate common use case of absolutely positioning children.

1) Reasoning through this requires a pretty detailed understanding of the spec. This is an understanding that exceeds what most developers are likely to have.

That is very true. The growing complexity of web APIs is a huge problem, and it is about to get a lot worse. If you have any insights on this, I'll be chat over coffee or lunch, around MTV. My hunch that this will be resolved by frameworks built on these complex APIs. I am also curious to learn more about FBs problems.

[atotic]

Added full chat window example to: https://rawgit.com/WICG/ResizeObserver/master/examples/chat.html