skip to content

In a game companion app's design system, a squad-invite toast hides behind an open sheet and a menu opened in a dialog appears beneath it; what layering rules fix this?

level: seniorimportance: should knowfreq 34%

answer

  1. a fixed number per type is not enough
  2. named layers by role
  3. opened from it, drawn above it
  4. visual level follows layer order
  5. content under a modal is inert

basics

~20 s

Define a named layer order by role, with toasts above sheets and dialogs, and add a relative rule: a surface opened from another appears directly above its opener, whatever its type. Visual elevation must follow that order.

solid answer

~50 s

Both bugs come from giving each component type one fixed layer and ignoring relationships. The fix is two rules. First, a **named layer order by role** for independent surfaces: page content, sticky bars, navigation drawers, sheets, dialogs with their scrim, and **toasts** at the top so a squad invite is never hidden. Second, a **relative rule** for dependent surfaces: anything opened from another surface, such as a menu from a dialog, appears **directly above its opener**, so the most recently opened surface in a chain is on top. The visual level must agree, so a higher layer never casts a smaller shadow or darker tone than what it covers. Under the WAI-ARIA modal dialog pattern, content under an open modal is inert, so an actionable toast shown during a dialog needs a decision: defer it, or show it without its action until the dialog closes.

go deeper

for a junior

Recall the order of common overlays, from page content up to toasts, and that a menu appears above whatever opened it.

for a middle

Explain why fixed per-type layers fail for anchored surfaces, and why visual elevation and the scrim must match the layer order.

for a senior

Show how you would diagnose hidden overlays, replace ad-hoc layer values with named layers plus the opener rule, and test the risky combinations.

for a principal

Decide system-wide how toasts behave while a modal is open, weighing deferral against hiding actions, and how strictly teams may add new layers.

## Diagnosing the two bugs In the game companion app, each overlay component was given one fixed layer: sheets got a high number, dialogs higher, menus somewhere in between, and toasts were added later at a value below sheets. Two failures follow: - **The toast hides behind the sheet** because its layer was chosen without reference to the other overlays. - **The menu opened inside the dialog appears beneath it** because menus sit on a lower fixed layer than dialogs. The menu would be correct on the page, but it is wrong when its opener is a dialog. The root cause is treating layering as a property of the **component type** alone. Some surfaces are independent; others exist only in relation to the surface that opened them. ## Rule 1: a named layer order by role For independent surfaces, the system defines a small, ordered set of **layers**, each with a name and a role: | Order | Layer | Examples | |---|---|---| | 1 | base | lobby, lists, inventory grid | | 2 | raised | sticky header, floating quick-join control | | 3 | navigation | side drawer | | 4 | sheet | squad-invite sheet, filter sheet | | 5 | modal | match-result dialog and its scrim | | 6 | notification | toasts | Toasts sit at the top because they are brief, non-blocking and must never be hidden by whatever happens to be open. Components reference these layers by name; no team picks a number. ## Rule 2: dependent surfaces sit above their opener Menus, popovers and tooltips are **anchored transients**: they belong to the control that opened them. For these the rule is relative: 1. A surface opened from another surface appears **directly above its opener**, whatever their types. 2. Within one chain, the most recently opened surface is on top. 3. Closing a surface returns the chain to the state before it opened. So a menu opened from the page sits above the page, and the same menu opened from a dialog sits above the dialog. A fixed "menu layer" can never satisfy both cases. ## Visual elevation must agree with the order Layer order and visual elevation are two expressions of one idea. If they disagree, users get mixed signals: - A higher layer should use an equal or higher elevation level: larger, softer shadow in light themes, lighter tone in dark ones. - A **scrim**, a dimming layer, goes between a modal surface and everything beneath it. The WAI-ARIA Authoring Practices dialog (modal) pattern notes that windows under a modal dialog are inert, and that inert content is typically visually obscured or dimmed; the scrim is the visual half of that contract. - Non-modal sheets may omit the scrim, which tells users the content behind them is still usable. ## Toasts and modals: a real design decision Putting toasts on the top layer creates a question. When a modal dialog is open, everything outside it is inert, so a toast that appears over it **with an action button** shows an action the user cannot reach. The system has to choose: - **Defer** actionable toasts until the modal closes, and show informational ones immediately. - **Show without the action** while a modal is open, keeping the action available afterwards elsewhere. - **Route** the message into the dialog's own content when it concerns the dialog. Each is defensible; what matters is that the system decides once and documents it, rather than each team finding out in production. ## Rolling the rules out - Replace every per-component layer value with a named layer or the relative rule. - Document in each overlay component's spec whether it is independent or anchored, and which layer it uses. - Keep the layer list short: every added layer is another place for surfaces to collide, so a new one needs a role the existing layers cannot express. - Test the combinations that break in practice: menu in dialog, toast over sheet, tooltip in a menu, dialog opened from a sheet. - Leave the mechanics of rendering each layer to platform guidance; the design rule is the order, not the implementation.

  • Why can't a single fixed layer value per component type ever get menus right?
    Because a menu's correct position depends on its opener, not its type. On the page it must sit above page content; inside a dialog it must sit above the dialog; inside a sheet, above the sheet. Any single fixed value is either below some possible opener or needlessly above surfaces it should not cover. Only a relative rule, above whatever opened it, handles every case.
  • What does a scrim communicate that elevation alone does not?
    Elevation says the surface is on top; a scrim says everything underneath is currently unavailable. The WAI-ARIA dialog (modal) pattern describes content under a modal as inert and typically dimmed or obscured, and the scrim provides that dimming. Omitting it on a non-modal sheet signals the opposite: the content behind remains usable.

saying these in an interview costs you the question

  • Give each overlay type one fixed layer number and the order will sort itself out.
  • Menus should always use the highest layer so nothing ever covers them.
  • Content under a modal dialog stays usable as long as it is visible.
  • A higher layer may use a smaller shadow than the surface beneath it.
  • Toasts can use any layer, since they disappear quickly anyway.