Re: [w3ctag/design-reviews] Review request for ResizeObserver (#187)

Abbreviation: RO - ResizeObserver

Answers:

> Why aren't the new & old sizes provided by the API directly?

The need to report the old size never came up. We tried to keep the API simple.
If the old size is needed, we'd have to define what is meant by "old size". The simplest answer would be "last reported size". If that is the answer, it can be trivially implemented on top of the existing API. If so, there is no need to add it to existing API unless widely used.

> Is it always going to be cheap to call window.getComputedStyle() within the callback to get the new sizes?

I read this question as "Is getComputedStyle() guaranteed not to trigger reflow".
Not in general case. If there are multiple ROs, and first observer's callback invalidates layout, calls to getComputedStyle() in second observer will trigger reflow.

> What's the timing relationship between Resize Observer delivery and Intersection Observer records? I presume the latter happens (sometimes much) later?

ResizeObserver notifications are delivered after Intersection Observer: https://wicg.github.io/ResizeObserver/#html-event-loop

When RO spec was designed, Intersection Observer used to deliver records with delay, without specific delivery timing guarantees. Therefore, the ordering of notification delivery between Intersection Observer and Resize Observer was not an issue.

Looking at the existing Intersection Observer spec, I do not see anything about delayed delivery. If Intersection Observer has started providing stronger delivery guarantees, I should open an issue to discuss RO/IO relationship.

**What is the current status of Intersection Observer delivery guarantees?**

> Is there more example code? ISTM that the explainer should include much more example code to outline the various scenarios where RO will be used.

I'll update the explainer shortly. So far, there are only 2 usage scenarios we've come upon, if more are discovered, I can add them to the explainer.
- Manipulate content in response to Resize event (example in the explainer)
- Use scroll events in combination with ResizeObserver to pin chatt window scroller to the bottom. This example is in the RO WICG repo (https://github.com/WICG/ResizeObserver/tree/master/examples/chat), but not in the explainer. 

> How do RO's work with proxies like the Offscreen Canvas proposal?

ResizeObserver only works with visible DOM elements. How is Offscreen Canvas related?

> Were design alternatives considered? If so, why were they discarded?

Design alternatives for what? Different parts of RO API? We've had several design discussions:

- [What happens](https://github.com/WICG/ResizeObserver/issues/8) when you start observing an element? RO API here is unexpected: you get a notification immediately with the existing size. This is done to avoid forcing reflow when starting an observation. This has caused [problems](https://github.com/WICG/ResizeObserver/issues/38) for one developer.
- Observer vs event API. Observer API won because because of efficiency, consistency with existing APIs.
- What to observe? Detailed discussion are [issue 4](https://github.com/WICG/ResizeObserver/issues/4) and [issue 6](https://github.com/WICG/ResizeObserver/issues/6). clientWidth/Height, borderBoxSize, contentSize were considered.
  - clientWidth cons: rounded, element move could trigger size change. Rejected.
  - borderBoxSize, cons: no notifications when border or padding change. Rejected.
  - contentSize: cons: size could change simultaneously with border/padding keeping content size same, resulting in no notifications.. Accepted. 
- How to prevent infinite loops. We considered timeout, hardcoded iteration limit, and depth limit. Decided upon depth limit.  Detailed discussion at [issue 7](https://github.com/WICG/ResizeObserver/issues/7)


-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/187#issuecomment-323437949