- From: Ian Kilpatrick via GitHub <sysbot+gh@w3.org>
- Date: Tue, 12 Oct 2021 17:09:49 +0000
- To: public-css-archive@w3.org
So for all(?) of these cases roughly fall into this pattern: 1. Parent performs layout/intrinsic-sizes with some set of constraints. 2. Parent inspects the result of the layout/intrinsic-sizes (e.g. reads the block-size of the resulting layout). 3. Parent based in (2) updates the constraints (changing available-size to avoid floats). For this case the parent layout algorithms always walk forward. They don't go backwards. The easiest to look at here is the float case: https://codepen.io/miriamsuzanne/pen/mdmJRxW E.g. if we see that a fragment has a smaller block-size in area #2 we don't suddenly go backwards to try and get it to fit in area #1. This is somewhat implied by a lot of algorithms, for the float case we discussed it previously here: https://github.com/w3c/csswg-drafts/issues/2452 -- GitHub Notification of comment by bfgeek Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/6426#issuecomment-941205671 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 12 October 2021 17:09:51 UTC