- From: Tab Atkins Jr. via GitHub <sysbot+gh@w3.org>
- Date: Wed, 20 Mar 2024 17:47:55 +0000
- To: public-css-archive@w3.org
Given that top layer lets us do this already, I assume that the core functionality of "move this element around in the box tree" is at least feasible. What I'm not clear on is if there are complications that make it difficult to go anywhere between "use the normal CB" and "use the topmost possible CB". > I'm not entirely clear why this fixed-positioning context restriction is useful for container query implementations. I *think* it's just because of static positioning - figuring out the static position requires doing layout on the subtree, and that would defeat the layout-containment optimization. We'd have to zero out the static position if we did something with this. (Which isn't a problem for anchor positioning, obviously.) I think that's similarly why things like transforms create fixpos containing blocks - if the static position *isn't* transformed, then it's just a nonsense position with no relation to anything, but if it *is* transformed, then it could become an unaligned non-rectangle wrt the fixpos element, which isn't meaningful for static positioning either. So yeah, in all cases I think it's fine to let an element move its CB higher in the tree, so long as it loses its static position in the process (just goes in the start/start corner or something instead). -- GitHub Notification of comment by tabatkins Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10102#issuecomment-2010236836 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 20 March 2024 17:47:57 UTC