[css-overflow-3][css-overflow-4][css-box-3] A switch for bottom/right (end) overflow to not be scrollable contribution, like top/left (start)

[jonjohnjohnson]

https://drafts.csswg.org/css-overflow-3/
https://drafts.csswg.org/css-overflow-4/

I know historically we have the whole from top/left nature of the web that makes things like transforms, abspos, and negative margins across bottom/right edges create scrollable overflow, but doesn't when crossing top/left edges. This definitely makes sense being the default in many situations, but I have had to hack my way around bottom/right edges enough times to wish there was a switch that made all edges "trim" like top/left, regardless of used overflow or clip-path values.

With issues like #3068, #129, #3653, & #3665 being ironed out, I wonder if an overflow-trim property, akin to margin-trim could be a switch from auto to trim that allows bottom/right, logical end, directions to behave the same as top/left, logical start, directions, where descendent geometry could cross those boundaries and not contribute to the nearest scrollable ancestors overflow?

[fantasai]

You mean like overflow: clip?

[jonjohnjohnson]

You mean like overflow: clip?

No, hence mentioning

regardless of used overflow or clip-path values.

I think what you're suggesting is use of some extra non-semantic wrapper inside the scroll container? Instead of something, on a scroll container, that can just make bottom edge crossing geometry, like a margin-bottom:-100px, not adding scrollable overflow, as a margin-top:-100px obviously can't add top scrollable overflow when crossing the top edge.

I can't use overflow:clip and have a scroll container, let alone any scrollable overflow. Separately, it seems like computing overflow:clip to overflow:hidden on html stunts possible paint optimizations?

<scrollport>
  <content>tall overflowing content</content>
  <block style="height: 50px; margin-bottom: -50px;">attempts to negate scrollable overflow</block>
</scrollport>

Shows a block attempting, but failing to negate overflow, unlike if crossing top edge.

[fantasai]

OK, so you want the contents that overflow the box to still scroll, but content that overflows what would have been the content-box edge if the box were auto-sized to be clipped. Yes?

Can you give some examples of where this is needed?

[jonjohnjohnson]

OK, so you want the contents that overflow the box to still scroll, but content that overflows what would have been the content-box edge if the box were auto-sized to be clipped.

Yep

In the changes following #1971 (comment) we have overflow as...

Computed value: As specified, except with visible/clip computing to auto/hidden (respectively) if one of overflow-x or overflow-y is neither visible nor clip

So...

<scrollport style="overflow-x: clip; overflow-y: scroll;">
  <sliding-side-menu style="transform: translateX(100%)"></sliding-side-menu>
  <content></content>
</scrollport>

Still creates scrollable overflow and things like tab keys can break the hidden overflow.

And this morning was caught off guard when attempting to use the benefits of negative margins in a sticky position scheme...

Open in firefox, using overflow:clip -> https://jsfiddle.net/7ywxn1fr/

Scroll the light grey box up and down, between boundaries see the top blue bar sits at top edge, but the bottom blue bar doesn't sit at the bottom edge. Because of negative margin still creates scrollable overflow. Sure overflow:clip (-moz-hidden-unscrollable) can partially fix the layout. Click to focus in the "lorem ipsum" area, which in the demo matches a pseudo class to wrap content in overflow: clip and then scroll, seeing layout geometry behave as expected. But this *fix renders the translucent layering effects of the blue bars futile, with the content visually not being able to show outside its edges or underneath the blue bars. :(

It's true this can be remedied by always adding an extra wrapper around all the scrollable content inside the scroll container with overflow:clip, but semantics as well as proposals like #2406 from @Loirooriol will be harder to push through the longer we wait.

[fantasai]

OK, so the first case would be solved if we made clip disable scrolling in that axis in the cases where it otherwise behaves like hidden, yeah?

As for the second, I'm having trouble following what you're trying to do. Maybe a simplified testcase would help?

[jonjohnjohnson]

OK, so the first case would be solved if we made clip disable scrolling in that axis in the cases where it otherwise behaves like hidden, yeah?

Yep, this would solve for how currently the spec would require a non-semantic clip wrapper around content inside the scroll container.

As for the second, I'm having trouble following what you're trying to do. Maybe a simplified testcase would help?

Negative margins allow for some interesting scroll effects with position sticky, but though a negative bottom margin may create a shorter content box for the immediate sticky elements parent, it does not pass that "shorter content edge" up to the scroll container, with the scroll container expanding its scrollable overflow to contain the sticky element. So...

<scrollport>
  <box>
    <content></content>
    <sticky style="margin-bottom: -100px"></sticky>
  </box>
</scrollport>

In this example, the <box> would be made 100px shorter than the sticky elements bottom edge, though of course the scrollports scrollHeight would not be cut short the 100px, unlike what rightly happens in the top/left edge of a scroll container.

It might be simply put as a way to contain scrollable overflow to the size of immediate descendant(s) flow? This would match top/left?

I also wonder what this means for scrollable overflow regarding alignment/logical specs for scroll content aligning/starting on the bottom/right flowing upward/leftward?

And again, won't overflow:clip computing to overflow:hidden on the root scroller keep from paint optimizations, especially for things like a menu transformed way up out of view inside a root that is intended to absolutely never have scrollable overflow or scroll?

[fantasai]

@jonjohnjohnson So... why do you have a negative margin here in the first place? Like I have no idea what you're trying to do here or why.

[jonjohnjohnson]

@fantasai Sorry, I do realize the test case is far from concise, and moreso my explanation. I'm using negative margins because of their usefulness within the sticky positioning scheme (see #2496), to make "bookends" that cover the main scrolling content at the beginning and end of the scroll container.

But sometimes the bookends and scrollHeight are both small enough that scrollable contribution breaks the layout when using overflow:visible, which is desired for showing the content behind semitransparent bookends. To remedy the scrollable contribution, I could use overflow:clip but then it inhibits the ability to show the main content behind the semitransparent bookends. I think that's as simple as I can explain it right now. :)

In other news, I'll close this in confidence that #8361 gets us a solution which won't require overflow:clip and then be able to set some other property on that overflowing element or its descendants.