Stacked edge cases need their own frames

What it is

Edges that are well-defined in isolation produce a new geometry when they occupy the same slot; they do not add. Stacked-edge frames are dedicated screens for combinations that actually co-occur: an extreme-long title plus many tags plus an inline warning; a zero-item list while filters stay on; a short name beside an overlong secondary field. If the package only ships the single-factor frames for “long,” “many,” and “warning,” implementation can only superpose them at runtime, and superposition collides.

This is about already-defined edges sharing space, not about inventing a third single factor. Hover-plus-disabled priority inside a component is a different object — what stacks here is the shape of content.

Why it happens

Each single-factor policy competes for the same space. A long title wants a second line, many tags want a wrap or a fold, a warning icon wants a column. When all three claim height and the leading edge from their own frames, row height is added three times, the action is pushed off-screen, or the warning covers the last characters of the title. The policies do not conflict on paper because they were never asked to be true together.

Stacking also rewrites priority. Folding tags into “+N” is reasonable for “many” alone; stacked on a full-width error bar, +N may become unhittable or fail contrast. Centering a short name is tidy alone; beside an overlong timestamp, the name looks dragged. None of that is a third state you can guess by averaging two frames. Without a combination frame, the implementer picks a winner — usually whichever edge they last touched — and the other bound is sacrificed in integration, never written back.

Where it stops holding

Combinations that cannot co-occur need no frame: a zero collection cannot also overflow; “many” folding should not stack on a still-loading body. Combinatorial explosion is not saved by exhaustive drawing — ship stacks that co-occur, picked from co-occurrence counts or support records, not from a Cartesian product. If two edges share no geometry (a color-blind palette versus long text in another region that never collides), verify them separately; a forced combo frame adds no information. Stacking in paginated print or PDF export is another page geometry; a screen combo frame cannot stand in.

Applying it

• From production logs or walkthrough notes, list pairs of edges that are true on the same row or card. Ship at least one frame per pair, and on it write which policy yields.
• Build combination frames from records that actually co-occur. Do not pile every extreme onto a demo disaster card; that card forces a layout that exists only in the demo.
• Mark unsquashable elements on the combo frame (primary action, error icon, price) so implementation knows what moves last in a conflict.
• Construct a test record where both edges are true, open that row in the built UI, and overlay the combo frame. If the warning covers the title’s end, or the folded +N sits unreadably on the error bar, the implementation is linearly superposing. Add the frame to the package; do not only tweak z-index in code.

Related

• Same group: R2.05.1 Handoff must show both extreme-long and extreme-short content · R2.05.2 Zero, one, and many each need their own defined layout · R2.05.3 Whatever is left unspecified will be invented by the implementer · R2.05.4 Bound values come from real distributions, not imagined extremes · R2.05.5 Overflow behavior must be specified separately by content type
• Adjacent: R1.03 Completeness of component states · R2.01 Annotation and asset export
• Search terms: stacked-edge frames · compound edge case · co-occurring extrema