Peter: why wouldn't you also want the overflow-clip-margin to work in overflow: hidden? Maybe it doesn't make sense for scroll or auto, but it does seem useful in hidden as well as clip.

Peter: The only difference between hidden and clip is that one causes a scroll container. Two high-level knobs that switch a low-level value which isn't exposed. We should expose the low-level knob "turn this thing into a scoll container". Or "look, just make me a stacking context" or "just make me a containing block."

Peter to write up a comment on this issue.

We talked a bunch (and failed to minute) about why overflow-clip-margin doesn't apply to overflow:hidden or even overflow:visible. Tess captured the conversation in a comment on the issue.

Rossen: [CSS thing and chromium implementation]

Dan: notes "positive" signals in the Chromnestatus page from Safari. - good for multistakeholder.

Rossen: between Tess & I we spoke about it - how it would apply to different kinds of overflow... whether it's programmatic or through UA - eg panning. Main question - 2 types of overflow. Overflow that is scrollable or manipulatiable - and one that isn't. overflowVisible creates overflow but it's not scrollable. overflowClip if applied to visible will constrain the bounds but doesn't change the bounds. We gave reasoning why the proposal seems a bit confusing and more explanation is needed. Response has not addressed the issue - followup discussion is needed. Explainer in-lined into the comments - i don't appreciate the corner cutting. One of the main reasons for the explainer is to satisfy the criteria - use cases - how the feature addresses the use cases - what other other methods were considered to satisfy? Is this the best way to go... Plus security & Privacy... They are talking about experimentation... The chromestatus page only talks about overflow-clip.

Peter: the issue is about both.

[mozilla shipped clip but ...]

Rossen: don't see anything about margin from reading the Mozilla intent-to-ship. Somewhat misleading on Chromestatus.

Rossen: more discussion warrented. I don't think overflow clip margin is shipped.

Peter: i have concerns about clip. One of those things where we have multiple ways of doing something in CSS. This whole thing feels bolted on the side instead of fitting in well with CSS.

Rossen: what's a better approach?

Dan: because they don't provide the user needs, can you tell me what this is used in?

Peter: anything that has a specified or constrained size that is smaller than what it would need to fit its content can potentially overflow

Dan: right, so something might overflow the bounds of an iframe?

Peter: not an iframe, but a paragraph with a really long word. Something is going to have to give. The question is how doe sit give? overflow:visible you draw the contents extend outside the box. Auto or scroll you add scrollbars and don'td raw the outside but allow the user to scroll. Hidden you don't draw the outside, dont add a scroll but you could programatically still scroll it. The author can add some other mechanism to display it. This, if I'm reading correctly, you don't draw the overflow, no mechanism to scroll it whatseover, the margin basically says go ahead and draw some extra, eg. by 20px worth of the overflow but no more than that. Lets you expand the clipping region.

... One of my questions was why should the margin only apply to clip, why not over-flow hidden? Main concern was that when you overflow there's a side effect. Scroll or auto, and start scrolling, auto you only scroll if you have to, scroll you always have a scrolling mechanism. Side effect is when you get a scrolling mechanism you get a stacking contet. Everything in the box is an atomic unit for rendering. Eg. with z ordering things things can't be in the middle. It isolates that whole thing into its own rendering area. One purpose is to control overflow without generating a stacking context.

Rossen: which is not great

Peter: I think that's why you can't scroll programatically because if you don't have a stacking context you can't do all of the math, it's too complicated

Dan: where the need for the explainer would come in is talking about that, and also the use cases that make this important. Obviously it's being driven by some user need - who is it and what is the need? That justifies the added complexity and the difference between this and the case where its scrollable but only programatically

Peter: CSS has made this msitake in several places - switching some property has a main effect and a side effect, like creating a stacking context or becoming a containing block. We wind up with people doing things like making something position relative then not offsetting it, becuase it has the side effect of creating a stacking context. You want to force the thing to be a stacking context or containing block. My desire has been that these side effects should just have their own switches. If I want to force something to be a containing block or a stacking context I should be able to say containing-block: always, and not have to trick the engine into that state. I think this is one of those things where we're adding a property that people are going to use for its side effects more than its effect and we should just enable direct control over the side effect that people want.

Rossen: I think you need to give your comment more gravity and then continue the conversation

Peter: I said what I meant.. he responded with 'why not a scrollable context'.. which is not what i was saying. I'll respond.

Rossen: will leave feedback about explainer

Peter: One of my problems with this feature is that we're adding yet another clipping mechanism to the existing clip property.

Rossen: Current spec defines overflow:clip as a strict superset of clip. It also allows better integration with non-scrollable content. In the ideal case that property will overtake clip entirely and we can deprecate it.

Peter: Yes and then again, clip exists today despite its (lack of) usefulness. It seems weird to have both a clip property and a seperate overflow-clip-margin. What if overflow: clip opts in to using the clip property to define the box? Alternatively, if this is meant to fully replace clip, then that should be stated.

Rossen: So how can we resolve this from TAG POV?

Peter: The behavior makes sense but the resolutoin is certainly not satisfying. It almost feels we need another resolution type to ask for a feature to go back for additional design considerations.

... Let's discuss more at the plenary with the rest of the group.

Rossen and Peter had a breakout about this some time ago in which they convinved themselves that this isn't a great approach. Rossen closed with a comment that captures their thinking.