Re: [csswg-drafts] [css-overflow-5] Can we relax size containment on ::scroll-marker-group? (#11166)

> If it wouldn't be better to try not to get in developers ways since most of the time even with in-flow examples the layout would be stable.

In-flow without containment?

```html
<!DOCTYPE html>
<style>
  .container {
    width: 700px;
  }
  .scroller {
    overflow: auto;
    columns: 1;
    height: 110px;
    scroll-marker-group: before;
    background: yellow;
  }
  .scroller::scroll-marker-group {
    /* Look at me! No extrinsic size! */
    float: left;
    background: hotpink;
  }
  .item {
    display: inline-block;
    width: 300px;
    height: 70px;
    margin: 10px;
    background: cyan;
  }
  .scroller::column::scroll-marker {
    display: inline-block;
    width: 50px;
    height: 50px;
    content: "*";
  }
</style>
<div class="container">
  <div class="scroller">
    <div class="item"></div>
    <div class="item"></div>
    <div class="item"></div>
    <div class="item"></div>
    <div class="item"></div>
  </div>
</div>
```

With a `.container` width of 700px, two `.item`s (of width 300px plus margins and whitespace) will fit beside each other in each column. With 5 items, that means 3 columns, and therefore 3 scroll markers. 3 scroll markers need 50px * 3 plus some whitespace; let's say 160px. The scroll marker group is floated, and will be placed beside the scroller. If we were to take that into account, now there's only 700px - 160px = 540px space available for the scroller, which means that only one item will fit in each column (since items are 300px wide). Which means that we'll get 5 columns. And the final width of the scroll marker group should become 50px * 5 plus some whitespace; let's say 270px. 

So I guess we can say that it's stable in this case, although it took a couple of rounds. At least no circular dependencies (but I'm sure it's possible to come up with an example of that as well).

The main problem with supporting this (apart from detecting and speccing circular dependencies) is that we would have to do non-trivial amounts of work on every layout algorithm, basically teach them all that the contents of one element may affect the contents of a sibling. This would be a project comparable to adding support for block fragmentation to all layout algorithms, which we did, since we had to, and that took some years, and, like block fragmentation, it would add a heavy maintenance burden.

I'd like to go through the other options, the way I see them:

Option 1 isn't any weirder than what we currently have. Instead of enforced containment, we have enforced out-of-flow. Exchanging one disadvantage for another. I think enforcing containment is less of a disadvantage than enforcing out-of-flow, though?

Not sure what option 2 would give us, apart from annoying behavior if the developer has messed up. :)

Option 4 will allow for some chain reactions (example above) (probably even circular dependencies). The size of the scroll marker group could then affect the size of the scroller and/or its ancestors.

So option 3 seems like the best option to me, although implying containment from in-flowness is a new invention.

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


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

Received on Wednesday, 4 December 2024 09:03:40 UTC