[css-overflow] Is the box a scroll container if only one of 'overflow-x' or 'overflow-y' is 'clip'?

[Loirooriol]

According to https://drafts.csswg.org/css-overflow-3/#ref-for-propdef-overflow%E2%91%A3,

• visible and clip prevent the box from being a scroll container.
• hidden, scroll and auto force the box into being a scroll container.

visible is not a problem because it computes to auto if one of overflow-x or overflow-y is not visible.

However, what happens if one of overflow-x or overflow-y is clip and the other is hidden, scroll or auto?

Is the box a scroll container or not?

Maybe a box could be a scroll container in one direction but not in the other one. Or maybe clip could compute to hidden similarly to visible.

[Loirooriol]

Firefox seems the only browser that supports clip, under the name -moz-hidden-unscrollable. Effectively it seems to compute to hidden if one of overflow-x or overflow-y is not -moz-hidden-unscrollable.

[fantasai]

Agenda+ to resolve on computing clip to hidden if the other side is neither visible nor clip.

[Loirooriol]

@fantasai With your wording I understand that overflow-x: visible; overflow-y: clip remains as specified. But on Firefox overflow-x: visible; overflow-y: -moz-hidden-unscrollable computes to overflow-x: auto; overflow-y: hidden. Is this deliberate? Consider

Computed value: as specified, except with visible/clip computing to auto/hidden (respectively) if overflow-x and overflow-y have different values.

[frivoal]

We'll see if the group agrees or not, but this is a deliberate proposal.

[Loirooriol]

OK! But then the spec says

If the computed value of overflow on a block box is not visible, it creates a new block formatting context for its content.

If the proposal is accepted it will mean that only one of overflow-x or overflow-y may be visible, so please clarify if the BFC is established only when both are not visible or if one of them suffices.

[dbaron]

FWIW, I think the intent of -moz-hidden-unscrollable was that it not create a BFC, and in general not have any layout differences from visible, only visual (painting) differences. (In other words, it was trying to do what CSS 2.0 described hidden as being, and I think was the implementation remaining after agreeing to standardize the spec-incompatible behavior of the other browser engines.) I can also see the value in a value that does create a BFC but doesn't allow programmatic scrolling (at least in its dimension, but could allow scrolling in the other dimension).

Might we want both of these values eventually? If so, do we really want to use the clip name for the latter one rather than the former?

[Loirooriol]

Since clip does not produce a scroll container, I don't think a BFC is necessary, so I wouldn't establish it. If someone wants it, they can use display: flow-root.

[frivoal]

We started discussing this by email a long time ago, and never concluded:
http://www.w3.org/mid/4314D40D-454E-48E3-99E0-3AB126308744@rivoal.net

I said:

overflow:clip is currently defined as the same as overflow:hidden, minus the scrolling abilities.
This implies that it establishes a BCF.

http://dev.w3.org/csswg/css-overflow/#valdef-overflow-clip

Mozilla implements -moz-hidden-unscrollable, which is similar to clip, except that it does not cause the element to establish a BFC.

Should we keep things as they are, or align with Mozilla?

As a reminder, overflow:clip was introduced to be what overflow:visible computes to when contain:paint is specified. We could have achieved the same pain containment effects without this value, but having overflow compute to something other than visible allows the properties that depend on overflow not being visible to be used with non-scrollable paint containment (e.g. text-overflow). Had we not had it, you'd have to use overflow:hidden if you wanted paint:containment and text-overflow, inducing the browser into allocating a larger buffer than needed to prepare for potential scrolling, even though you intend no scrolling.

As far as I know, the properties that depend on overflow not being visible are:

• text-overflow
• resize

If there is a need for the element to establish a BFC for these properties to work normally, then we should to keep the spec as it is. If not, I don't have a strong opinion.

Do they? Doesn't seem so to me, but I might be missing something.

@tabatkins replied:

If it doesn't establish a BFC, that means it can project invisible
geometry outside of itself, via a projecting float. That's
ridiculous. I'd love to hear the use-case behind
-moz-hidden-unscrollable.

I followed up with:

I'm curious too. What I gathered was that the goal was to avoid disturbing margin collapsing and have it fall out the same way it would with overflow:visible, not any particular interest in invisible floats peeking out. Not entirely sure what use cases this would matter for, though.

and as far as I know, we're still there.

---

