[css-flexbox] Flexbox alignment and fragmentation

[alisonmaher]

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

[fantasai]

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.

[mstensho]

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.

[alisonmaher]

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.

[fantasai]

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.

[alisonmaher]

@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.

[fantasai]

@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?

[fantasai]

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.

[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?

@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")?

[alisonmaher]

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?

[css-meeting-bot]

The CSS Working Group just discussed [css-flexbox] Flexbox alignment and fragmentation, and agreed to the following:

• RESOLVED: We will spec that grid, flex, and table fragmentation align globally before fragments are created
• RESOLVED: we will not truncate margins at any break when aligning globally for fragmentation

The full IRC log of that discussion

<dael> Topic: [css-flexbox] Flexbox alignment and fragmentation
<dael> github: https://github.com//issues/6812
<dael> alisonmaher: This is about handling alignment when fragmeneting. Issue also applies to grid and tables
<dael> alisonmaher: According to spec it suggest align per fragment. Flexbox is only that makes this suggestion. Can confuse impl and may imply flexbox is unique.
<dael> alisonmaher: Would it make sesne to change to suggest align prior and can ignore
<dael> alisonmaher: Advantage of ahead of time is it layout more similar to non-fragment. Consiquence is how to handle margins. Spec says truncate at soft break and they can affect alignments so may not want to truncate
<dael> alisonmaher: FF does not truncate
<dael> alisonmaher: prop: update to match FF for margins during fragmentation and add similar language in grid and tables
<dael> iank_: broadly supportive
<dael> iank_: When fragmenting, doing it globaly somewhat makes most sense when you look. Otherwise you can get things in unexpected columns and not aligning at the end
<dael> astearns: I'm not entirely convinced of the preference for stitching back together in way that looks more like unfragmented, but not against the change
<florian> q+
<dael> astearns: If there is a use case for align per fragment is that a switch we can add, maybe like how we do box decoration breaks where an author can choose?
<dael> iank_: Potentially. I think for that case what we might do is treat everything as start aligned and do alignment then
<dael> iank_: one thing that should be said is this would match what impl do in reality. Blink at the moment b/c we're adding proper fragmentation and fixing bugs
<dael> iank_: Theoretically possible to haev a switch. Place where per fragment makes sense is content-alignment. But that's different
<dael> dholbert: Justify content?
<dael> iank_: No, talking about...what's the keyword...we don't have it, I think only FF does. Let me look it up
<dael> dholbert: first-basline and last-baseline?
<dael> iank_: Ignore my last comment. I'm confused.
<astearns> ack florian
<dael> florian: Usually when it comes to things that relate to fragmentation print formatters have spent more time on this. prince at least supports both fragmentation and flexbox. Might be worth looking at what they do. If it's not what we're proposing we should think about it more
<dael> iank_: This is slightly larger than flexbox since it applies to grid and table
<dael> florian: I don't remember if they do grid. Might
<dael> iank_: For grid doesn't make a lot of sense to do by fragment
<dael> florian: I don't have an objection, but given it applies to things important to print formatters it's worth looking at what they do. We can make a revision and put a to do to look and revisit if needed
<dael> astearns: Is there a good person to tag? I would go to Dave Cramer but I'm not sure how much time he has for CSS
<dael> florian: That was my answer as well
<GameMaker> present_
<dael> astearns: Maybe we can tag Dave and see if he can give us an idea of what Prince is doing. Somewhat convinced we should take the proposal since it's what FF is doing. If there is a difference we can think again
<dael> dholbert: FF supports the change. It feels like most coherent thing to do
<dael> iank_: That's what I came to as well. It falls out to make most sense
<dael> astearns: Prop 1: We will spec that grid, flex, and table fragmentation align globally before fragments are created
<dael> alisonmaher: Correct
<dael> astearns: Do we need anything about margins in that resolution?
<dael> alisonmaher: Sep
<dael> astearns: Concerns about that resolution?
<dael> astearns: Obj?
<dael> RESOLVED: We will spec that grid, flex, and table fragmentation align globally before fragments are created
<dael> alisonmaher: Margins want when handling alignment globally shouldn't truncate margins at soft breaks
<dael> astearns: Can we do that without causing any cycles in determining if a soft break
<dael> alisonmaher: I think FF already doesn't truncate margins in flexbox case so I think there's a prior for it
<dael> astearns: Okay. Interested in seeing test cases we can apply for this. Seems to me lots of weird edge cases for particular kinds of margins. I suspect not well tested
<dael> alisonmaher: Yeah
<dael> astearns: Anything more to discuss about margins?
<dael> dholbert: Additional point, when doing global alignment the thing aligned is the margin box which is why it makes sense to preserve the margins
<dael> astearns: when we are aligning globally we will not truncate margins at any break
<dael> alisonmaher: We could say it generally
<dael> astearns: Prop: we will not truncate margins at any break when aligning globally for fragmentation
<dael> RESOLVED: we will not truncate margins at any break when aligning globally for fragmentation
<dael> astearns: Blink is going through this and will be adding new fragmentation code. Test cases as you go?
<dael> alisonmaher: Yeah
<dael> astearns: alisonmaher would you ping Dave Cramer?
<dael> alisonmaher: Sure

[alisonmaher]

@dauwhe in the resolution above, we had resolved to apply alignment globally instead of per fragment for flexbox, grid and tables when fragmenting.

The question of how print formatters handles alignment arose during the conversation. Do you by chance know if the above resolution conflicts with what print is doing, or if there may be others who would be worth pinging to confirm?