Context
The CSS Spatial Layout Module introduces 3D spatial contexts via spatial: page and spatial: portal. Elements within these contexts can be lifted off the page (inset-back/inset-front) and transformed in true 3D space using the user's actual perspective.
However, the spec does not define how popup-style UI behaves when its trigger element (or an ancestor) is spatially positioned and/or transformed. This is a significant gap, as popups, dropdowns, tooltips, dialogs, and native UI are ubiquitous on the web.
Open Questions
1. Author-implemented popups (position: absolute)
If a trigger element is spatially positioned and rotated:
.trigger {
position: relative;
inset-back: 2cm;
transform: rotateX(30deg);
transform-style: preserve-3d;
}
.menu {
position: absolute;
top: 100%;
}
- Does
.menu inherit the 3D rendering context and render in the same rotated plane?
- If
preserve-3d is not set, is the menu flattened onto the trigger's plane?
- Can the menu use
inset-back/inset-front to position itself in z relative to the trigger's plane?
2. position: fixed popups
Spatial containers establish a containing volume. Does this cause position: fixed descendants to be trapped within the spatial context (similar to how transform ancestors break fixed positioning)? Or do fixed elements escape to the page plane?
3. Top-layer elements (<dialog>, popover, :popover)
Top-layer elements currently render above all normal stacking contexts and are not affected by ancestor transforms. In a spatial context:
- Does a
<dialog> or popover opened from within a spatial container remain in the top layer (2D, facing the user), or does it enter the 3D spatial context?
- If it enters the spatial context, does it follow the trigger element's rotation, or does it auto-billboard (always face the user)?
- How does anchor positioning (
position-area, anchor()) interact with 3D-transformed anchors? The spec introduces position-context: anchor to let elements follow their anchor's transform — is this the intended mechanism for popups?
4. UA-native UI (<select> dropdown, alert(), <input type="date"> picker)
These are rendered by the user agent, not by page CSS:
- Does a
<select> inside a rotated spatial container open its dropdown in 2D at the page level, or does it follow the element's spatial transform?
- Does
alert()/confirm() remain a 2D browser chrome dialog, or is it spatial-aware?
5. Hit-testing and event coordinates
Section 5 states that precise coordinates must not be transmitted for spatial pointer interactions. How does this affect popups that rely on MouseEvent coordinates (e.g., context menus, drag-to-position tooltips)?
Suggested Next Steps
It would be helpful to have a dedicated section in the spec addressing:
- Which popup mechanisms enter the spatial context vs. remain in the 2D top layer
- Whether an "auto-billboard" behavior is needed for popups to remain readable
- How
position-context: anchor should be used for popup positioning in 3D
- Interaction with the existing CSS Top Layer spec and CSS Anchor Positioning spec
Related
Context
The CSS Spatial Layout Module introduces 3D spatial contexts via
spatial: pageandspatial: portal. Elements within these contexts can be lifted off the page (inset-back/inset-front) and transformed in true 3D space using the user's actual perspective.However, the spec does not define how popup-style UI behaves when its trigger element (or an ancestor) is spatially positioned and/or transformed. This is a significant gap, as popups, dropdowns, tooltips, dialogs, and native UI are ubiquitous on the web.
Open Questions
1. Author-implemented popups (
position: absolute)If a trigger element is spatially positioned and rotated:
.menuinherit the 3D rendering context and render in the same rotated plane?preserve-3dis not set, is the menu flattened onto the trigger's plane?inset-back/inset-frontto position itself in z relative to the trigger's plane?2.
position: fixedpopupsSpatial containers establish a containing volume. Does this cause
position: fixeddescendants to be trapped within the spatial context (similar to howtransformancestors breakfixedpositioning)? Or do fixed elements escape to the page plane?3. Top-layer elements (
<dialog>,popover,:popover)Top-layer elements currently render above all normal stacking contexts and are not affected by ancestor transforms. In a spatial context:
<dialog>orpopoveropened from within a spatial container remain in the top layer (2D, facing the user), or does it enter the 3D spatial context?position-area,anchor()) interact with 3D-transformed anchors? The spec introducesposition-context: anchorto let elements follow their anchor's transform — is this the intended mechanism for popups?4. UA-native UI (
<select>dropdown,alert(),<input type="date">picker)These are rendered by the user agent, not by page CSS:
<select>inside a rotated spatial container open its dropdown in 2D at the page level, or does it follow the element's spatial transform?alert()/confirm()remain a 2D browser chrome dialog, or is it spatial-aware?5. Hit-testing and event coordinates
Section 5 states that precise coordinates must not be transmitted for spatial pointer interactions. How does this affect popups that rely on
MouseEventcoordinates (e.g., context menus, drag-to-position tooltips)?Suggested Next Steps
It would be helpful to have a dedicated section in the spec addressing:
position-context: anchorshould be used for popup positioning in 3DRelated