PS: this mail thread was in my TODO list since 2015, albeit with a low priority 😱

[dbaron]

I think if clip (or a value with a different name) doesn't cause creation of a new BFC, all (or nearly all) of the properties that refer to overflow being visible should now refer to visible or clip.

[Loirooriol]

@dbaron I think "overflow is visible" should become "the box is not a scroll container".

[css-meeting-bot]

The Working Group just discussed https://github.com/w3c/csswg-drafts/issues/1971#issuecomment-370692229, and agreed to the following resolutions:

• RESOLVED: overflow:clip is a paint time only operation and we shouldn't require that an element with overflow as clip in either direction be a BFC nor a scroll port.

The full IRC log of that discussion

<dael> topic: https://github.com//issues/1971#issuecomment-370692229
<dael> github: https://github.com//issues/1971#issuecomment-370692229
<dael> Rossen_: florian sent regrets. can someone else take it?
<dael> fantasai: There's several issues here. Main one is that we wanted to figure out what various values of overflow compute to when you set...set x axis but not y.
<dael> fantasai: Before we introduced clip any value that's not visible in one axis causes the other axis compute to auto so you have a scroll container in both axes.
<dael> fantasai: Clip didn't spec how to compute. In general it was supposed to not trigger a scroll container.
<dael> fantasai: Combo of clip in one axis and visible in the other seems to be valid and should not cause visible to compute to auto
<fantasai> https://github.com/w3c/csswg-drafts/commit/1d1a8e9caf4333518620e32f2a8b08ec3efdfa13
<dael> fantasai: We updated computed value field. That's the first request. Current text says if one axis is not visible or clip then any axis that's visible or clip computes to atuo or hidden
<dael> fantasai: Changeset^
<dael> fantasai: That raised the question of but clip creates a BFC and visible doesn't, what happens when it's overflow:visible in one axis and clip in the other. That caused a sep discussion on if a BFC.
<dael> Rossen_: WE should take these one at a time. Thought they're related I think we can resolve independantly.
<dael> dbaron: Bigger issue is should clip create BFC and the other thing falls out.
<dael> Rossen_: Correct. fwiw I think we had this discussion in the past and every time we do a full circle and at the end we convince ourselves that not having it be a BFC becomes complex for implementation.
<dael> Rossen_: At least what I recall is are how floats that start before the element with a clip and extend past the clip region, how are they effected in terms of flow.
<dael> Rossen_: If clip is intended to be render time only effect...nevermind.
<dael> Rossen_: The interaction between floats that start before clipping elements or those on the side are hairy if overflow:clip is not BFC. If it is BFC it's predicatble but then you have overflowing visibly content to the lefft or right and because BFCs allow floats next to them you have overlapping content with floats.
<dbaron> I didn't actually follow that... and I actually don't remember having this discussion before.
<dael> Rossen_: Every time we have this discussion I recall us coming back to the BFC one makes the most sense if we have to impl.
<dael> Rossen_: I'm happy to discuss one more time if people think we can arrive at a different resolution.
<dael> TabAtkins: I think it's clear if there's a bfc creating context it's scroll. For clip it's just a matter of what hte intent of the value is. If as dbaron says clip is supposed to be like visible but without painting outside the bounds that's fine. Geometry will project out but it does what we're asking for here.
<dael> TabAtkins: If we want to restirct geometry clip is hidden with 0 ability to scroll. We have to decide.
<dael> fantasai: Or we make it effect alyout by truncating the float.
<dael> TabAtkins: That's a new concept that I'd prefer not to add.
<AmeliaBR> Floats affecting layout outside of the container but not painting outside the container sounds super confusing.
<dael> dbaron: The two things we described extend existing concepts and don't require huge changes. If we create one of those concepts we may decide to make the other in the future so we should name appropraitely.
<dael> TabAtkins: IN that case, on naming issue, perhaps we can plan for visible-clip and hidden-clip to suggest they're same as base...wait...doesn't make sense.
<dael> Rossen_: What was the motivation use case here?
<dael> TabAtkins: I presume dbaron can explain the visible unscrollable
<dael> dbaron: It's what css2.0 spec. The hidden creating a scroll container and bfc was new to 2.1. It's what the WG rec recommended for a decade.
<dael> Rossen_: and you're only impl?
<dael> dbaron: I think so. Other impl did hidden in terms of scrolling.
<dael> Rossen_: If this is back compat with not compat reature should we decide?
<dael> dbaron: I don't think that's why it was added to spec.
<dael> Rossen_: Was it used anywhere?
<dael> dbaron: Internally. not externally.
<dael> fantasai: I think idea was to not have some of the hidden side effects like a scroll container.
<dael> fantasai: Has a bit more effect on stuff now then in the past. In the past it meant you have slightly different perf considerations. Sometimes certain user events can scroll a hidden thing. Currently if you turn something into a scroll container it catches things like scroll snap
<dael> Rossen_: This is a large topic. I think this is perfect for whiteboard between sessions thing and convince ourselves one way or another. And then hopefully we have florian. Should we table?
<dael> TabAtkins: I'm fine right now resolving clip is the visible but doesn't paint outside the bounds thing. I can see use cases for it as fantasai describes. Doesn't disturb margin or capture scroll snaps.
<dael> Rossen_: Margin collapsing and everything else?
<dael> TabAtkins: Same as visibility.
<dael> Rossen_: Visibility:hidden takes layout space.
<dael> TabAtkins: This will too
<dael> Rossen_: No, it says you stop at the bounds of your container. Which means if you have a whole bunch of floats or 0 height divs with negative margins that effect after clip but they're overflowing, do you take that into account?
<dael> TabAtkins: I'm not willing to spec something that clips geometry. I'd be happy with the it's like visible buy clips paining
<dael> Rossen_: If you don't have floats and a div with overflow-clip:veritical and a bunc hof text with at the end a div with a huge negative bottom margin. It overflows.
<dael> Rossen_: After the clip the div isn't visible nor is the content. Is the negative margin in effect?
<dael> TabAtkins: Full geometry. Exactly like visibility:hidden but you extend the geometry
<dael> dbaron: I'm not sure visibility:hidden is greatest analogy, but it's purely a paint time effect. Layout is the same as overflow:visible but descendors outside bounds are clipped
<dael> frremy: We haave requests for overflow:hidden but have position sticky work and I think this fixes that.
<dael> TabAtkins: That's good. Another thing scroll containers block. Nice use case.
<dael> TabAtkins: I'm seeing good reasoning for a purely paint time clipping. You'll have weird looking stuff sometimes, but that's going to be rare. If you don't want that use overflow:hidden
<dael> Rossen_: And we shouldn't ask people to do that with clip or clip path? How many other ways do we have for clipping?
<dael> Rossen_: This was the intent of css clip in 2.1
<dael> TabAtkins: Good point.
<dael> dbaron: Clip in 2.1 was only for abspos. We can't change that due to compat.
<dael> Rossen_: I don't think we can undo the things in the past. What we can do is narrow down this issue and see if we can get consensus
<dael> Rossen_: Sounds like most people feel like overflow:cip is a paint time only operation and we shouldn't require that a element with overflow as clip in either direction be a BFC. The note in the spec would be yes geometry and everything else works as it does before and if geometry overflow it will have side effects.
<fantasai> +1
<dael> Rossen_: Would people object to this as a resolution?
<dael> RESOLVED: overflow:clip is a paint time only operation and we shouldn't require that an element with overflow as clip in either direction be a BFC nor a scroll port.
<TabAtkins> Yeah, not seeing why we shouldn't just use clip-path here. Need to recall what the syntax is of just clipping to border box.
<dael> Rossen_: Now if overflow computes to clip in one direction or visible in the other. If we have overflow...I'm confused if we need a resolution. If you have overflow auto or scroll in one direction the other is hidden by default. If you have clip in one direction the other is visible.
<dael> TabAtkins: We need a resolution because we have termonoloy that talks about this.
<dael> Rossen_: What would you want to call this?
<dael> TabAtkins: Dunno
<dael> fantasai: I'm confused that we need. If we have the reoslution we need to resolve on the changes in the issue.
<dael> TabAtkins: We have various specs that have behavior when overflow is non-visible, but it means when it causes a scroll container. So clip now falls into visible so we need specs to refer to a term.
<dael> Rossen_: Can we replace to overflow computes to scrollable or non-scrollable?
<dael> fantasai: It's editorial. We don't need a resolution.
<dael> TabAtkins: Yeah. But we need to do it.
<dael> Rossen_: No more resolutions needed and we can move on?