W3C home > Mailing lists > Public > public-css-archive@w3.org > May 2019

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

From: jonjohnjohnson via GitHub <sysbot+gh@w3.org>
Date: Wed, 22 May 2019 13:42:41 +0000
To: public-css-archive@w3.org
Message-ID: <issues.opened-447144884-1558532560-sysbot+gh@w3.org>
jonjohnjohnson has just created a new issue for https://github.com/w3c/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) ==
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 https://github.com/w3c/csswg-drafts/issues/3068, https://github.com/w3c/csswg-drafts/issues/129, https://github.com/w3c/csswg-drafts/issues/3653, & https://github.com/w3c/csswg-drafts/issues/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 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?

Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/3953 using your GitHub account
Received on Wednesday, 22 May 2019 13:42:44 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 5 July 2022 06:41:48 UTC