CSS overflow: clip and overflow-clip-margin

[sky2]

HIQaH! QaH! TAG!

I'm requesting a TAG review of CSS overflow: clip and overflow-clip-margin

[One paragraph summary of idea, ideally copy-pasted from Explainer introduction]

Adds two CSS features. The 'clip' value results in a box’s content being clipped to the box's overflow clip edge. In addition, no scrolling interface is provided, and the content can not be scrolled by the user or programmatically. The overflow-clip-margin property enables specifying how far outside the bounds an element is allowed to paint before being clipped.

• Explainer¹: None

• Specification URL: https://drafts.csswg.org/css-overflow-3/#valdef-overflow-clip and https://drafts.csswg.org/css-overflow-3/#propdef-overflow-clip-margin .

• Tests:
  css/css-overflow/clip-001.html
  css/css-overflow/dynamic-visible-to-clip-001.html
  css/css-overflow/overflow-body-propagation-007.html
  css/css-overflow/overflow-body-propagation-008.html
  css/css-overflow/overflow-body-propagation-009.html
  css/css-overflow/overflow-clip-*
  css/css-overflow/overflow-clip-margin*
  css/css-overflow/overflow-clip-scroll-size.html

• Security and Privacy self-review²: Not aware of any security or privacy implications

• GitHub repo (if you prefer feedback filed there): None

• Primary contacts (and their relationship to the specification):

  • [email protected]

• Organization(s)/project(s) driving the specification: CSSWG

• Key pieces of existing multi-stakeholder review or discussion of this specification: Continued evolution of overflow.

• External status/issue trackers for this specification (publicly visible, e.g. Chrome Status): https://www.chromestatus.com/feature/5638444178997248

Further details:

• I have reviewed the TAG's API Design Principles
• Relevant time constraints or deadlines: Would love to enable this now (89) in chrome.
• The group where the work on this specification is currently being done: CSSWG
• Major unresolved issues with or opposition to this specification: none
• This work is being funded by: Google

You should also know that...

[please tell us anything you think is relevant to this review]

We'd prefer the TAG provide feedback as (please delete all but the desired option):

🐛 open issues in our GitHub repo for each point of feedback

☂️ open a single issue in our GitHub repo for the entire review

💬 leave review feedback as a comment in this issue and @-notify [github usernames]

[LeaVerou]

@hober and I tried to review this in our VF2F breakout today, but realized there is no explainer, and no list of use cases this is trying to address, without which review is rather difficult. Could you please add an explainer minimally containing a list of user needs and example code these are trying to address?

[sky2]

Here's an explainer.

Prior to this work, it was not possible to have an element hide overflow and prevent scrolling of any kind (programmatic or user). The ‘clip’ value of ‘overflow’ adds this functionality. That is, the content is clipped to the element's padding box and scrolling of any kind is not allowed. The element is not a scroll container, and does not start a new formatting context. If you wish to start a new formatting context, you can use display: flow-root to do so.

For some uses, it is desirable to modify the clipping edge. For example, the shadow of a child element should still be visible. The ‘overflow-clip-margin’ property determines precisely how far outside the element's bounds the element is allowed to paint before being clipped. ‘Overflow-clip-margin’ may be used with ‘overflow: clip’ as well as ‘contain: paint.’

The following illustrates using ‘overflow-clip-margin’ with ‘contain: paint.’ For browsers that support overflow-clip-margin the box-shadow will be visible.

#container {
width: 100px;
height: 100px;
contain: paint;
overflow-clip-margin: 10px;
}
#child {
width: 100px;
height: 100px;
box-shadow: 8px 8px blue;
border: 1px solid;
}
</style>

[plinss]

Looked at this today with @hober and have two points of feedback:

1. It seems odd to constrain the overflow-clip-margin to the overflow: clip case. Wouldn't an additional margin also make sense in the overflow: hidden state?

2. Adding another high-level feature that has the same behavior as another high-level feature with the exception of a low-level detail seems like an anti-pattern that CSS is guilty of in multiple places. Examples are other properties that cause the generation of stacking contexts or containing blocks, and are often used just for those side-effects (e.g. position: relative with no offsets). Many of these cases would be better served by a direct control of the lower-level feature, e.g. "make this a stacking context", or "make this a containing block". We're wondering if it doesn't make more sense to have an individual control of whether something is a scroll container and use that feature in conjunction with overflow: hidden to get the overflow: clip behavior.

[sky2]

On Mon, Feb 15, 2021 at 4:33 PM Peter Linss ***@***.***> wrote: Looked at this today with @hober <https://github.com/hober> and have two points of feedback: 1. It seems odd to constrain the overflow-clip-margin to the overflow: clip case. Wouldn't an additional margin also make sense in the overflow: hidden state?

As the "overflow: hidden" case is still scrollable (programatically), I don't think it makes sense to support the overflow-clip-margin there.

1. 2. Adding another high-level feature that has the same behavior as another high-level feature with the exception of a low-level detail seems like an anti-pattern that CSS is guilty of in multiple places. Examples are other properties that cause the generation of stacking contexts or containing blocks, and are often used just for those side-effects (e.g. position: relative with no offsets). Many of these cases would be better served by a direct control of the lower-level feature, e.g. "make this a stacking context", or "make this a containing block". We're wondering if it doesn't make more sense to have an individual control of whether something is a scroll container and use that feature in conjunction with overflow: hidden to get the overflow: clip behavior.

If we were to introduce another property, then we would end up contradicting configurations. For example, 'overflow: scroll;' and 'scrollable: false' ? -Scott

…

1. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#579 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACHE7YRVEQSG7V5BO5NH553S7G4OZANCNFSM4ULE44UA> .

[hober]

Hi,

@atanassov and I took a look at this today in a TAG breakout.

Looked at this today with @hober and have two points of feedback:

1. It seems odd to constrain the overflow-clip-margin to the overflow: clip case. Wouldn't an additional margin also make sense in the overflow: hidden state?

As the "overflow: hidden" case is still scrollable (programatically), I don't think it makes sense to support the overflow-clip-margin there.

I'm afraid I don't follow. Currently, there are two differences between overflow: hidden and overflow: clip:

1. overflow: hidden content is programmatically scrollable, whereas overflow: clip content is not
2. overflow: clip content is clipped to the overflow clip edge whereas overflow: hidden content is clipped to the padding box.

But what if you want content that is programmatically scrollable but clipped to the overflow clip edge? It seems like you have to choose between your content looking like you want but not behaving like you want (overflow: clip), or your content acting like you want but not looking like you want (overflow: hidden).

In the degenerate case of overflow-clip-margin: 0;, the overflow clip edge just is the padding box, so I doubt there would be much of a compat hit if we made overflow: hidden clip to the overflow clip edge.

There are also use cases for overflow-clip-margin for other values of overflow, such as overflow: visible. Suppose you wanted to slowly reveal more lines of text in a box. If overflow-clip-margin affected overflow: visible boxes, you could simply animate its value from -somenumber to 0 to reveal the rest of the text without causing weird layout things to happen and without having to create an extraneous opaque element to put on top of the text (& animate a translate transform of).

[torgo]

Hi @sky2 we're just picking this up and I notice there hasn't been any feedback. We'll punt it to our next session in 2 weeks time. Looking forward to your thoughts.

[sky2]

There is no technical reason why overflow-clip-margin couldn't be applied to hidden as well. We would need the constraint that 'hidden' is set along both axis.

As to applying overflow-clip-margin to 'overflow: visible' as well. That seems confusing, given the 'visible' implies no clipping.

[atanassov]

@hober and I looked at this issue during our Gethen virtual f2f and the following is a summary of our discussion.

1. There is an existing clipping mechanism in CSS provided through the clip property. This is not ideal since it only applies to absolutely positioned elements, but it exists.
2. This proposal could be a good generalization of clipping since it could apply to most other elements and it provides better control through properties such as overflow-clip-margin.

The problems we see with the approach are:

1. By introducing overflow:clip we are essentially adding a second mechanism for clipping to the platform
2. There is no clear expectation if overflow-clip-margin can or should apply to clip
3. The overflow:clip value makes clipping of scrollers impossible, a capability that is possible with clip property.

All in all, we don't see a clear path of convergence between the clip property and new clip value of overflow. We also don't see how one can become a superset of the other even if the goal was to overtake and deprecate clip property.

At this point we are closing the issue until the above could be satisfied. Thank you for working for us. Happy to review another proposal when ready.