Re: [csswg-drafts] [css-flexbox] Flexbox alignment and fragmentation (#6812)

> 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:
    
![flex-fragmentation-screenshotpng](https://github.com/user-attachments/assets/8c59a82b-b69c-4e04-bb36-0073e517aec2)

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?

-- 
GitHub Notification of comment by tabatkins
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/6812#issuecomment-2584970370 using your GitHub account


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

Received on Saturday, 11 January 2025 00:59:21 UTC