Re: [csswg-drafts] [resize-observer] Which box information should we pass to the callback (#3329)

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

<details><summary>The full IRC log of that discussion</summary>
&lt;dael> Topic: Which box information should we pass to the callback<br>
&lt;dael> github: https://github.com/w3c/csswg-drafts/issues/3329#issuecomment-452477429<br>
&lt;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.<br>
&lt;dael> gregwhitworth: WE don't want author putting multi observers to watch multiple boxes.<br>
&lt;dael> gregwhitworth: What would happen is in the issue. We would return border box, content size box, scroll box, and device pixel border box.<br>
&lt;dael> iank_: I'm observing border box size and the content box size changes, am I notified?<br>
&lt;dael> gregwhitworth: No. If you want the content box you should observe it<br>
&lt;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?<br>
&lt;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.<br>
&lt;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<br>
&lt;dael> iank_: Border box size would be null in that call<br>
&lt;smfr> q+<br>
&lt;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<br>
&lt;dael> Rossen: Almost eq. of pretending any other property of box is a scriptable object<br>
&lt;astearns> ack smfr<br>
&lt;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<br>
&lt;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<br>
&lt;dael> smfr: To resolve what changed is you return all rectangles and an enum to say which changed<br>
&lt;dael> astearns: Would be which changed, it's which of them changed<br>
&lt;dael> smfr: Yes<br>
&lt;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.<br>
&lt;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<br>
&lt;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<br>
&lt;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<br>
&lt;dael> smfr: I would imagine the users care about fitting thigns inside. I think it's about size and not position<br>
&lt;dael> gregwhitworth: hen why include offsets? Just in case?<br>
&lt;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<br>
&lt;dael> smfr: One final piece of feedback on algo, but we can come back to that<br>
&lt;dael> gregwhitworth: That is good F2F item.<br>
&lt;dael> gregwhitworth: Rossen to your point on model, any other rec. on achieving the end case?<br>
&lt;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.<br>
&lt;dael> Rossen: The misalignment seems a bit odd here<br>
&lt;dael> gregwhitworth: Okay<br>
&lt;dael> Rossen: Let's table and discuss at length at F2F<br>
&lt;dael> astearns: I'll add F2F tag<br>
</details>


-- 
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/3329#issuecomment-456897554 using your GitHub account

Received on Wednesday, 23 January 2019 17:42:30 UTC