The issue has a specific name: "offsetParent". When an element is assigned a position of absolute|relative or undergoes a transformation that changes its position/size, it becomes the offsetParent for its child elements. Initially, the offsetParent for all elements is the viewport of the browser or the iFrame, which dictates where overflowing content will be displayed and provides a reference point for absolute positioning.
In one of my projects, I encountered a situation where a 'popup' window contained a dropdown menu that extended beyond the window's boundaries. However, when the window was moved using a transformation or relative positioning, the dropdown would appear in the wrong location (with additional offsets from the top-left corner of the window) and be clipped at the window's edges. To address this, I positioned the dropdown absolutely by appending it as a child of the Body element instead of the window. I calculated the absolute position of the dropdown based on the button that triggered the menu (using clientBoundingBox) and adjusted for the offset from the button's offsetParent. This ensured that the Body element served as the new bounding area. Although this approach became more complex with multiple z-axis levels, it was sufficient considering that the window needed to remain visible for the menu to open effectively. This solution involved using JavaScript rather than relying solely on CSS.
You can't have it both ways. Once you remove something from the original layout context, it establishes its own, separate (and constrained) layout parameters.