[css-flexbox] Flexbox alignment and fragmentation

@mstensho

According to the sample flex fragmentation algorithm in the spec:

This algorithm assumes that pagination always proceeds only in the forward direction; therefore, in the algorithms below, alignment is mostly ignored prior to pagination. Advanced layout engines may be able to honor alignment across fragments.

In other words, the algorithm suggests performing alignment per fragment in the case of flex. Although the note isn't subscriptive, other algorithms such as grid fragmentation and table fragmentation don't mention a similar suggestion for alignment. Would it make sense to remove this note from the flexbox spec to better match the other algorithms?

Note: neither Gecko or Chromium currently perform flex alignment per fragment.

cc @mstensho @bfgeek

Grid fragmentation and table fragmentation overall have less details on how to fragment. Keep in mind also this entire section is non-normative. This is because fragmentation is hard and there's no obviously correct answer for how to do it for grid and flex layout; defining fragmentation precisely is therefore out of scope for Level 1.

However, that doesn't mean it's best to ignore alignment when fragmenting. Ideally, fragmented pages stitched back together should look as similar as possible to unfragmented pages; adjustments away from that ideal need to have some justification.

So, handling alignment globally (for the entire grid / flex / table) would disrupt layout less (if we imagine that we stitch all fragments back together afterwards). But then there's margins, and the spec at https://drafts.csswg.org/css-break/#break-margins says to truncate margins at soft breaks. We'd probably want to change that as well, if we are to go down this path.

The other option would be to leave the css-break spec unchanged, and perform alignment per fragment.

Truncating margins but still attempting to perform alignment globally doesn't make sense to me.

However, that doesn't mean it's best to ignore alignment when fragmenting. Ideally, fragmented pages stitched back together should look as similar as possible to unfragmented pages; adjustments away from that ideal need to have some justification.

Apologies, I didn't make this clear in my original post. The proposal would be to perform alignment globally (as Morten mentioned above) rather than per fragment or not at all. Performing alignment globally would result in a layout that is more similar to its unfragmented counterpart than what is currently suggested in the spec.

If we do decide to apply alignment globally, though, rethinking how we handle margins would make sense to me, as well. Firefox, at least in the case of flex fragmentation, currently applies alignment globally, and margins do not get truncated.

[FlexNG] Add OOF in flexbox fragmentation tests

So you want to remove the note that's the only allusion to the behavior you actually want to have here? I don't understand.

@fantasai

@fantasai The note, along with the various flex fragmentation algorithms below the note, suggest applying alignment per fragment. Since the specs for grid and table don't mention a similar note, the assumption for those is to apply alignment globally, which can lead implementors to handle alignment when fragmenting differently for the different display types.

For example, EdgeHTML applies alignment per fragment for flexbox but globally for grid. The idea of removing the note in the flexbox spec (and I suppose we would also need to update the algorithms to match) was to create consistency with grid and table in how to handle alignment.

However, keeping the note would be fine with me, as well, as long as the implication matches however we decide to apply alignment across the board, and as long as we add similar messaging to the specs for table and grid.

If we do decide to suggest applying alignment globally, instead, we might also need to update the spec at https://drafts.csswg.org/css-break/#break-margins since we probably don't want to truncate margins if alignment is handled globally.

@alisonmaher

@alisonmaher Aligning Grid and Flexbox seems reasonable to me, but the note is explaining why the sample algorithm in the spec doesn't honor alignment “globally” (as you put it), and suggesting that more advanced engines could do it. So I don't see why you're having a problem with it?

As for margins, I'm less certain about that. We do truncate margins between pages in block layout for good reason: it's generally not wanted to have blank space at the top of a page. For some grids, the margin might play a role in lining things up, but in a lot of cases it's there to provide space between boxes, and when fragmenting across pages it's not wanted.

@fantasai

Aligning Grid and Flexbox seems reasonable to me, but the note is explaining why the sample algorithm in the spec doesn't honor alignment “globally” (as you put it), and suggesting that more advanced engines could do it. So I don't see why you're having a problem with it?

@fantasai I think as long as we are consistent between algorithms, I'm ok with the note. If implementors are converging toward applying alignment globally, though, wouldn't it make sense to update the spec to match? And then perhaps the note could suggest the opposite (i.e. "UAs may ignore alignment prior to fragmentation if needed")?

Regarding margins, I agree that in the case of block layout, truncating can be helpful. I'm not convinced that it makes as much sense when performing alignment globally, though, so perhaps we could add a special note about truncating margins for algorithms that perform alignment?

