[css-overflow] allow elements to escape the scroll container

[mayank99]

Problem/motivation

Currently, if an element is made into a scroll container (e.g. using overflow: auto or overflow: hidden), then nothing inside it can "escape" out.

It is often desirable for some parts to be able to escape. Consider three examples:

• box-shadow often needs to protrude out of the container. Very common.
• position: absolute is often used to make elements protrude out or be anchored near one of the edges. One use case is nested scrollable sub menus, demonstrated in the css-tricks article "Popping out of hidden overflow".
• transform can be used to displace an element out of the container. Used in combination with display: grid (e.g. place-self: end), this is a great way to place decorative or functional elements near the corners of the containers.

In all of these examples, the element gets clipped if it tries to escape the scroll container.

Ideas

There could be a simple way to make an element not be constrained by the scroll container.

.scroll-container {
  overflow: auto;

  .escape {
    overflow-escape: x; /* or y or both */
  }
}

@daviddarnes suggested a more powerful idea, where an element could specify which scroll container it wants to (not) be constrained by.

.scroll-container {
  overflow: auto;

  .escape {
    overflow-container: none;
  }
}

.scroll-container {
  overflow: auto;
  container-name: one;
  contain: overflow;

  .another-scroll-container {
    overflow: auto;
    container-name: two;

    .escape {
      overflow-container: one;
    }
  }
}

Another idea that might solve some use cases would be to allow individual elements to control their own version of overflow-clip-margin.

.escape {
  /* will be clipped if it goes more than 20px outside the scroll container */
  overflow-escape-margin: 20px;
}

[argyleink]

I've asked about this feature too 🙂

Here's a supportive component / use case for letting box-shadow exceed the scrollport:
https://gui-challenges.web.app/carousel/dist/

The design required padding-bottom to be enough so the shadows on the cards aren't cutoff. Original design had larger shadows but the amount of padding required for it, looked silly, so we compromised and found a middle ground between shadow size and block-end padding.

Here's the problem visualized, all I needed to do was put the larger box shadow back on the card:

and what was wanted:

[daviddarnes]

box-shadow and absolute positioned elements that intended to be dropdowns are the ones that get me the most. It's often the case that overflow is applied to an element to keep it contained in some fashion but then a nested child of that element needs to spill out.

I suppose there is a new alternative for dropdowns using the new anchor positioning properties to get that look of a dropdown appearing from an interacted element, however you'll have to break the semantic structure to prevent that anchored element from inheriting the overflow issue. For a nested set of lists that makes things worse if anything.

The linked solution that @mayank99 mentioned ends up with the author writing JavaScript to ultimately solve the problem they were facing, which for a dropdown like that seems like a necessary reach

[kizu]

Anchor positioning would allow escaping the scroll containers by using position: fixed, but that won't help for cases where the position: fixed would be contained, like if there'd be a transform. An ability to have something like “reparenting” of such elements would be handy. See a related discussion at #8588

[ydaniv]

Somewhat related to #8361 but with different outcome. The former was resolved to be adopted and the required effect is to allow content to not contribute to scrollable overflow, while here the effect is a bit similar, not to contribute to overflow, while also being able to escape the clipping effect.
Maybe considering these together can help the overall design?