Re: [csswg-drafts] [css3 positioning] support position:sticky inside an overflow:hidden|auto on general parents (#865)

Hey, just commenting since we have a similar situation as @AaronBeaudoin brought up in https://github.com/w3c/csswg-drafts/issues/865#issuecomment-1267567002 but with some extra nuance that makes `overflow: hidden` appealing, and not a detail I've seen brought up here yet.

One of the greater benefits of `overflow: hidden` is that it clips "normally" positioned children, *but not* children with `position: absolute`. In other words you can use it to cut off corners of static children - or, in principle, sticky children! - that "seep out" past the rounded corners of the parent. But you're left with flexibility: if you do need other children to leave that containing box, *while still being placed relatively,* `position: absolute` is your go-to. (In a `position: relative` parent of course.)

We're taking advantage of basically this `overflow: hidden` behavior for hover-tooltips beneath links (in addition to cleaning the rounded corners of the containing panel):

<img width="283" alt="Floaty-looking box positioned neatly beneath a hovered link in ordinary text content, on top of other text content." src="https://github.com/w3c/csswg-drafts/assets/9948030/d1d78dd9-5925-4a51-80ac-9add8eba4959">

But in practice we aren't able to use `overflow: hidden`, of course, because it prevents the sticky heading element from scrolling with the page. So instead we're using `contain: paint` at the moment (`overflow: clip` is fine too, but worse browser support, and the same issue ahead). And this works fine... *until* we get to that case where `overflow: hidden`'s true power shines... and `contain: paint` sure doesn't!

<img width="240" alt="A rather tall tooltip near the bottom of a page. Where the main panel cuts off and the footer begins, the tooltip gets chopped in half!" src="https://github.com/w3c/csswg-drafts/assets/9948030/aa832c8c-a1dd-415c-a463-f1ca3657c525">

It seems like the only workable solution here is to set `overflow-y: scroll` on the main element, but this seriously alters and conflicts with the layout of the site (you're supposed to scroll the *page,* not the main content panel).

We could position the tooltips with JavaScript and separate them outright from the main page layout tree, but it's such a janky solution. Placement in the HTML tree, statically generated, and positioned relatively to a parent `position: relative` link isn't something we're interested in leaving behind, but it's not clear what current solutions *don't* involve using `contain: paint` or similar - and that's not compatible with `position: absolute` elements that sometimes extend past the containing element's border.


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


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

Received on Wednesday, 10 January 2024 00:45:31 UTC