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

flackr has just created a new issue for https://github.com/w3c/csswg-drafts:

== [css-overflow-5] Can we relax size containment on ::scroll-marker-group? ==
The [spec currently recommends](https://drafts.csswg.org/css-overflow-5/#scroll-marker-group-pseudo) the following default UA stylesheet:

```css
/* The generation of ::scroll-marker pseudo-elements shouldn’t
 * invalidate layout outside of this pseudo-element. */
::scroll-marker-group { contain: size !important; }
```

This is necessary to prevent cycles in certain cases, e.g. 
```html
<style>
.container { display: flex; height: 100vh; flex-direction: column; }
.scroller { columns: 1; flex: 1; scroll-marker-group: after; counter-reset: marker; }
.scroller::column::scroll-marker { counter-increment: marker; content: counter(marker); }
.scroller::scroll-marker-group { /* ... */ }
</style>
<div class="container"><div class="scroller">...</div></div>
```

Without size containment, the size of the `::scroll-marker-group` depends on the number / layout of the `::scroll-marker` elements that are within it. However, when the size of the group changes, it changes the space available for the scroller which could change the number of `::column`s.

However, having this size containment means that even in cases where the size doesn't affect the size of the scroller (e.g. `position: absolute`), they can't have it automatically sized and aligned based on its size, which adds a fair bit of complexity to achieving certain designs.

Some ideas that might make this less surprising or easier to work with:
1. Remove size containment and enforce out of flow positioning. This would make anchor positioning cases "just work", however would make it harder if you wanted to reserve space for the marker group to ensure it's not on top of anything.
2. Apply `overflow: auto` to make the problem more obvious when you're overflowing the space.
3. Something conditional? I'm not sure if there's any precedent for this.
4. Allow one layout cycle similar to a ResizeObserver based size change? This could be achieved by updating the initial `contain-intrinsic-size` after the first layout perhaps?
5. Something else?

Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/11166 using your GitHub account


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

Received on Thursday, 7 November 2024 16:40:00 UTC