- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Thu, 07 May 2020 21:35:43 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-align-3] What is supposed to happen to abspos in an end-aligned scroll container? #4957`. <details><summary>The full IRC log of that discussion</summary> <dael> Topic: [css-align-3] What is supposed to happen to abspos in an end-aligned scroll container? #4957<br> <fantasai> github: https://github.com/w3c/csswg-drafts/issues/4957<br> <dael> github: https://github.com/w3c/csswg-drafts/issues/4957<br> <dael> TabAtkins: While fantasai and I doing position re-write we found incompat<br> <dael> TabAtkins: 2 ways to resolve<br> <dael> TabAtkins: When you do align-content: end it aligns end of content box with end of container box. If container is scrollable don't want to do that. Instead adjust scroll position for same visual effect.<br> <dael> TabAtkins: If you flip overflow from auto to visible you should have content looking the same.<br> <fantasai> https://www.w3.org/TR/2020/WD-css-align-3-20200421/#overflow-scroll-position<br> <fantasai> whiteboard: https://www.w3.org/TR/2020/WD-css-align-3-20200421/images/scroll-align-padding.jpg<br> <dael> TabAtkins: However abspos position themselves in a way that doens't work well. If you say top:0 it's positioned against top edge of scrollable area. If you set align:content end to start at bottom of scroll abspos is out of view. If you turn overflow back to visible abspos is now attached to top and in view.<br> <fantasai> ^ is what happens with in-flow content<br> <dael> TabAtkins: Two ways to deal.<br> <fantasai> Now we're talking about interaction with abspos<br> <dael> TabAtkins: 1) say that's fine and overflow is slightly different positioning model. I think I prefer this<br> <dael> TabAtkins: 2) We do adjust how abspos is positioned when it's non-start so abspos containing block is moved in the scroll container to allow to sit in same spot<br> <dael> TabAtkins: Requires some ffixup but not too complicated. Another thing in there. Not sure authors expect. When they say abspos they expect top<br> <dael> Rossen_: Inner border box edge?<br> <dael> TabAtkins: Scollable area edge when scrollable.<br> <dael> Rossen_: top and left logical establish origin and you don't go past htat<br> <dael> TabAtkins: Yes<br> <dael> fantasai: One key point is the origin of the scrollable overflow area is not nec the initial scroll position. Initial scroll position can depend on alignment. Sep. concepts<br> <dael> Rossen_: I'm unclear in your def when they expect it to be aligned to top important to define what top means. If we allow abspos elements to redefine scrollable area as they extend past hte origin in the negative before the start than your statement is circular<br> <dael> TabAtkins: We're saying the opposite<br> <myles> q+<br> <dbaron> I think I understand the question here, and I don't yet have an opinion on which behavior seems better -- and given that I think it's preferable to go with the simpler one as Tab suggested. But it's possible thinking about it more would make me have a different intuition for what "should" happen.<br> <dael> TabAtkins: In the thread there's 100pxhigh scroll cotnainer and abspos with top:0 inset. 200px of content. If you set align content end scroll container starts at bottom.<br> <dael> TabAtkins: Right now abspos still connected to top of area so it's not visible. Attached to 0 position.<br> <dael> TabAtkins: That means difference in render for visible and scrollable overflow. We try and avoid that with normal content.<br> <dael> TabAtkins: Is that okay? For abspos position to jump depending on if visible or scrollable?<br> <dael> TabAtkins: That vs where authors expect abspos to be. Does it push down to always be visible?<br> <dael> iank_: Concerned if this flipped on overflow status because webdev will change that to disable scroll for example. A bit concerning.<br> <dael> TabAtkins: Not sure which you argue for in that case<br> <dael> Rossen_: My excectation is the behavior would be closer to how we handle static inflow layout. Favor stable rather than jumping with the overflow toggle<br> <dael> TabAtkins: You prefer we redefine abspos position to rely on alignment. So top:0 withing align:end would be visible within the original scroll position<br> <dael> iank_: No, the other one.<br> <dael> TabAtkins: It maintains stable position relative tos tatic content but visually jumps based on if you flip overflow on/off<br> <dael> iank_: Yes. IT's not jumping, just that the initial scroll position is set differently.<br> <fantasai> testcase<br> <fantasai> http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cstyle%3E%0Abody%20%3E%20div%20%7Bdisplay%3A%20flex%3B%20float%3A%20left%3B%20border%3A%20solid%3B%20width%3A%2050px%3B%20height%3A%2050px%3B%20margin%3A%20100px%3B%20position%3A%20relative%3B%7D%0A%3C%2Fstyle%3E%0A%3Cdiv%20style%3D%22overflow%3A%20auto%22%3E%0A%20%20%3Cdiv%20style%3D%22border%3A%20solid%20aqua%3B%20width%3A%201<br> <fantasai> 00px%3B%20height%3A%20100px%3B%20flex%3A%20none%3B%22%3E%3C%2Fdiv%3E%0A%20%20%3Cdiv%20style%3D%22border%3A%20double%20blue%3B%20width%3A%20100px%3B%20height%3A%20100px%3B%20position%3A%20absolute%3B%20left%3A%200%3B%20top%3A%200%3B%22%3E%3C%2Fdiv%3E%0A%3C%2Fdiv%3E%0A%3Cdiv%20style%3D%22flex-flow%3A%20row-reverse%20wrap-reverse%3B%20%22%3E%0A%20%20%3Cdiv%20style%3D%22border%3A%20solid%20aqua%3B%20width%3A%201<br> <fantasai> 00px%3B%20height%3A%20100px%3B%20flex%3A%20none%3B%22%3E%3C%2Fdiv%3E%0A%20%20%3Cdiv%20style%3D%22border%3A%20double%20blue%3B%20width%3A%20100px%3B%20height%3A%20100px%3B%20position%3A%20absolute%3B%20left%3A%200%3B%20top%3A%200%3B%22%3E%3C%2Fdiv%3E%0A%3C%2Fdiv%3E%0A%3Cdiv%20style%3D%22flex-flow%3A%20row-reverse%20wrap-reverse%3B%20overflow%3A%20auto%3B%22%3E%0A%20%20%3Cdiv%20style%3D%22border%3A%20solid%20a<br> <fantasai> qua%3B%20width%3A%20100px%3B%20height%3A%20100px%3B%20flex%3A%20none%3B%22%3E%3C%2Fdiv%3E%0A%20%20%3Cdiv%20style%3D%22border%3A%20double%20blue%3B%20width%3A%20100px%3B%20height%3A%20100px%3B%20position%3A%20absolute%3B%20left%3A%200%3B%20top%3A%200%3B%22%3E%3C%2Fdiv%3E%0A%3C%2Fdiv%3E%0A<br> <dael> TabAtkins: It's jumping visually. align-content:end and you have the abspost top:0 Either top of container or top of scrollable area. align-content:end top of the scrollable is above<br> <fantasai> testcase - http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=8068<br> <dael> fantasai: I made a test case if you want to load the testcase and see<br> <dael> TabAtkins: Glad the answer wasn't obvious<br> <dael> fantasai: [shares testacase]<br> <dael> fantasai: blue double border is abspos and aqua box in inflow. FIrst example is typical flexbox where both origin and scroll are top<br> <dael> fantasai: In second example it's not a scroll container. First example is same if it's scroll or not bc we're in start start<br> <dael> fantasai: Second shows overflowness<br> <dael> fantasai: I made a 4th<br> <dael> fantasai: First is abspos and an item and you can see they align.<br> <dael> fantasai: Second is overflow auto. In otherwords we clip. Layout is same<br> <dael> fantasai: Third we have the flex flow changed to be reversed in both axises so it overflows to top and the left. abspos doesn't care about flex flow, stays to top left of block<br> <dael> iank_: There's something slightly different in [missed]<br> <dael> fantasai: This is about expectations<br> <dael> fantasai: Rendering for first 3 is correct<br> <dael> iank_: No virtical scroll in 2nd?<br> <dael> fantasai: This is jsut layout and position. THere's lots of bugs about scrollers. Let's not pay attention to them.<br> <dael> fantasai: I can switch to overflow hidden<br> <dael> fantasai: 4th example is same code as 3rd but we applied hidden or auto. Ends up clipping around the behavior<br> <dael> fantasai: Question for TabAtkins is is this what we should see or something different? Important to see aqua box is top and left in 3. We defined alignment to allow people to align to bottom. DOn't want clip so you can't scroll to them. Goal of def is you shoudl be able to scroll to left and top to see content.<br> <dael> fantasai: Desc in spec to say you do the alignment...instead of alignt to bottom left you keep everything and change initial scroll position<br> <dael> fantasai: Scroller in 4th should be able to scroll to the left and up. Question we have is for an abspos element depending on how we describe it, do we want to have it layout so that when you're in its initial scroll position it's in its desc position or desc it so when you scroll to origin you get the desc position.<br> <dael> iank_: Clarification: How you're calc the layout overflow. If you've got a scrollable overflow cotnainer. Calc layout overflow from right to left. Starts on right. But initial position is still 0.<br> <dael> iank_: With align-content:end are you assuming layout overflow calc starts from bottom or start at top and scroll to bottom?<br> <dael> fantasai: That's what we're trying to figure out<br> <fantasai> updated testcase for the minutes: http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=8069<br> <dael> Rossen_: Mental model when I impl containing box edges desfined by inner border box. That inner border box def origin. You may or may not allow scrolling into the negative for purpose of accommodating alignment. THird case here illustrates using alignment you may create situations where overflow has to allow scroll to negative<br> <dael> Rossen_: Origin is always well defined and not redefined. Position always in respect to that box.<br> <dael> Rossen_: That makes both the layouts stable b/c adding or removing scrollbars doesn't change position of abspos elements. Always everyone has expected top/left is in respect to border box<br> <dael> Rossen_: otherwise a little unstable<br> <dael> fantasai: 2 renderings we're looking at for last case is what you're seeing in FF where you can scroll to see everything. One poss is you see this initially and scroll i both directions<br> <dael> Rossen_: That's overflow nto positioning<br> <drousso> present_<br> <dael> fantasai: Other is the same rendering as the second case but initial scroll position is to bottom right. See bottom right corner but can scroll to everything.<br> <myles> q-<br> <dael> iank_: Maybe different wayt o sdo align-content:end. Maybe in 3rd the aqua box should overlap and then when container is big enough the aqua box sticks<br> <dael> fantasai: Distinction between safe and unsafe. You can request overflow to always bottom but that's not the default.<br> <dael> Rossen_: We've been at this for 25 minutes. I think we have 2 choices. We can contain working on the issue or make a resolution here<br> <dael> fantasai: I'm not sure. I can see that it's a nice invarient to be able to flip overflow on and off and have thing you see the same. I can also see authors surprised if they position top-left and it's not there it's in the middle<br> <dael> Rossen_: How I'm reading convo is top left is defined by origin established by inner border box of containing block. If it's overflow and has scrollbars in that case there might be additional mech that require scrollers to enable going negative but htat's sep. SHouldn't redefine size for overflow<br> <dael> TabAtkins: No one has mentioned scrolling negative<br> <dael> Rossen_: With the aqua box aligned bottom and right, it's overflowing to the negative of the origin of the dark containing block. Do we agree? Overflow is the negative in the inline and block<br> <dael> TabAtkins: Aqua is inflow box? If that's unscrollable that's blink bug<br> <dael> Rossen_: Do we agree here aqua overflows in negative?<br> <dael> TabAtkins: Nothing in spec makes it go negative<br> <dael> fantasai: I think Rossen_ is talking about negative in respect of top and left of border box of scroll container. You're talking negative of contents which makes it unscrollable<br> <Rossen_> q?<br> <dael> fantasai: We all agree aqua box extends out ot left and top of container just like ex 3. Impl not considering that as scrollable and that's a bug.<br> <dael> iank_: One thing good to clarify is...when blink does reverse we treat similar to a [missed] cotnainer tso overflow starts in top right. :reverse we start from bottom<br> <Rossen_> q<br> <dael> iank_: That will influence decision<br> <dael> dholbert: We intend to be same in FF<br> <dael> iank_: For row:reverse and column?<br> <dael> dholbert: Yeah<br> <dael> iank_: THe question is how do you want align content to work. Start overflow from bottom and right and scroll position in initial or you start top left and scroll position is at end. THat influences this decision<br> <dael> Rossen_: We're getting into the weeds. I suggest we continue in the issue and bring back for resolution<br> <dael> Rossen_: 2 clear choices that were well articulated. I'd encourage you to continue discussion there.<br> <dael> TabAtkins: Last bit. b/c one behavior falls out if we dont' resolve on anything we're in effect choosing one.<br> <Rossen_> q<br> <dael> fantasai: Showing this whiteboard that's around concept in spec. Wanted to make sure we didn't mix up scroll to bottom of scrollable vs making etra space you need.<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/4957#issuecomment-625509733 using your GitHub account
Received on Thursday, 7 May 2020 21:35:46 UTC