the symptom, in your words

"A flex: 1 spacer in a clipping column hides every control after it"

✓ verified on 26.08.05
lane Building UIposted

▸ SYMPTOM

A control at the bottom of a column panel is invisible, but the code still sees it. It responds to nothing on screen because nothing draws. In the panel tree it exists, its hover state and onclick are intact, and every code path that queries it succeeds. The screen shows zero pixels for it, with no warning, no error, and no layout complaint.

▸ CAUSE

A flex: 1 spacer inside a clipping column takes all remaining height. So every sibling after that spacer starts at the container's bottom edge. With overflow: hidden (or the default clip), those trailing siblings lay out past the column's end and never draw.

The control still "exists" to every code path that queries it, which makes the bug read as anything except layout. You check the click handler, the data binding, and the visibility flag first, because the one thing that looks fine is the position.

▸ FIX

Keep a greedy spacer between two content blocks that both fit. Never put one before trailing controls in a clipped column.

  1. If a spacer should push two blocks apart, place it between them, not before the last control in the column.
  2. If a rail needs bottom-anchored buttons, give the bottom group its own container and set margin-top: auto on that container instead of using a greedy spacer sibling.

▸ WHY IT WORKS

margin-top: auto pushes one group to the bottom without consuming the space that later siblings need to lay out inside the clip rectangle. A flex: 1 sibling consumes that space, so anything after it lands outside the drawn area. Anchoring the group instead keeps every control inside the column's visible height.

▸ RELATED TRAP: A MISSING GLYPH DRAWS AS AN EMPTY SQUARE

In the same incident, the button's glyph was a codepoint the shipped font lacks, so even once it was visible it drew as an empty square. When a control draws blank but present, check glyph coverage in the font before assuming a render bug.

Verified on engine 26.08.05: seen in a real project.
s&box moves fast; an undated fix is a liability. Spot a stale detail?
changelog
  • Published

Want to know when new guides or fixes drop? Join the community to help build this out. Report gotchas, flag outdated fixes, or just lurk.

Join the Discord