Re: [csswg-drafts] [css-sizing-4][css-contain-2] Revisiting auto-sizing when size-containment applies (#5668)

The CSS Working Group just discussed `[css-sizing-4][css-contain-2] Revisiting auto-sizing when size-containment applies`, and agreed to the following:

* `RESOLVED: align the behavior of auto sizing for size-containment with that of resizeObserver`

<details><summary>The full IRC log of that discussion</summary>
&lt;dael> Topic: [css-sizing-4][css-contain-2] Revisiting auto-sizing when size-containment applies<br>
&lt;dael> github: https://github.com/w3c/csswg-drafts/issues/5668<br>
&lt;dael> vmpstr: A little background. We have content-visibility:auto Way it works is when element goes offscreen we add size containment and when it's on screen we remove. Can change the scrollbar size which is undesired. Added contraint-intrinsic-size to manage this. Works great as a placeholder b/c gives some size even when size containment applies.<br>
&lt;dael> vmpstr: Problem is it's hard to know the right size so scrollbar can still jump. When element is on screen as it rolls offscreen browser knows size that would cause scrollbar not to jump. There is a value it oculd take. Broswer knows but it's not exposed<br>
&lt;dael> vmpstr: I think script can get an estimate<br>
&lt;dael> vmpstr: Prop is add an auto qualification to contain-intrinsic-size which is when size containment is first applied and when content has been previously rendered remember that size and use it as the value. Else use placeholder<br>
&lt;dael> vmpstr: Daniel and Christian raised some points that it adds dependency on sequence of steps.<br>
&lt;TabAtkins> q+<br>
&lt;smfr> q+<br>
&lt;dael> vmpstr: Wanted to bring to group. Hoping there's a solution that doesn't involve script. Maybe not this exact proposal, but this is what I have<br>
&lt;dael> TabAtkins: Point about non-determinism about exactly when size is recorded, while technically true it's a cost we eaten with animations. Style depends on exactly when it started so you know how far in animation you are. Since we've eaten that cost for animations I don't see why not here unless we think that was unavoidably broken<br>
&lt;dael> TabAtkins: We should think about htis the same as animation start<br>
&lt;Rossen_> ack TabAtkins<br>
&lt;Rossen_> ack smfr<br>
&lt;TabAtkins> smfr's idea makes sense to me as well<br>
&lt;TabAtkins> it's what you'd get if you did this by hand anyway<br>
&lt;dael> smfr: Slightly different prop is spec this exactly same as resizeObserver. Timing is well defined. Write the spec so you get the same behavior as if you registered a resize on it and that's the same size as you'd get with snapshot<br>
&lt;dael> vmpstr: Good idea. Question is when do we snapshot. If you add size containment and change another style I guess you first process size containment and snapshot at that time?<br>
&lt;dael> smfr: I think you would use size from the most recent event loop steps where your resize observer would have fired and given an answer. Might be loop before a style change that effects containment<br>
&lt;dael> smfr: That's last thing you saw on screen<br>
&lt;dael> vmpstr: Makes sense<br>
&lt;dael> chrishtr: resizeObserver is when content-visbility content is unskipped, right?<br>
&lt;dael> vmpstr: On the contents of the element. On the element itself the observer would still fire<br>
&lt;dael> chrishtr: So a polyfill would put it on the element and when it fires set contain intrinsic size on that. And smfr proposal is do that without any script<br>
&lt;dael> vmpstr: Pretty much. I've seen a polyfill that does that. I'm not sure what to do with padding and margins.<br>
&lt;dael> chrishtr: ResizeObserver allow syou to observe different boxes<br>
&lt;dael> vmpstr: Then yeah<br>
&lt;dael> chrishtr: What if it was independent of content visibility. It restricts to the c-i-s property<br>
&lt;dael> vmpstr: Content visibility was motivation. Proposal is change to contain intrsintic-size to save off the value<br>
&lt;dael> chrishtr: Only do when size containment wasn't present<br>
&lt;dael> vmpstr: Right. And just snapshot at the time size containment starts being applied<br>
&lt;Rossen_> q?<br>
&lt;dael> chrishtr: So if size containment isn't present that size is automatically reflected into contain-intrincis-size used value<br>
&lt;dael> Rossen_: Hearing alignment on prop from smfr to align with resizeObserver. Are we happy with that and then will work on additional details in the issue?<br>
&lt;chrishtr> q+sounds good to me<br>
&lt;dael> Rossen_: Objections to align the behavior of auto sizing for size-containment with that of resizeObserver<br>
&lt;dael> RESOLVED: align the behavior of auto sizing for size-containment with that of resizeObserver<br>
</details>


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


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Wednesday, 13 January 2021 17:29:27 UTC