Constraints Go Down, Sizes Go Up

"It is in working within limits that the master first shows himself." — Johann Wolfgang von Goethe, Natur und Kunst (1802)

Flutter's layout model fits in one sentence, and unlike most such claims, the sentence is genuinely sufficient:

Constraints go down. Sizes go up. The parent sets the position.

Every layout surprise in Flutter — the SizedBox that ignores its size, the Column that overflows, the Row whose children vanish, the widget that fills the screen when you wanted it small — is that sentence being applied somewhere you did not expect. Learn it properly once and the debugging becomes mechanical.

This Part measures the model rather than describing it, because the framework's test harness runs the real layout engine and will tell you exactly what any widget receives. We begin with the most useful measurement in the volume.

Before that, it is worth being clear about which tree this is. Part I established three — widgets describe, elements persist, render objects lay out and paint — and everything in this Part happens in the third. Layout is not something widgets do; it is something RenderObjects do, and the widgets you write are descriptions that produce them. That matters for debugging, because the error messages in this Part all name render objects rather than widgets, and the correspondence is not one-to-one: your Center is a RenderPositionedBox, your Padding is a RenderPadding, and a great many widgets produce no render object at all.

It also explains why the model is so uniform. There are around 197 render object classes against 850 widget classes, and every one of those 197 implements the same protocol — receive constraints, report a size. A Row and a Text and a CustomPaint differ enormously in what they do and not at all in how they are asked.

One widget, six parents, four sizes

SizedBox(width: 200, height: 100) is about as unambiguous as a request gets. Here is what it actually measures, placed under different parents.

What each parent hands down

The way to see the model directly is to measure the constraints a child receives, which LayoutBuilder will report.

Tight, loose, and why the distinction is the whole game

The three steps, walked

Seeing constraints live

Every box shows the same widget reporting a different answer. Nothing about Probe differs between them; the only variable is what it was allowed to be.

One detail in that block is worth a note, because it is a genuine oddity I only found by compiling it: ConstrainedBox has no const constructor. Every other widget in the demo does, and ConstrainedBox looks like it should, and it does not:

class ConstrainedBox extends SingleChildRenderObjectWidget {
  ConstrainedBox({super.key, required this.constraints, super.child})
    : assert(constraints.debugAssertIsValid());

The reason is the assertion. A const constructor's initialiser list may not call arbitrary methods, and debugAssertIsValid() is one — so validating the constraints in debug builds costs the widget its constancy in every build. That is a small, concrete instance of Part II's rules arriving somewhere real: const is not a modifier you can add wherever you like, and a framework primitive lost it to a debug check.

The practical consequence is minor and worth knowing: a subtree containing a ConstrainedBox cannot be const all the way up through it, so the const boundary stops there. If you need one and the constancy matters, SizedBox and BoxConstraints can both be const, and a ConstrainedBox with a const child still lets that child be skipped.

Where the rule runs out

The model is genuinely sufficient for describing what happens, and there are three places where knowing it is not enough on its own, each of which gets a chapter later in this Part.

Unbounded constraints. A Column passes unbounded height to its children, so a child that wants to fill the available space has nothing to fill. Put a Column inside a Column, or anything inside a SingleChildScrollView, and widgets that behaved perfectly elsewhere start throwing. The measurement table above shows exactly where the infinities come from.

Shared axes. When a Row has several children, the available width has to be divided, and the rule as stated says nothing about how. Expanded and Flexible are the mechanism, and the measurement above already hints at what Expanded does — it converts a loose main-axis constraint into a tight one, which is why a SizedBox inside an Expanded loses its width.

Intrinsics. Sometimes a parent genuinely needs to know how big a child would like to be before deciding what to permit — "make all these cards as tall as the tallest". That question is unanswerable in one downward pass, which is why IntrinsicHeight exists and why it is documented as expensive: it runs a speculative extra pass to ask.

Everything else follows from the sentence. It is worth resisting the urge to learn layout as a collection of widget behaviours — Center does this, Expanded does that — because the list is long and the rule is short, and each widget's behaviour is a one-line consequence of it: Center loosens, Padding deflates, Expanded tightens, SizedBox enforces, scroll views unbind their axis.

Reading a layout error

The model also tells you how to read the framework's layout errors, which are unusually informative once you know what they are describing.

A RenderBox was not laid out or an overflow message names a render object and reports the constraints it was given. That is the input, not the output — so the question it answers is "what was this thing allowed to be", and the fix is nearly always in whatever produced that constraint rather than in the widget named.

The pattern to look for in the numbers:

• An Infinity in the constraint means an unbounded axis, so an ancestor is a scroll view or an unbounded Row/Column, and a descendant tried to fill it.
• Equal min and max means tight, so a descendant's requested size was discarded and the ancestor that tightened is the one to change.
• A size larger than the constraint permitted is the overflow case, where a child insisted on more room than it was given.

None of those require understanding the widget that failed. They require finding the ancestor that set the number, which is a search up the parent chain and is exactly what the inspector's layout explorer displays.

There is one more habit worth building, and it is the cheapest diagnostic in the framework. When a size is wrong and you cannot see why, drop a LayoutBuilder directly around the widget in question and print the constraints — the same technique that produced this chapter's tables:

LayoutBuilder(builder: (context, constraints) {
  debugPrint('$constraints');
  return TheWidgetThatIsWrong();
})

Three lines, removed afterwards, and it answers the only question that matters. It works because LayoutBuilder is not an inspection tool bolted on for debugging — it is an ordinary widget that receives constraints and is given the opportunity to build differently depending on them, so printing them is just using it for its own purpose and discarding the interesting half.

The reason to prefer this over reasoning is that the parent chain in real code is rarely the one in your head. Widgets arrive from helper methods, from packages, from a Scaffold that wraps its body in things you did not write — and any one of those can be where the constraint was decided.

Common Mistakes

1. Expecting SizedBox to always win. Under tight constraints it is applied and has no effect.
2. Debugging the widget whose size is wrong. The cause is the ancestor that set the constraint.
3. Thinking Center centres by magic. It loosens the constraint, then positions the result.
4. Assuming Padding gives its child freedom. Tight in means tight out, just smaller.
5. Forgetting constraints are per-axis. Expanded can force width while leaving height loose.
6. Missing that Row and Column are unbounded on the main axis. That is the overflow chapter.
7. Expecting a widget to know where it is. Position is assigned by the parent and never travels down.
8. Reaching for IntrinsicHeight casually. It reintroduces the extra pass the model exists to avoid.
9. Reading "bounded" as "loose". A min above zero clamps upward as well as down.
10. Guessing instead of measuring. A temporary LayoutBuilder answers it in thirty seconds.

Interview Corner

Hands-on

Summary

• Constraints go down, sizes go up, the parent sets the position. The whole model.
• Measured: one SizedBox(200×100) produced four different sizes under six different parents.
• At the root it measured 800×600 — the request was applied and had no effect.
• Center loosens, which is why the same SizedBox inside one measures 200×100.
• Padding deflates but stays tight — tight in means tight out, just smaller.
• Constraints are per-axis: Expanded forces a tight width while leaving height loose.
• Tight means min equals max, and a tight constraint is not a suggestion.
• Unbounded means the child decides alone, which is where overflows come from.
• A widget never knows its position — that is assigned by the parent after sizes are known.
• Diagnose upward. The wrong size is caused by the ancestor that chose the constraint.

Next: Row, Column and Flex — the multi-child case, where Expanded and Flexible decide how a shared axis is divided, measured against the real engine.