First, thank you for Amber Console. We are embedding it in an operator-facing application and have found the project unusually thoughtful about both physical character and cascade behavior.
What we observed
The shared frame rule currently normalizes every direct child:
.ac-bloom > *, .ac-crt > *, .ac-afterglow > * {
position: relative;
z-index: 1;
}In an embedded application, a modal rendered as a direct child of the simulated frame had its own class-based position: fixed; z-index: 50 styling. The frame selector has greater specificity, so the modal became position: relative; z-index: 1, entered normal layout, and rendered underneath the console instead of covering the viewport.
A minimal shape is:
<div class="ac-screen ac-bloom">
<div class="app-modal">…</div>
</div>
.app-modal {
position: fixed;
inset: 0;
z-index: 50;
}Current workaround
We portal the modal to document.body, outside the simulated frame. That is a sound application-level boundary, but the broad child selector could surprise other consumers that place popovers, dialogs, sticky controls, or other explicitly positioned UI inside a frame.
Possible direction
I am opening this as an issue rather than proposing a patch because the stacking rule protects simulation overlays and its safest shape belongs to the project. Possibilities might include targeting a known content wrapper such as .ac-screen__body, or lowering the normalization selector's specificity so explicit consumer positioning wins.
If you consider this a framework bug, I would be happy to prepare a focused change and computed-style regression in the direction you prefer.
First, thank you for Amber Console. We are embedding it in an operator-facing application and have found the project unusually thoughtful about both physical character and cascade behavior.
What we observed
The shared frame rule currently normalizes every direct child:
In an embedded application, a modal rendered as a direct child of the simulated frame had its own class-based
position: fixed; z-index: 50styling. The frame selector has greater specificity, so the modal becameposition: relative; z-index: 1, entered normal layout, and rendered underneath the console instead of covering the viewport.A minimal shape is:
Current workaround
We portal the modal to
document.body, outside the simulated frame. That is a sound application-level boundary, but the broad child selector could surprise other consumers that place popovers, dialogs, sticky controls, or other explicitly positioned UI inside a frame.Possible direction
I am opening this as an issue rather than proposing a patch because the stacking rule protects simulation overlays and its safest shape belongs to the project. Possibilities might include targeting a known content wrapper such as
.ac-screen__body, or lowering the normalization selector's specificity so explicit consumer positioning wins.If you consider this a framework bug, I would be happy to prepare a focused change and computed-style regression in the direction you prefer.