[resize-observer] Which box information should we pass to the callback

[gregwhitworth]

We now allow authors to determine which box(es) they wish to observe on layout changes. Now we need to discuss which boxes we provide the information on. We have a few options:

Take the following example: If the author sets content-box and border-box to be observed, which box dimensions would you expect to receive passed to your callback?

1. The box(es) that were requested to be observed: so in the example above, content-box and border-box information
2. They receive all available CSS boxes that are observable: They will receive border-box, content-box, scroll-box dimensions.

Option 1 Pros is good because it makes sense that I requested a specific set of boxes to be observed and those are the ones that you returned information on.

Option 1 Cons If the sets the observer to the border-box but desires to know something about an inner box, they may request it in some other manner causing us to do additional work which defeats the purpose of this API altogether.

Option 2 Pros You can set one observation and get information about all of the boxes, so if you have a scenario in which you want to observe the border box but check the content or scroll box - this is possible without having to observe them.

Option 2 Cons It clutters up the response, if I only care about the border-box but I get results for every other box this may be a nuisance.

My personal opinion is to go with option 2 as I think people will either over observe to get the potential rects they care about or will ask for them in some other manner. That said, I don't have a strong opinion about this as I think it will be user preference. I have a twitter poll going about this in hopes of crowd sourcing some thoughts from web devs.

[atotic]

My vote is also for #2, report all boxes.

Observing content-box and border-box at the same time increases likelihood of "undelivered notifications error". We do not want developers observing multiple sizes just to be able to read their values out of the ResizeObserverEntry.

[gregwhitworth]

increases likelihood of "undelivered notifications error"

Then what is the reasoning behind allowing a sequence of options to be passed in? Maybe we should limit it to only one option being passed in as to avoid this issue?

[atotic]

Then what is the reasoning behind allowing a sequence of options to be passed in? Maybe we should limit it to only one option being passed in as to avoid this issue?

Good point. I think single option will be vast majority of usage. For the rare case of multiple sizes being observed, developers can use multiple ResizeObservers.

[gregwhitworth]

Good point. I think single option will be vast majority of usage. For the rare case of multiple sizes being observed, developers can use multiple ResizeObservers.

To be clear here - you're in agreement that we should change this:

dictionary ResizeObserverOptions {
    (ResizeObserverSizeOptions or sequence<ResizeObserverSizeOptions>) size = "content-box";
};

to this:

dictionary ResizeObserverOptions {
    (ResizeObserverSizeOptions) size = "content-box";
};

[atotic]

Yes :-)

I started off against the change. Then I wrote down my arguments for allowing multiples, and they were not convincing. So I changed my mind, and now agree with you.

[gregwhitworth]

To summarize, the change that @atotic and I made is to be able to observe and single box at a time with all boxes being returned on callback.

[gregwhitworth]

To be very clear, here are the boxes whos dimensions would be returned:

• borderBoxSize
• contentSize
• scrollSize
• devicePixelBorderBoxSize

[TremayneChrist]

To be very clear, here are the boxes whos dimensions would be returned:

• borderBoxSize
• contentSize
• scrollSize
• devicePixelBorderBoxSize

If we can observe border-box, content-box, scroll-box and device-pixel-border-box, shouldn't all property names also include box in the name?

• borderBoxSize
• contentBoxSize
• scrollBoxSize
• devicePixelBorderBoxSize

[css-meeting-bot]

The CSS Working Group just discussed Which box information should we pass to the callback.

The full IRC log of that discussion

<dael> Topic: Which box information should we pass to the callback
<dael> github: https://github.com//issues/3329#issuecomment-452477429
<dael> gregwhitworth: This comes down to we changed the spec because we resolved we wanted to watch more boxes. THen it was what information should we return? Author wants to observe border box, what do we return? We previously stated all that you could potentially observe so that we answer anything the author wants to watch.
<dael> gregwhitworth: WE don't want author putting multi observers to watch multiple boxes.
<dael> gregwhitworth: What would happen is in the issue. We would return border box, content size box, scroll box, and device pixel border box.
<dael> iank_: I'm observing border box size and the content box size changes, am I notified?
<dael> gregwhitworth: No. If you want the content box you should observe it
<dael> iank_: Worries me webdev will observe border box and then complain it's not working as expected. Did you consider getting people to list all boxes and nulling things not needed?
<dael> gregwhitworth: Initially we were going to allow them to observe multi. We can add an option to return us what you want to return us. We can add an option that says of the ones we have which do you want options returned.
<dael> gregwhitworth: It's kinda a shot in the dark right now. Even if they have the option they could still have the same problem of observe border and dimensions on content
<dael> iank_: Border box size would be null in that call
<smfr> q+
<dael> Rossen: Verbosity of proposed API. The entity in the platform is the css box. All other boxes are properties of that object. My worry is if we go down path to expose such models where you are creating an identity for a property you're complicating lifetime of the API. Sounds a bit odd to me to go down that path
<dael> Rossen: Almost eq. of pretending any other property of box is a scriptable object
<astearns> ack smfr
<dael> smfr: One of the things I find odd is that we don't have any other APIs that return content box stuff. It seems odd to get these boxes is only resize observer. Why not expose on the things that are an imparitive to get boxes
<dael> smfr: Also odd API only returns sizes. I'd like rect for all of these and they should be relative to top left of border box
<dael> smfr: To resolve what changed is you return all rectangles and an enum to say which changed
<dael> astearns: Would be which changed, it's which of them changed
<dael> smfr: Yes
<dael> gregwhitworth: Not opposed to having results return in other static areas. THis was just an issue for the resize observer. Not sure if you want to expose in CSSOM or whatever.
<dael> gregwhitworth: smfr are you saying youw ant shape is what would be return from getClietnRects? I had talked with Alec (sp?) that we'd have getBoundingClientRects be what's returned for these boxes. But we said it's about size change not position
<dael> smfr: These rect are in local coordinates. Which I think is fine. This API shouldn't be able abspos or client pos. If you're giving size of contents I'd also like offset from top left. That seems natural and cheap to compute
<dael> gregwhitworth: Makes sense. Ic an open that issue. Are we providing for sake or is that a thing authors want commonly? That they want to check the offset
<dael> smfr: I would imagine the users care about fitting thigns inside. I think it's about size and not position
<dael> gregwhitworth: hen why include offsets? Just in case?
<dael> smfr: If you tell me content size I might want to know how much is border and how much padding. If I have to call gCS it might trigger a layout which is expensive so that should be in resize observer
<dael> smfr: One final piece of feedback on algo, but we can come back to that
<dael> gregwhitworth: That is good F2F item.
<dael> gregwhitworth: Rossen to your point on model, any other rec. on achieving the end case?
<dael> Rossen: If we're going to discuss at F2F I'd defer to then. Providing all the information in a property bag that doesn't require additional readbacks would be the preferred model.
<dael> Rossen: The misalignment seems a bit odd here
<dael> gregwhitworth: Okay
<dael> Rossen: Let's table and discuss at length at F2F
<dael> astearns: I'll add F2F tag