The production question
A designer builds a toolbar button whose label should stretch to match a neighboring icon's width, sets the label's horizontal sizing to Fill container, and finds the option greyed out — or watches the layout snap back to Hug the moment they click away. This is the single most common place new Auto Layout users get stuck, and the fix is not a hack: Fill has nothing to claim inside a parent that is itself set to Hug contents, because Hug means “size follows children” and Fill means “take the space the parent offers” — the two can't both be true on the same axis at once. Do you widen the parent to a Fixed pixel value to unblock Fill, restructure which frame in the hierarchy actually owns the Fill relationship, or accept Hug on the child and solve the alignment a different way? Each option removes the greyed-out state, but only one of them keeps the layout genuinely responsive when the toolbar's width changes later instead of just today.
How to decide
- Ask what determines this layer's size on this axis: its own content (a label, an icon, a badge word) or the space its parent offers? Content-driven sizing is Hug; space-driven sizing is Fill.
- Before touching the child, check the immediate parent's sizing mode on that same axis. If the parent is set to Hug contents, no child on that axis can Fill — there is no defined space to take. Fix the parent's mode first; don't hardcode the child to escape the error.
- Decide width and height independently. A card can Fill its width to match a grid column while Hugging its height to match its own content in the same frame — sizing mode is per axis, never one toggle for the whole layer.
- For anything that must survive a narrow context without collapsing to an unreadable width, add a minimum width instead of switching to Fixed — Fixed removes exactly the flexibility the sizing decision was supposed to build in.
- Before treating the decision as final, swap in the longest realistic content (a 40-character label, a four-line heading) and the narrowest realistic frame at the same time. A sizing mode that only holds up at default content length and default frame width hasn't actually been tested yet.
- If two or more children need to divide space evenly rather than one taking whatever is left over, that calls for multiple Fill children with equal effective weight, not one Fill child plus manually calculated gaps around Hug siblings.
Correct vs. incorrect
In the Cloud Recovery dashboard's toolbar, the search input is set to Fill container on its width while the Region and Status filter dropdowns sitting next to it are set to Hug contents. The toolbar frame itself resolves to a real width (it Fills the screen-width frame above it), so the chain of sizing intent is unbroken from the search field all the way up to the page. The visible result is a search field that visibly grows or shrinks as the window resizes while the filters stay exactly as wide as their own labels — which is the behavior a toolbar actually needs, not a coincidence of the default layout.
A designer adds a status badge inside a workloads table row and sets it to Fill container, expecting it to stretch to match a column width — but the row frame is itself set to Hug contents, sized to fit its children. Figma won't apply Fill in that context, so instead of changing the row's sizing mode, the designer works around the greyed-out option by typing a Fixed 96 px width directly onto the badge. That workaround holds fine while every status reads “Healthy,” but breaks the moment a status reads “Recovery in progress” — the Fixed-width badge clips the longer label instead of growing to fit it, because the fix patched the symptom on the child instead of the sizing contract on the parent.
Practice it, then try to break it
Build a single notification row inside a 400 px Fixed-width parent frame: a Fixed-size icon, a Hug-contents title, a Fill-container message area, and a Hug-contents timestamp. Confirm it looks right, then change only the parent's sizing mode from Fixed to Hug contents and note exactly which child breaks and why before you undo it. Set the parent back to Fixed, then test the row with a one-word message and with a roughly 200-character message to confirm the message area — not the icon or timestamp — is the only element that grows.
Stress test: Nest three Auto Layout frames deep — an outer card, a middle content stack, and an inner button row — with a Fill child at every level, then change only the outermost card's sizing mode from Fixed to Hug contents. If you can correctly predict, before checking, exactly which nested Fill children silently stop behaving as Fill (and why frames you didn't directly touch are affected), the parent-child sizing contract has actually been learned rather than pattern-matched from one working example.
Common mistakes
- Setting a child to Fill container when its immediate parent is set to Hug contents, then working around the resulting error by hardcoding a pixel width on the child instead of fixing the parent's sizing mode.
- Setting a text layer's height to Fixed to force vertical alignment, which clips the text the moment a longer name, a translation, or a status message wraps to two lines instead of one.
- Treating Hug and Fill as a single setting per layer instead of a setting per axis, so a card meant to Fill only its width also ends up Filling its height and stretches to match its tallest sibling.
- Faking gaps or padding with empty spacer layers instead of using the Auto Layout parent's own gap and padding values, which breaks silently the moment an item is added, removed, or reordered.
Accessibility and handoff
Sizing mode is invisible in a flat screenshot — a developer working from an image alone cannot tell whether a column was Fill, Hug, or Fixed, so getting Auto Layout's direction, gap, padding, and per-axis sizing right in the file directly determines whether the implementation uses flexbox correctly or silently reverts to fixed-pixel positioning.
FAQ
- What's the actual difference between Fill container and a percentage width?
- Figma has no percentage-width option on Auto Layout children; Fill container means “take whatever space is left after siblings and padding are accounted for,” which behaves like flex-grow, not like a fixed percentage of the total.
- Why is Fill container greyed out or not working on a layer?
- Fill only works when the immediate parent is an Auto Layout frame with a resolved size on that axis (Fixed, or itself Filling/Hugging against a sized ancestor) — inside a parent set to Hug contents, Fill has nothing to measure against.
- Do minimum and maximum width work together with Fill container?
- Yes — min/max sits on top of Fill as a constraint: the child still fills available space but won't shrink below the minimum or grow past the maximum, which is how a reading column stays comfortable on both a narrow laptop and an ultrawide monitor.
- Does every layer in a design need Auto Layout?
- No — a genuinely fixed relationship, like an icon centered in a fixed circular badge or a decorative background image, may not need Auto Layout at all; applying it everywhere adds overhead without changing behavior when nothing in that relationship needs to resize.
Take this skill into a connected project.
The full Mission 2 lesson includes guided steps, a timer, quiz, pass criteria, and saved progress.