[css-overflow-3] What clips scrollable overflow?

[fantasai]

See testcase:

So far the following results:

• overflow: clip (and contain: paint) clip scrollable overflow
• clip-path does not clip scrollable overflow in FF, WK, or Blink
  • Side note: Blink doesn't seem to support the full syntax of clip-path, e.g. border-box doesn't work >:/
• clip does not have interop on this point

Is this the behavior we want?

[smfr]

clip-path is like a mask or filter, which does not affect layout overflow. clip is just weird and I don't really care :)

[bfgeek]

I believe we represent clip and clip-path as the same concept internally - so I'd prefer if they were kept consistent.

[css-meeting-bot]

The CSS Working Group just discussed [css-overflow-3] What clips scrollable overflow?, and agreed to the following:

• RESOLVED: Explicitly define that overflow:clip does clip scrollable overflow
• RESOLVED: clip and clip-path do not clip scrollable overflow

The full IRC log of that discussion

<dael> fantasai: We are trying to figure out how we're defining scrollable overflow. clip-ath seems to not clip scrollable overflow. clip has no interop. What behavior do we want ehre
<dael> fantasai: smfr said clip-ath should be like a mask. iank_ suggested clip and clip-path should behave the same
<dael> florian: So this is not visually clipping, but clipping the effect on scrollability
<dael> iank_: Yes. And I somewhat agree with smfr as well
<dael> fantasai: Prop: Overflow-clip clips scrollable overflow. clip-path and clip do not clip scrollable overflow; they just clip painting
<dael> astearns: A bit of a concern that if we define clip to have this behavior it may not actually come to be. I don't think browser impl won't be all that concerned about interop on clip
<dael> iank_: webkit and blink are consistent with clip. I think Gecko is only odd one out
<dael> astearns: Other comments?
<dael> astearns: There were results in test case. What does spec say?
<dael> fantasai: I think it's not defined for clip path
<dael> florian: overflow:clip not an objection but feeling a bit odd. If I'm not misremebering in terms of floats poking out overflow:clip lets them do that. So overflow:clip does clip geometry for scrollable and not for floats. Maybe a bit weird but I guess okay
<dael> astearns: Sounds like a candidate for a test case
<dael> astearns: Is it the case that overflow:clip is specced to say it clips scrollable overflow?
<dael> astearns: Do we need two resolutions, one for overflow:clip and one for clip and clip path? Or is overflow:clip handled?
<dael> florian: In the spec overflow:clip is spec to say UI is not supposed to provide scrolling interface. At time written probably meant for element, not its parents. Maybe needs clarifications
<chrishtr> q+
<dael> astearns: Prop 1: Explicitly define that overflow:clip does clip scrollable overflow
<dael> astearns: According to test case we're speccing reality
<dael> chrishtr: In all browsers, right?
<dael> iank_: Correct
<dael> astearns: Objections?
<chrishtr> sgtm
<dael> RESOLVED: Explicitly define that overflow:clip does clip scrollable overflow
<astearns> ack chrishtr
<dael> chrishtr: According to issue css-clip does not have interop
<dael> iank_: Webkit and Blink are the same. only Gecko clips scrolable overflow
<dael> chrishtr: On WK and Blink neither clip nor clip-path effects scrollable overflow
<dael> iank_: Right. But only clip in Gecko
<dael> chrishtr: Prop is match WK and Blink?
<dael> iank_: Yes
<dael> chrishtr: Makes sense
<dael> dholbert: Makes sense to me too. Digging into code to understand why they're different but not sure. Seems reasonable
<dael> iank_: Clip is such an old property I wouldn't be surprised if it's old behavior
<dael> astearns: Other comments?
<dael> astearns: Prop: We specify that clip and clip-path do not clip scrollable overflow
<dael> chrishtr: What about masking? Has anyone checked that?
<dael> astearns: I'm guessing we have not
<dael> chrishtr: Pretty sure it does the same as clip-path in blink. I think we should align them all together
<dael> astearns: Makes sense to me
<dael> dholbert: Might be good to do testing o nthat before we resolve
<dael> astearns: Let's resolve on clip and clip-path for now and then let's take a look at masking. Let's have that be a separate issue.
<dael> chrishtr: Okay
<dael> astearns: Prop: clip and clip-path do not clip scrollable overflow
<dael> astearns: Obj?
<dael> RESOLVED: clip and clip-path do not clip scrollable overflow
<dael> ACTION chrishtr check out if masking has the same issue as clip and open an issue if necessary
<dael> iank_: I'd be surprised if it doesn't behave correctly
<dael> astearns: But the spec may need words

[frivoal]

I think we have a little less interop than we thought with overflow: clip.

TL;DR: The problematic case is when a float overflows in the block axis.

Here's a test case It has a float, inside of a box with overflow: clip, itself followed by a box with clear: both, all of that inside of a box with overflow: auto. Then that's repeated, but without the box with clearance.

First, in Safari, the test doesn't work, because it seems that overflow: clip stops having any effect at all (!) if a float overflows in the block axis. It would take effect in the inline axis if there was no block overflow, or if any block axis overflow was caused by something other than a float, like an abspos. Hard to think that's anything but a bug, but that bug could be a sign of "it's harder than we thought". testcase for that

Back to the main test case.

In Chrome and Firefox (and Safari if you modify the test case to remove block overflow), overflow: clip does suppress the inline axis scrolling potentially caused by a protruding float. This is what the opening comment tested for and claimed interop about.

However, things get more "interesting" in the block axis:

• As stated above, overflow: clip stops working altogether in Safari when a float overflows in the block axis
• In both Chrome and Firefox, there is interop about the spec requirement that an overflow: clip element does not establish a BFC, and therefore the box with clearance is pushed down by the invisible geometry of the clipped float. Therefore we do get vertical scrolling (triggered by the box with clearance).
• However, if we remove the box with clearance, we get a difference:
  • In Chrome, just like in the inline axis, the invisible geometry of the clipped float does not trigger scroll overflow in the block axis, so we do not get a vertical scrollbar.
  • In Firefox, the invisible geometry of the clipped float does trigger scroll overflow in the block axis, so we do get a vertical scrollbar.

If we try to have something other than a float cause the overflow, for instance with an abspos, then we do have interop in all 3 browsers that the clipped content does not trigger scroll overflow in either axis.

---

In conclusion, what the spec currently says is that overflow:clip visually clips the content without providing scrollbars (nor programatic scrolling) on the clipping element itself. I believe we do have interop on that.

But the spec is less clear on whether the protruding geometry can cause scrollbars on ancestor elements, and we do not have full interop on that. We seem closer to agreement on not scrolling than the other way around, but we're not fully there: when a float overflows in the block axis, we get 3 possible behaviors: clear and scroll, clear but don't scroll, or give up.

Question to the group (and particularly to Safari and Firefox): do you consider that a bug that you intend to fix, and we can therefore stick with the resolution, or does that cause a need to rethink?

[dholbert]

I think we have a little less interop than we thought with overflow: clip.
[...]
Question to the group (and particularly to Safari and Firefox): do you consider that a bug that you intend to fix, and we can therefore stick with the resolution, or does that cause a need to rethink?

I think the Firefox behavior there is probably a bug -- at least, we change to match Chromium if I apply @dshin-moz's patch for bug 1768921 (which is aiming to implement the spec update from #129 and align with Chromium's behavior on that).

(That patch has been stuck in my review queue, but I anticipate finishing the review soon. When it lands, Firefox & Chromium will be consistent on this part at least.)

So: no concerns from me on sticking with the resolution at this point.

[smfr]

I filed https://bugs.webkit.org/show_bug.cgi?id=256410 on the Safari issue with floats.