[resize-observer] Add offset position to rects

[gregwhitworth]

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

<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

@smfr wanted to have the offsets included rather than just the dimensions so that if the authors want that data they're aren't potentially flushing the pipeline again to retrieve it. Opening this issue to track that since the other issue is specifically about whether to return all boxes or the ones that are specified.

[gregwhitworth]

@atotic and I discussed this, we also looked at real world usage and providing the offsets of an individual box relative to its closest other box does not provide enough information to be useful.

Another good point which aligns with what @bfgeek brought up in the issue regarding which box info to return, we're currently only allowing observations on the inline or block dimensions, not their offsets. So if we report the offsets and they're used within but not observed the information will be out of sync.

In addition to this, we didn't find any usecases for needing this information in relation to resizeObserver. @smfr since you raised this issue I'd like to hear your thoughts as we're currently leaning to not adding the offsets.

[css-meeting-bot]

The CSS Working Group just discussed Add offset pos, and agreed to the following:

• RESOLVED: Don't include offsets for the box being observed.

The full IRC log of that discussion

<heycam> Topic: Add offset pos
<gregwhitworth> Github: https://github.com//issues/3550
<heycam> gregwhitworth: Simon brought up that the position of the rects you're observing
<heycam> ... say the author wants to observe the content rect, you want both the tlbr offsets relative to the box
<heycam> ... Alex and I discussed this. Ian brought up a valid pint, we're not observing the offsets
<heycam> .. beingable to use the offsets inside the observer may cause stale issues
<heycam> ... only when dimensions change do you fire the observer
<heycam> smfr: which box?
<heycam> gregwhitworth: the one you're watching
<heycam> ... say you're observing context box
<heycam> ... you' dget the dimensions of that back
<heycam> ... you asked about having the offsets in there sa well
<heycam> ... use counters say that isn't common
<heycam> ... Ian brought up looking at the offsets when not firing the observer
<heycam> ... you'd want to add that you're also observing offsets
<heycam> smfr: so author could change border and padding so the content box doesn't change
<heycam> alex: you'd have to put two boxes together if you really wanted to know the offsets
<heycam> smfr: I suggested it for completeness. if it adds complexity I don't feel strongly
<heycam> iank_: if we need it eventually, it should be trivial to extend to support this
<heycam> gregwhitworth: but also need to add observing offsets
<heycam> iank_: but we haven't painted ourselves into a corner
<heycam> stefan: the behavior is polyfillable if oyu have a 100% div inside
<heycam> ... if the size changes, the offsets will have chnaged
<heycam> dbaron: I like the idea that hte pieces of data you provide are the ones you're observing
<heycam> ... don't like having data in there that you're using which you don't get notifications for
<heycam> RESOLVED: Don't include offsets for the box being observed.

[gregwhitworth]

To summarize the above, it was resolved to not include the offsets of the box that is being observed as the offsets are not actually be observed and thus can be stale. In addition, looking at utilization for this - the offsets are not normally utilized and in a situation where someone is wanting to do custom layout the Houdini Layout API is a better approach.