[css-overflow-4] Allow scrollable overflow to be visible in the off-axis / overflow-clip-margin

[freedebreuil]

When developers create scroll containers that only scroll in one direction, they’ll sometimes have use cases where content needs to overflow visually in the other axis. Per the css-overflow-3 spec:

The visible/clip values of overflow compute to auto/hidden (respectively) if one of overflow-x or overflow-y is neither visible nor clip.

Per WG #12289:

RESOLVED: Allow overflow: clip in other axis of a scrollable container. It is still a scroll container but prevents scrolling away from origin in that axis

This means if you set the off-axis to clip, it will clip the contents as expected. However, if you set the off-axis to visible, it will compute to auto. This leads to the same sort of issues as #12289, such as calls to scrollIntoView or anchor link scrolls accidentally scrolling vertical content.

Additionally, it is unclear if overflow-clip-margin applies to clip in the off-axis. If allowed, setting this to a high value (e.g. 100vh) would be equivalent to visible. It would be preferable to allow an intentional solution here. Also, it would allow content-visibility:auto to work with ink overflow in the off-axis.

An example use case is a Horizontal Carousel with off-axis visual overflow. It’s possible to get similar effects with negative margins or anchor positioning - but are more complex to create and maintain.

Proposal 1: We should allow overflow-clip-margin to apply in the off-axis when set to clip, expanding the overflow clip edge for a single axis.

Proposal 2: If we accept (1), allow overflow visible in the off-axis, enabling elements to allow visual overflow for a single axis.

/cc @flackr

[flackr]

One big compat issue to note regarding proposal 2, with visible as the initial value, it will be extremely common that authors have specified one axis, e.g. overflow-x: auto; and not the other, having a specified overflow-y: visible;. I suspect it will not be web compatible to stop coercing the other axis in these cases. I think we can do this, but we would need to add a new initial value, e.g. overflow: normal, that computes to visible, hidden or auto depending on the other axis. This way we could tell when developers have explicitly specified that the other axis is visible.

[css-meeting-bot]

The CSS Working Group just discussed [css-overflow-4] Allow scrollable overflow to be visible in the off-axis / overflow-clip-margin, and agreed to the following:

• RESOLVED: o-c-m restriction already resolved on continues to apply in this case

The full IRC log of that discussion

<TabAtkins> flackr: we resolved previously that you can create scrollable containers in one axis and not other
<TabAtkins> flackr: the immediate implicaction is you can have clip in the other axis
<TabAtkins> flackr: so q came up whether overflow-clip-margin should apply
<TabAtkins> flackr: and if so, and it can be arbitrarily large, should we support the use-case of not clipping in the non-scrollable axis? allowing visible?
<TabAtkins> flackr: dont' see reason to not do it, there's potential use cases
<TabAtkins> flackr: but wanted to get group agreement
<TabAtkins> flackr: with visible being initial value, we probably have to introduce new initial value that computes to visible
<TabAtkins> flackr: so we can tell the different between author specifying scroll in one axis, or scroll in one and visible in the other
<TabAtkins> flackr: so two proposals, one is less scary than the other
<TabAtkins> TabAtkins: is there any reason to not apply overflow-clip-margin?
<TabAtkins> fantasai: q is do we want to allow the content of a scroll container to be rendered outside?
<smfr> q+
<astearns> ack smfr
<TabAtkins> smfr: does the scrollbar show on top of the stuff that's not clipped?
<TabAtkins> flackr: that's a good question...
<TabAtkins> flackr: it probably should, a little weird
<TabAtkins> smfr: i'm also concerneda bou tthe computation of things that need to overlap the scroller
<TabAtkins> smfr: worried this makes it harder, it's already complicated
<TabAtkins> flackr: note i'm not opposed to saying we don't respect overflow-clip-margin
<TabAtkins> TabAtkins: I agree that *if* we allow o-c-m we should allow visible
<TabAtkins> dbaron: issue is there are dependencies lying around CSS that might cause problems
<TabAtkins> dbaron: if we were going to allow visible in one dimension, we probably want to be clear that this is still a block formatting context
<TabAtkins> TabAtkins: yeah I think there should be no difference between clip+infinite margin, and 'visible', in this case
<TabAtkins> fantasai: I think it could be cool but not worth the complexity in impl and testing
<TabAtkins> fantasai: if it was important we could do it
<vmpstr> q+
<TabAtkins> fantasai: but it's a lot of effort
<smfr> +1
<astearns> ack vmpstr
<TabAtkins> vmpstr: I don't disagree with Elika. We do then want to explicitly say that o-c-m doesn't apply if it's only clipping in one axis.
<TabAtkins> vmpstr: per spec right now it should
<TabAtkins> fantasai: yeah
<TabAtkins> astearns: if we decide it doens't apply, and later find a use-case, are we stuck?
<TabAtkins> TabAtkins: we'd be compat constrained, is all
<TabAtkins> flackr: we have another issue about showing visible content outside of the scroller, could support it as part of that if reasoanble
<astearns> ack fantasai
<TabAtkins> fantasai: so o-c-m can clip both in and out of the econtainer
<TabAtkins> fantasai: these mostly apply to clipping out of the container. we could honor clipping into the container
<TabAtkins> emilio: I think we did have a resolution for that more generally
<TabAtkins> flackr: ah if this is supposed to be something more general it should work here
<TabAtkins> flackr: so barring more comments, sounds like we're leaning toward not allowing this any more than it is for general scroll containers
<emilio> https://github.com//issues/7246
<TabAtkins> emilio: we might have just discussed it, not resolved...
<emilio> https://github.com//issues/10745
<TabAtkins> emilio: ah we did resolve in another issue
<TabAtkins> emilio: we resolved that o-c-m on scroll containers is clamped to the padding box
<emilio> > RESOLVED: scrollable boxes can combine content-box and a positive margin (clamped to padding box), and content-box and padding box can use negative margins. border-box ignores margin either way.
<TabAtkins> astearns: so should we say this is just covered by the previous resolution?
<TabAtkins> TabAtkins: I need to get that edit in
<TabAtkins> astearns: so proposed resolution is we actually apply the previous resolution to the espec
<TabAtkins> RESOLVED: o-c-m restriction already resolved on continues to apply in this case