Re: [csswg-drafts] [css-position-3] Making a stickypos in a scroller also see the viewport edges (#8286)

The CSS Working Group just discussed `[css-position-3] Making a stickypos in a scroller also see the viewport edges`.

<details><summary>The full IRC log of that discussion</summary>
&lt;dael> TabAtkins: An issue for a good while is when people use stickypos by default it sticks to viewport. Very useful. Stays on screen<br>
&lt;dael> TabAtkins: If you have a scrollable ancestor this stops happening. Stays in scrollport but no longer sticks to viewport. IF scrollport larger than screen you can scroll sticky thing offscreen even though intended to be always visible<br>
&lt;flackr> q+<br>
&lt;dael> TabAtkins: Request is for some mech to make sure a stickypos can see viewport edges even when it's not the closest scroller. Could go further to allow arbitary scroll containers, but important things are nearest scrollport and viewport<br>
&lt;Rossen_> ack flackr<br>
&lt;dael> flackr: Commented on issue, think viewport is too special case. I don't know if we have ability to have overflow:clip in one postion. That oculd be workable to make this composable so you can observe scroller scrolling you and not the one clipping you<br>
&lt;dael> TabAtkins: I don't think that solves. IN a scroller that can be scrolled vertically. You have a big table and want head to be sticky. Box of table is partially offscreen but you want thead to be sticky. Genuinely scrollable access is that thing you want to pay attention past<br>
&lt;dael> flackr: Concern is if we special-case viewport there's still a lot of cases where doc can't use viewport<br>
&lt;dael> TabAtkins: Agree. Hits on issue viewport has magic we can't reproduce. Talked in the past about being able to mark something as root scroller. Perhaps it's a matter of we should do that and it interacts well here<br>
&lt;dael> flackr: That would help<br>
&lt;dael> TabAtkins: I think you were a part of those discussion in the past, but that was years ago<br>
&lt;dael> flackr: It certainly stalled.<br>
&lt;dael> fantasai: Other prop in the issue was make it sticky to nearest scroller in the relevant axis. If you have only horz scroll something sticky in vertical axis sticks to next scroller up<br>
&lt;dael> TabAtkins: I thought use case listed in root is that or by what flackr mentioned<br>
&lt;dael> flackr: I think they are same. They could ignore nearest scroller if it desn't impact in that axis<br>
&lt;dael> fantasai: I feel like it's more flexible. Would it make sense?<br>
&lt;Rossen_> t-1 min<br>
&lt;dael> flackr: Tricky bit is non-scrollable direction is treated as overflow:hidden<br>
&lt;dael> fantasai: So can't be a scroll container<br>
&lt;dael> flackr: Could make non-scroll overflow:clip so it's explicitly not scrollable<br>
&lt;dael> flackr: Haven't fully thought if that works<br>
&lt;dael> TabAtkins: I don't think anything wrong with that. Clipping in 1 axis is weird visual stuff, but not if scrollable in other axis<br>
&lt;dael> TabAtkins: That might be it<br>
&lt;dael> flackr: Might be good in general to say something is clipped in one axis<br>
&lt;dael> TabAtkins: I want to do investigation, but that's a plausable approach<br>
&lt;dael> Rossen_: TabAtkins you want to do that and bring it back?<br>
&lt;dael> TabAtkins: Sounds good<br>
&lt;dael> fantasai: I wasn't expecting a resolution, but good to have progress<br>
</details>


-- 
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8286#issuecomment-1451120259 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Thursday, 2 March 2023 01:01:51 UTC