[css-multicol] Should contained out-of-flow descendants affect column balancing? #6279
Comments
|
Safari is doing the same thing, so we do have interop in terms of browsers. So the question really is whether we are happy for multicol to behave differently to other things. |
|
The CSS Working Group just discussed
The full IRC log of that discussion<dael> Topic: [css-multicol] Should contained out-of-flow descendants affect column balancing?<dael> github: https://github.com//issues/6279 <dael> rachelandrew: This is another one about out of flow elements. Out of flow position box doesn't normally effect ancestor size. It is happening in multicol <dael> rachelandrew: We have interop,e veryone does same thing. It is different to have things behave with out of flow. Are we happy to have multicol behave different or do we want to change that <dael> astearns: We have interop but not based on spec text? <dael> rachelandrew: I think that's right <dael> fantasai: I think we do have a use case that people use multicol to emulate pages. That would want us to do same as paginated which is generate more pages and take up space. given we have interop and one reason to do it my suggestion would be to put what they're doing in spec <dael> astearns: Any opinions on the other side? <dael> astearns: Or just generally against <TYLin> +1 for current behavior <dael> astearns: Prop: Add the current interop situation to the spec <dael> astearns: Objections? <dael> RESOLVED: Add the current interop situation to the spec |
chromium-wpt-export-bot
pushed a commit
to web-platform-tests/wpt
that referenced
this issue
Jul 22, 2021
OOFs should affect column balancing: w3c/csswg-drafts#6279. As an initial implementation, this CL allows OOFs to affect the initial column balancing pass, which won't handle every case, but it should handle the cases of most interest. To accomplish this, lay out the OOFs normally inside their containing block during the initial column balancing pass, allowing the OOF to affect the initial column block size estimate. In order for the OOF to also affect the TallestUnbreakableBlockSize(), we needed to set up the constraint space in this case for fragmentation and propagate this information to the containing block's builder. Because OOFs now affect the initial column block size, there ended up being strange results when an OOF was discovered before a spanner. The OOF would affect the column block size for the columns before the spanner, but we would wait to layout the OOF officially until the multicol had finished layout. Because of this, we ended up adding new columns after the spanner with a smaller column block size. To fix this, this CL adds logic to the column layout algorithm to lay out any OOF descendants when we find a spanner using the newly added NGOutOfFlowLayoutPart::HandleFragmentation() function. This ensures that any OOF descendants found before a spanner are actually laid out before the spanner and take up the block size that they had initially contributed to. (See the updated unit tests as an example). Note that this doesn't work for nested fragmentation, and the related unit tests still result in slightly different behavior than the unnested case. Bug: 1206618 Change-Id: If21e1cac970289e569be9ab1a79030329732d613
chromium-wpt-export-bot
pushed a commit
to web-platform-tests/wpt
that referenced
this issue
Aug 2, 2021
OOFs should affect column balancing: w3c/csswg-drafts#6279. As an initial implementation, this CL allows OOFs to affect the initial column balancing pass, which won't handle every case, but it should handle the cases of most interest. To accomplish this, lay out the OOFs normally inside their containing block during the initial column balancing pass, allowing the OOF to affect the initial column block size estimate. In order for the OOF to also affect the TallestUnbreakableBlockSize(), we needed to set up the constraint space in this case for fragmentation and propagate this information to the containing block's builder. Because OOFs now affect the initial column block size, there ended up being strange results when an OOF was discovered before a spanner. The OOF would affect the column block size for the columns before the spanner, but we would wait to layout the OOF officially until the multicol had finished layout. Because of this, we ended up adding new columns after the spanner with a smaller column block size. To fix this, this CL adds logic to the column layout algorithm to lay out any OOF descendants when we find a spanner using the newly added NGOutOfFlowLayoutPart::HandleFragmentation() function. This ensures that any OOF descendants found before a spanner are actually laid out before the spanner and take up the block size that they had initially contributed to. (See the updated unit tests as an example). Note that this doesn't work for nested fragmentation, and the related unit tests still result in slightly different behavior than the unnested case. Bug: 1206618 Change-Id: If21e1cac970289e569be9ab1a79030329732d613
chromium-wpt-export-bot
pushed a commit
to web-platform-tests/wpt
that referenced
this issue
Aug 3, 2021
OOFs should affect column balancing: w3c/csswg-drafts#6279. As an initial implementation, this CL allows OOFs to affect the initial column balancing pass, which won't handle every case, but it should handle the cases of most interest. To accomplish this, lay out the OOFs normally inside their containing block during the initial column balancing pass, allowing the OOF to affect the initial column block size estimate. In order for the OOF to also affect the TallestUnbreakableBlockSize(), we needed to set up the constraint space in this case for fragmentation and propagate this information to the containing block's builder. Because OOFs now affect the initial column block size, there ended up being strange results when an OOF was discovered before a spanner. The OOF would affect the column block size for the columns before the spanner, but we would wait to layout the OOF officially until the multicol had finished layout. Because of this, we ended up adding new columns after the spanner with a smaller column block size. To fix this, this CL adds logic to the column layout algorithm to lay out any OOF descendants when we find a spanner using the newly added NGOutOfFlowLayoutPart::HandleFragmentation() function. This ensures that any OOF descendants found before a spanner are actually laid out before the spanner and take up the block size that they had initially contributed to. (See the updated unit tests as an example). Note that this doesn't work for nested fragmentation, and the related unit tests still result in slightly different behavior than the unnested case. Bug: 1206618 Change-Id: If21e1cac970289e569be9ab1a79030329732d613
chromium-wpt-export-bot
pushed a commit
to web-platform-tests/wpt
that referenced
this issue
Aug 3, 2021
OOFs should affect column balancing: w3c/csswg-drafts#6279. As an initial implementation, this CL allows OOFs to affect the initial column balancing pass, which won't handle every case, but it should handle the cases of most interest. To accomplish this, lay out the OOFs normally inside their containing block during the initial column balancing pass, allowing the OOF to affect the initial column block size estimate. In order for the OOF to also affect the TallestUnbreakableBlockSize(), we needed to set up the constraint space in this case for fragmentation and propagate this information to the containing block's builder. Because OOFs now affect the initial column block size, there ended up being strange results when an OOF was discovered before a spanner. The OOF would affect the column block size for the columns before the spanner, but we would wait to layout the OOF officially until the multicol had finished layout. Because of this, we ended up adding new columns after the spanner with a smaller column block size. To fix this, this CL adds logic to the column layout algorithm to lay out any OOF descendants when we find a spanner using the newly added NGOutOfFlowLayoutPart::HandleFragmentation() function. This ensures that any OOF descendants found before a spanner are actually laid out before the spanner and take up the block size that they had initially contributed to. (See the updated unit tests as an example). Note that this doesn't work for nested fragmentation, and the related unit tests still result in slightly different behavior than the unnested case. Bug: 1206618 Change-Id: If21e1cac970289e569be9ab1a79030329732d613
chromium-wpt-export-bot
pushed a commit
to web-platform-tests/wpt
that referenced
this issue
Aug 3, 2021
OOFs should affect column balancing: w3c/csswg-drafts#6279. As an initial implementation, this CL allows OOFs to affect the initial column balancing pass, which won't handle every case, but it should handle the cases of most interest. To accomplish this, lay out the OOFs normally inside their containing block during the initial column balancing pass, allowing the OOF to affect the initial column block size estimate. In order for the OOF to also affect the TallestUnbreakableBlockSize(), we needed to set up the constraint space in this case for fragmentation and propagate this information to the containing block's builder. Because OOFs now affect the initial column block size, there ended up being strange results when an OOF was discovered before a spanner. The OOF would affect the column block size for the columns before the spanner, but we would wait to layout the OOF officially until the multicol had finished layout. Because of this, we ended up adding new columns after the spanner with a smaller column block size. To fix this, this CL adds logic to the column layout algorithm to lay out any OOF descendants when we find a spanner using the newly added NGOutOfFlowLayoutPart::HandleFragmentation() function. This ensures that any OOF descendants found before a spanner are actually laid out before the spanner and take up the block size that they had initially contributed to. (See the updated unit tests as an example). Note that this doesn't work for nested fragmentation, and the related unit tests still result in slightly different behavior than the unnested case. Bug: 1206618 Change-Id: If21e1cac970289e569be9ab1a79030329732d613 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3018723 Commit-Queue: Alison Maher <almaher@microsoft.com> Reviewed-by: Morten Stenshorne <mstensho@chromium.org> Cr-Commit-Position: refs/heads/master@{#908157}
chromium-wpt-export-bot
pushed a commit
to web-platform-tests/wpt
that referenced
this issue
Aug 3, 2021
OOFs should affect column balancing: w3c/csswg-drafts#6279. As an initial implementation, this CL allows OOFs to affect the initial column balancing pass, which won't handle every case, but it should handle the cases of most interest. To accomplish this, lay out the OOFs normally inside their containing block during the initial column balancing pass, allowing the OOF to affect the initial column block size estimate. In order for the OOF to also affect the TallestUnbreakableBlockSize(), we needed to set up the constraint space in this case for fragmentation and propagate this information to the containing block's builder. Because OOFs now affect the initial column block size, there ended up being strange results when an OOF was discovered before a spanner. The OOF would affect the column block size for the columns before the spanner, but we would wait to layout the OOF officially until the multicol had finished layout. Because of this, we ended up adding new columns after the spanner with a smaller column block size. To fix this, this CL adds logic to the column layout algorithm to lay out any OOF descendants when we find a spanner using the newly added NGOutOfFlowLayoutPart::HandleFragmentation() function. This ensures that any OOF descendants found before a spanner are actually laid out before the spanner and take up the block size that they had initially contributed to. (See the updated unit tests as an example). Note that this doesn't work for nested fragmentation, and the related unit tests still result in slightly different behavior than the unnested case. Bug: 1206618 Change-Id: If21e1cac970289e569be9ab1a79030329732d613 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3018723 Commit-Queue: Alison Maher <almaher@microsoft.com> Reviewed-by: Morten Stenshorne <mstensho@chromium.org> Cr-Commit-Position: refs/heads/master@{#908157}
blueboxd
pushed a commit
to blueboxd/chromium-legacy
that referenced
this issue
Aug 4, 2021
OOFs should affect column balancing: w3c/csswg-drafts#6279. As an initial implementation, this CL allows OOFs to affect the initial column balancing pass, which won't handle every case, but it should handle the cases of most interest. To accomplish this, lay out the OOFs normally inside their containing block during the initial column balancing pass, allowing the OOF to affect the initial column block size estimate. In order for the OOF to also affect the TallestUnbreakableBlockSize(), we needed to set up the constraint space in this case for fragmentation and propagate this information to the containing block's builder. Because OOFs now affect the initial column block size, there ended up being strange results when an OOF was discovered before a spanner. The OOF would affect the column block size for the columns before the spanner, but we would wait to layout the OOF officially until the multicol had finished layout. Because of this, we ended up adding new columns after the spanner with a smaller column block size. To fix this, this CL adds logic to the column layout algorithm to lay out any OOF descendants when we find a spanner using the newly added NGOutOfFlowLayoutPart::HandleFragmentation() function. This ensures that any OOF descendants found before a spanner are actually laid out before the spanner and take up the block size that they had initially contributed to. (See the updated unit tests as an example). Note that this doesn't work for nested fragmentation, and the related unit tests still result in slightly different behavior than the unnested case. Bug: 1206618 Change-Id: If21e1cac970289e569be9ab1a79030329732d613 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3018723 Commit-Queue: Alison Maher <almaher@microsoft.com> Reviewed-by: Morten Stenshorne <mstensho@chromium.org> Cr-Commit-Position: refs/heads/master@{#908157}
moz-v2v-gh
pushed a commit
to mozilla/gecko-dev
that referenced
this issue
Aug 6, 2021
…testonly Automatic update from web-platform-tests [LayoutNG] OOFs and column balancing OOFs should affect column balancing: w3c/csswg-drafts#6279. As an initial implementation, this CL allows OOFs to affect the initial column balancing pass, which won't handle every case, but it should handle the cases of most interest. To accomplish this, lay out the OOFs normally inside their containing block during the initial column balancing pass, allowing the OOF to affect the initial column block size estimate. In order for the OOF to also affect the TallestUnbreakableBlockSize(), we needed to set up the constraint space in this case for fragmentation and propagate this information to the containing block's builder. Because OOFs now affect the initial column block size, there ended up being strange results when an OOF was discovered before a spanner. The OOF would affect the column block size for the columns before the spanner, but we would wait to layout the OOF officially until the multicol had finished layout. Because of this, we ended up adding new columns after the spanner with a smaller column block size. To fix this, this CL adds logic to the column layout algorithm to lay out any OOF descendants when we find a spanner using the newly added NGOutOfFlowLayoutPart::HandleFragmentation() function. This ensures that any OOF descendants found before a spanner are actually laid out before the spanner and take up the block size that they had initially contributed to. (See the updated unit tests as an example). Note that this doesn't work for nested fragmentation, and the related unit tests still result in slightly different behavior than the unnested case. Bug: 1206618 Change-Id: If21e1cac970289e569be9ab1a79030329732d613 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3018723 Commit-Queue: Alison Maher <almaher@microsoft.com> Reviewed-by: Morten Stenshorne <mstensho@chromium.org> Cr-Commit-Position: refs/heads/master@{#908157} -- wpt-commits: 380dd71fdb7fe4a22a88389e61759bb1f988434f wpt-pr: 29748
mjfroman
pushed a commit
to mjfroman/moz-libwebrtc-third-party
that referenced
this issue
Oct 14, 2022
OOFs should affect column balancing: w3c/csswg-drafts#6279. As an initial implementation, this CL allows OOFs to affect the initial column balancing pass, which won't handle every case, but it should handle the cases of most interest. To accomplish this, lay out the OOFs normally inside their containing block during the initial column balancing pass, allowing the OOF to affect the initial column block size estimate. In order for the OOF to also affect the TallestUnbreakableBlockSize(), we needed to set up the constraint space in this case for fragmentation and propagate this information to the containing block's builder. Because OOFs now affect the initial column block size, there ended up being strange results when an OOF was discovered before a spanner. The OOF would affect the column block size for the columns before the spanner, but we would wait to layout the OOF officially until the multicol had finished layout. Because of this, we ended up adding new columns after the spanner with a smaller column block size. To fix this, this CL adds logic to the column layout algorithm to lay out any OOF descendants when we find a spanner using the newly added NGOutOfFlowLayoutPart::HandleFragmentation() function. This ensures that any OOF descendants found before a spanner are actually laid out before the spanner and take up the block size that they had initially contributed to. (See the updated unit tests as an example). Note that this doesn't work for nested fragmentation, and the related unit tests still result in slightly different behavior than the unnested case. Bug: 1206618 Change-Id: If21e1cac970289e569be9ab1a79030329732d613 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3018723 Commit-Queue: Alison Maher <almaher@microsoft.com> Reviewed-by: Morten Stenshorne <mstensho@chromium.org> Cr-Commit-Position: refs/heads/master@{#908157} NOKEYCHECK=True GitOrigin-RevId: bb4374a017ebecb7343e71a536435b7966050c48
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Out-of-flow positioned boxes usually don't affect the size of their ancestors (with the exception of any scrollbars that an OOF might cause).
However:
Gecko and Blink show three blue squares in a 100px tall yellow multicol container here, i.e. the OOF affects the height of the multicol container. Is this how we want things?
The text was updated successfully, but these errors were encountered: