Re: [csswg-drafts] [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) (#3953)

> 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 https://github.com/w3c/csswg-drafts/issues/1971#issuecomment-370692229 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...
```html
<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. :(

-- 
GitHub Notification of comment by jonjohnjohnson
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/3953#issuecomment-494993905 using your GitHub account

Received on Wednesday, 22 May 2019 22:13:45 UTC