[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?

[frivoal]

Sorry for missing the meeting. There are a few things that are missing in this resolution.

The resolution above isn't clear about this, but various comments during the discussion, as well as #1971 (comment) suggest that places that require something to be (non) visible, should be changed to require something to be (non) visible or clip. I think it depends on which case we're talking about:

1. The motivating use case for adding overflow:clip (recently, not the one for the original CSS2 design) was to be able to do contain: strict; text-overflow: ellipsis; or contain: strict; resize: both; and have it work. Both of these properties require overflow to be non-visible. This could be achieved by using overflow:hidden, but this has the unintended side effect of introducing (programmatic) scrollability, which may cause browsers to consume more resources than necessary (e.g. prerendering the overflowing areas, to be able to display them without delay should scroll happen).

   → I would be very unhappy if text-overflow and resize did not work with overflow:clip

2. The propagation of overflow to the viewport says that once you've set the value of the viewport (based on the value on :root or body), if it is visible, it gets changed to auto. I don't think that this should be changed to visible or clip get changed to auto, as this effectively means that overflow:clip on the root/body does nothing. If we do allow clip to stay clip on the viewport, should there still be scrollbars to "see" the invisible projected geometry? Hopefully not, but that looks like special casing.

Also, Along the way, we had discussed how the vast majority of overflow:hidden uses did not actually want programatic scrollability, and that teaching people to use overflow:clip instead would be nice, since it would have a (small but) positive effect on resource consumption (for the same reason as in 1.). The current resolution would require people to do overflow: clip; display: flow-root instead, which is a lot less easy to teach. Also, combining this with 1., even when used without contain, I would be unhappy if text-overflow and resize did not work with overflow:clip.

So, all in all, I am a bit skeptical of the above resolution: are people willing to implement overflow:clip as a paint time effect and at the same time allow text-overflow and resize to apply, and to implement the root element / viewport special casing (at least clip instead of compute to auto, preferably don't have scrollbars)?

If yes, I'm not super convinced by the resolution, but I suppose I can live with it.
If no, I'd like to see arguments why not, but I would probably object to the resolution.

[frivoal]

(agenda+ to follow up while it's reasonably fresh on everyone's mind)

[astearns]

Let's discuss this with a whiteboard in person.

[tabatkins]

Both of these properties require overflow to be non-visible.

Okay, so this is the "create a scroll container, but make it completely unscrollable" use-case that we couldn't come up with during the telcon. It's separate and distinct from the "no scroll container, but clipped" value that we want for other use-cases, and which is currently exposed by Moz as a prefixed value.

[tabatkins]

If we do allow clip to stay clip on the viewport, should there still be scrollbars to "see" the invisible projected geometry?

Yes, this is identical to visibility: hidden (just with the in-bounds parts actually visible!), as we mentioned a few times in the discussion.

[css-meeting-bot]

The Working Group just discussed overflow:clip, and agreed to the following resolutions:

• RESOLVED: text-overflow and resize apply to elements with 'overflow: clip' just as they apply to elements with 'overflow: hidden'
• RESOLVED: when overflow:clip is propagated to the viewport it's changes to overflow:hidden the same way visible is changed to auto

The full IRC log of that discussion

<dael> Topic: overflow:clip
<florian> https://github.com//issues/1971#issuecomment-377078084
<florian> github: https://github.com//issues/1971#issuecomment-377078084
<dael> florian: Missed the telecon where we discussed. We recently resolved overflow:clip does not trigger BFC. I think it failed to considered some of the things that implies.
<dael> florian: The motivation that triggered adding to spec was usage in combo with contain:paint so you can have contain:paint with text overflow or resize property. Only apply to overflow not visible elements. We don't want to use contain:paint with overflow:hidden because UA might look for too many resources.
<dael> florian: If overflow:clip does not creat a BFC are impl comfrotable saying resize and text overflow applies to elements that are overflow:clip?
<dael> TabAtkins: During discussion before we couldn't come up with you'd want overflow without scrolling, this is the reason. There are properties that depend on things being non-visible.
<dael> florian: Resize.
<dael> fantasai: I think it doesn't matter for resize.
<dael> florian: I'm not saying should not apply. but if we're going with it's not a BFC we also have a bunch of properties that should change to not visible or clip.
<dael> dbaron: There were use caes for the opposite.
<fantasai> and I think that 'text-overflow' should never have keyed off of 'overflow'
<dael> TabAtkins: This is the use case for this situation. WE only can up with use cases for the other resolution. Something tha tacts like overflow:visible but it's clipped.
<dael> florian: NOt effect margin collapsing.
<dael> TabAtkins: Or sticky or scrollsnap.
<dael> TabAtkins: This is a reason for the opposite where it's like hidden but don't scroll.
<dael> dbaron: They can't apply for text:overflow partly because this is a purely paint time effect.
<dael> florian: This is also a purely paint time.
<dael> fantasai: True.
<dael> dbaron: I guess those two could maybe be changed to not include the visible. Nothing is like this because we've put overflow does not equal visible across all our specs where that's not what we mean.
<dael> fantasai: I think a lot that key off overflow not visible key off if it's a BFC.
<dael> fantasai: I think a lot of things are keying off that. There's many effects that key off of that and we don't have to handle the spec. There may be sone that don't.
<dael> florian: That we need to rename was mentioned. If we clarify that doesn't apply to text-overflow and resize that solve my first concern.
<dael> florian: Are we okay closing that sub topic?
<dael> astearns: Additional concerns?
<dael> florian: Assuming we don't find another problem we can clarify the previous resolution to mean text-overflow and resize refer to non-visible elements.
<fantasai> fantasai: To rephrase Florian without negatives, text-overflow and resize apply to elements with 'overflow: clip' just as they apply to elements with 'overflow: hidden'
<dael> florian: The second concern was about what overflow:clip means when applied to the document or body element and propegate to viewport
<dael> fantasai: Same way we transpate visible to auto we translate clip to auto.
<dael> florian: That's good.
<dael> s/transpate/translate
<dael> astearns: Resolve on both?
<dael> astearns: Prop: text-overflow and resize apply to elements with 'overflow: clip' just as they apply to elements with 'overflow: hidden'
<dael> RESOLVED: text-overflow and resize apply to elements with 'overflow: clip' just as they apply to elements with 'overflow: hidden'
<dael> astearns: Prop 2: when overflow:clip is propagated to the viewport it's changes to overflow:hiddent he same way visible is changed to auto
<dael> RESOLVED: when overflow:clip is propagated to the viewport it's changes to overflow:hidden the same way visible is changed to auto
<dael> astearns: You're fine with the resolution?
<dael> florian: Yes. I'm mildly skeptical, but not objecting.

[Loirooriol]

csswg-drafts/css-overflow-3/Overview.bs

Lines 386 to 388 in c8425bc

	If the computed value of 'overflow' on a <a>block box</a>
	is neither ''overflow/visible'' nor ''overflow/clip'',
	it creates a new <a>block formatting context</a> for its content.

@frivoal This seems to imply that overflow: visible clip, which is neither overflow: visible nor overflow: clip, does establish a new formatting context.

[frivoal]

@Loirooriol Thanks. This is fixed now.