Bug 1744554 [wpt PR 31915] - [FlexNG] Add OOF in flexbox fragmentatio…

[FlexNG] Don't truncate margins for flex items

Bug 1757673 [wpt PR 33027] - [FlexNG] Don't truncate margins for flex…

@fantasai

RESOLVED: we will not truncate margins at any break when aligning globally for fragmentation

@fantasai and I have been reviewing this to see what edits might still need to be made, and we're not sure what this is supposed to mean. At least, it doesn't appear that the Chromium implementation (which, it appears, is what drove the resolution) has behavior that can be explained as matching the resolution.

Given the following markup:

<!DOCTYPE html>
<style>
  body { columns: 10em; column-fill: auto; height: 4em; orphans: 1; widows: 1;} 
  .container { border-left:solid fuchsia; }
  .flex { border: blue solid; display: flex; flex-flow: wrap column; height: 10em }
  .flex > div { border: solid orange; width: 3em; margin: .5em}
</style>

<div class="container">
<div class="flex">
  <div>1ABC</div>
  <div>2ABC</div>
  <div>3ABC</div>
  <div>4ABC</div>
</div>
</div>

I get the following rendering in Chrome on Windows:

Clearly margins are being truncated in some cases - the 2ABC item is flush with the top of the column. But not in all cases - the 4ABC item is not flush. (And is overflowing its fragment slightly...)

We're not sure what exactly the behavior being demonstrated here is, but we theorize that the margins are being fragmented independently from the boxes they belong to. In this example, then, the 2ABC top margin fits in the first column, so it stays there, but 2ABC itself has to move to the next column, sans its margin. Meanwhile, 4ABC's top margin doesn't have enough space to fit into the second column, so it moves to the third column alongside 4ABC itself.

So, what is the actual behavior that we want here?

The margin before 2ABC isn't actually truncated. It's placed in the first column. The border box doesn't fit there, though, so it ends up in the second column. This is in line with #6812 (comment) - try to disrupt as little as possible when fragmenting. If we were to push the margin before 2ABC into the second column as well, content would become even taller (compared to when not fragmenting) -> more disruption.

The overflow in the third column is caused by the specified flex container height of 10em.

Note that the margins may even be sliced across columns (in Blink):

<!DOCTYPE html>
<div style="columns:3; height:100px; background:yellow;">
  <div style="display:flex; flex-flow:column;">
    <div style="height:50px; background:cyan;"></div>
    <div style="break-inside:avoid; margin-top:60px; height:50px; background:hotpink;"></div>
  </div>
</div>

Again, to cause as little disruption as possible.

I think the question here was whether to perform alignment per fragment, or do it globally for the flex container (Blink still does the latter (Gecko too)), or hardly perform any alignment at all (what the spec suggests).

<!DOCTYPE html>
<div style="columns:3; height:100px; column-fill:auto; background:yellow;">
  <div style="display:flex; height:250px;">
    <div>a</div>
    <div id="b" style="align-self:flex-end;">b</div>
  </div>
</div>

Should #b be placed at the bottom of the first fragment, or should it be placed at the bottom of the flex container (somewhere in the third column)? OR at the very start, which is what the spec https://drafts.csswg.org/css-flexbox/#pagination-algo suggests:

single-line row flex container
Run the entire flex layout algorithm (without regards to pagination), except treat any align-self other than flex-start or baseline as flex-start.

But we don't do that. We honor align-self, and apply it globally, for the entire flex container, not per fragment.

Bug 1744554 [wpt PR 31915] - [FlexNG] Add OOF in flexbox fragmentatio…

Bug 1757673 [wpt PR 33027] - [FlexNG] Don't truncate margins for flex…

Navigation Menu

Repository navigation

[css-flexbox] Flexbox alignment and fragmentation #6812

5 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

[css-flexbox] Flexbox alignment and fragmentation #6812

Description

Activity

fantasai commented on Nov 19, 2021

mstensho commented on Nov 22, 2021

alisonmaher commented on Nov 29, 2021

fantasai commented on Dec 14, 2021

alisonmaher commented on Dec 14, 2021

fantasai commented on Dec 15, 2021

fantasai commented on Dec 15, 2021

alisonmaher commented on Dec 15, 2021

alisonmaher commented on Dec 15, 2021

5 remaining items

tabatkins commented on Jan 11, 2025

mstensho commented on Jan 13, 2025

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions