Skip to content

[css-spatial] Behavior of popups / dropdowns / top-layer elements in spatial contexts #138

Description

@walton007

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

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions