Stack

A stack is a flex container with a gap. By default it stacks its children in a column, and Horizontal lays them out in a row instead. Reversed paints them from the far end back towards the near one - bottom-to-top in a column, end-to-start in a row - which only changes the painted order: the order the content is read in by a screen reader and reached in by the keyboard stays the order it is written in.

Gap is the room between the children, in any CSS length (0.5rem, 8px, 2%, var(--my-gap)), and it defaults to 1rem. It is created with the CSS gap rather than with margins on the children, so it never appears before the first child or after the last one and it survives a child being hidden. HorizontalGap and VerticalGap each replace it on a single axis, which is what a wrapping stack that needs more air between its rows than between its columns wants, and GapXs to GapXxl - and, per axis, HorizontalGapXs to VerticalGapXxl, shown in the Responsive section - replace it per breakpoint. The room is left empty; drawing a line in it is a BitSeparator placed between the two children it separates, which is a child of the stack like any other and is spaced by the same gap on both of its sides.

HorizontalAlign and VerticalAlign place the children by axis rather than by the flexbox property that happens to reach that axis, so each of them keeps meaning the same thing when the stack changes direction. On the axis the children are laid out along, all of Start, Center, End and the three space distributions apply; on the axis across them, Start, Center, End, Baseline and Stretch do. A value that means nothing on the axis it lands on is dropped and steps aside for Alignment, the shorthand that sets both axes at once. These place all of the children at once; pushing a single one of them - the actions at the end of a toolbar, say - away from the rest is a BitSpacer between the two groups instead.

Without Wrap the children of a stack are squeezed to fit rather than moved, which is what a toolbar that must never break wants and what a row of chips does not. WrapReverse wraps the other way, laying the rows out from the far edge of the stack back towards the near one. Once there is more than one row and the stack is larger than they are, AlignContent is what decides where those rows sit - it is the only alignment that acts on the rows themselves rather than on the children within a row. WrapXs to WrapXxl answer the question per breakpoint, with Wrap as the base of that chain, so a row that breaks onto a second line on a phone and holds its single line on a desktop is those two parameters and nothing else; WrapReverse stays outside the chain and is the way every breakpoint that wraps wraps.

HorizontalXs to HorizontalXxl give the stack a direction per breakpoint: true lays the children out in a row and false in a column, and each value keeps applying to every wider breakpoint until another one replaces it. That makes the column-on-a-phone, row-on-a-desktop layout a single parameter instead of a media query, and it leaves Horizontal as the base of the chain for any width none of them reach. HorizontalAlign and VerticalAlign follow the direction each breakpoint gives, so they keep naming the same axis of the screen at every width and the stack is realigned along with it - including which of their values mean anything on the axis they land on there. GapXs to GapXxl are the same chain for the spacing, with Gap as their base, which is what a stack that folds into a column and wants less room between its children there is written as. HorizontalGapXs to HorizontalGapXxl and VerticalGapXs to VerticalGapXxl are one more chain each, for the wrapping stack whose rows and columns want to change by different amounts; a breakpoint neither of them names falls back to whatever the Gap chain resolves to there, so only the axis that needs its own answer has to be written out. WrapXs to WrapXxl, shown in the Wrap section, are one more chain of the same shape, for the row that may break onto a second line at some widths and not at others. Reversed and WrapReverse are not part of any of these chains: each of them says which way round, and that is the same answer at every width. Narrow the window to below 960px to watch the stacks fold into columns.

A stack is a flex container and a flex child at the same time, so nesting one inside another is how a real layout is built: the outer stack decides the direction and the spacing of its parts, and each inner stack does the same for its own. Every stack keeps its own parameters - the ones below alternate direction at each level - and a nested stack claims only the space its parent gives it.

The four parameters that act on the children instead of on the stack. FillContent expands every direct child across the axis they are not laid out along - the full width in a column, the full height in a row - which is what a menu or a sidebar of equally wide items wants; the size is forced, so a child that stated one of its own is overridden. On a stack that wraps, or one that changes direction with the width of the window, it fills the row each child landed on rather than the whole stack, as a stretch that leaves a stated size alone. The other three act along that axis: GrowContent lays the children out at their natural size and shares what is left over between them, so a child that holds more stays larger; EqualContent takes their content out of the sum instead, so a row of three ends up in exact thirds whatever each of them holds; and NoShrinkContent keeps them at their own size when the stack runs out of room, so what no longer fits overflows it - or wraps, with Wrap - rather than being crushed into it. FillContent is on the other axis from all three, so it combines with any of them.

A stack fills its container on both axes by default, which is what a stack that lays a page or a panel out wants and what a stack of a few rows sitting inside a taller box does not. AutoWidth, AutoHeight and the AutoSize shorthand hand that axis back to the content. FitWidth, FitHeight and FitSize do the same but with a definite size, so unlike the automatic ones they also hold when the stack is a child of another flex container that stretches its children - which is what the dotted row below does.

These eight describe the stack as a child of another flex container rather than as a container itself, so they only say something inside a parent that has room to share out - most often another stack. Grow is the flex-grow factor and Grows is the same thing with the factor every layout reaches for first, so the three nested stacks below take three sixths, two sixths and one sixth of whatever their row has left over. Basis is the size that sharing starts from, and a basis of 0 takes the content of a stack out of the sum, which is how a row of equal columns is built out of stacks that hold different amounts. NoShrink takes a stack out of being squeezed when the room runs out, so the space has to come from its siblings instead, and Shrink is the same thing with a factor of its own - the mirror of Grow for a shortage rather than a leftover. Shrinkable is the other end of the same story: a flex child is never squeezed below its own content unless it is told it may, which is why a nested stack refuses to shrink far enough for the label inside it to be truncated with an ellipsis, and this is what lifts that floor on both axes. Self places this one stack across the axis of its parent, overriding for it alone whatever the parent aligns its children with, and Order moves it among its siblings visually while leaving the reading and tab order untouched.

Padding is the room between the border of the stack and its children, and it takes the CSS shorthand in full: one length pads every side, two pad the block and then the inline axis, and four pad each side in turn. The stack is sized border-box, so the padding is taken out of the size it already has rather than added to it, and a padded stack still fits exactly where an unpadded one did. There is no per breakpoint chain for it as there is for the direction and the spacing: a padding that answers to the width of the window is a fluid length such as clamp(0.5rem, 2vw, 2rem), which follows the viewport without a breakpoint at all.

The stack renders a div, and Element swaps that tag for any other one, which is how a stack of things that form a list becomes a ul or a region of the page becomes a nav. Only the tag name changes - the layout is untouched - so a landmark element given here is worth pairing with an AriaLabel that names it. A stack rendered as a ul, an ol or a menu is also given a role="list" of its own, since some browsers stop reporting those elements as lists as soon as they are laid out as a flex container; a role among the splatted html attributes still replaces it. Inline changes the box the stack itself is rather than its tag: an inline stack flows with the text around it and is sized by its content instead of by the box around it, which is what a group of chips or of icons sitting inside a sentence, a table cell or a label needs. A size given through Style or through the Fit and Auto parameters still wins over that.

Size is the gap picked from the spacing scale of the theme instead of being written out by hand, in the usual three steps: Small, Medium and Large. It is the parameter to reach for when the layouts of an application should stay on the rhythm of its theme, since the length it resolves to follows the spacing unit and the density of the current theme and changes along with them. The more specific Gap, HorizontalGap and VerticalGap each win over it on the axis they target.

The stack renders a single element, so Style and Class land straight on it. The inline styles are appended after the ones the component generates, so they win over them - which is how a stack is given a height, a background or a border without a class at all. The one declaration that is deliberately hard to reach is the display, since a stack that is not a flex container is not a stack. Everything the parameters of the stack already cover - the gap, the padding, the direction, the sizing - is worth reaching for there first, since those are resolved per breakpoint and per theme where a hardcoded declaration is not.

A horizontal stack runs along the text direction, so marking it right-to-left with Dir mirrors it: the children begin at the right edge, and HorizontalAlign keeps meaning "towards the edge the children begin at" rather than a fixed side of the screen. Reversed composes with it and flips that back again. A vertical stack lays its children out top to bottom either way, so only the alignment across it moves.