w3c / w3c/csswg-drafts

[css-overflow-5] Can we relax size containment on ::scroll-marker-group?

Open
#11,166 10 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

css-overflow-5 Needs Edits
Dominant language
Bikeshed
Stars
4.9k
Forks
816
PR merge metrics
PR metrics pending

Description

The spec currently recommends the following default UA stylesheet:

/* 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.

<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 ::columns.

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 on whether its out of flow positioned? 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?

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with the css-overflow-5 scroll-marker-group pseudo-element section and the containment example in this issue. Compare the proposed alternatives, including absolutely positioned groups and anchor positioning, against the cycle described. Done requires a resolved CSS Working Group direction and corresponding specification update; the issue does not identify an implementation file or test.

Written by the indexing model from the issue text.

Assessment

Tech stack
css
Domain
frontend, web-dev
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.