Container-Maximalbreite wählen

Mach eine kleine Messung, bevor es zur Theorie geht. Öffne eine textlastige Seite, der du vertraust — eine Zeitung, eine Dokumentationsseite, ein Longform-Magazin — auf dem breitesten Monitor, den du hast, und zieh das Browserfenster langsam von schmal auf volle Breite. Das Layout wächst eine Weile mit dem Fenster mit, und dann, irgendwo jenseits von 1100px, hört es auf: Die Spalten frieren ein, und jedes weitere Pixel Fensterbreite fließt in die leeren Ränder auf beiden Seiten. Miss ein paar Seiten mit dem Lineal der devtools, und die Haltepunkte häufen sich — die meisten landen zwischen 1100 und 1400px.

Dieser Haltepunkt ist die Container-Maximalbreite: die Obergrenze dafür, wie breit ein Layout wachsen darf. Unterhalb der Grenze ist das Raster fluid und nimmt den Viewport auf; jenseits davon halten die Spalten ihre Größe, die Seite läuft zentriert, und die Ränder nehmen alles Übrige auf. Es ist eine einzige Zahl, die jedes Layout im System deckelt, und dieser Artikel — Teil unseres Leitfadens zum Layout-Raster — erklärt, warum die Grenze existiert, woher die gängigen Werte kommen und wann man sie abschaltet.

Was macht eine Container-Maximalbreite eigentlich?

Sie teilt den Viewport-Bereich in zwei Regime. Unterhalb der Grenze teilen sich die Spalten des Rasters die Breite, die das Fenster hergibt — das fluide Regime, in dem Layout und Viewport dasselbe sind. Oberhalb der Grenze löst sich das Layout vom Fenster: Das Raster hält seine entworfene Breite, sitzt zentriert, und das Wachsen übernehmen die Ränder. In CSS ist das gesamte Muster max-width plus automatische Inline-Ränder:

.container {
  max-width: 1200px;    /* die Grenze */
  margin-inline: auto;  /* zentriert die gedeckelte Seite */
  padding-inline: 66px; /* die äußeren Ränder des Rasters */
}

Die Wahl von max-width statt width ist es, die beide Regime mit einer einzigen Eigenschaft erkauft: Ein festes width: 1200px würde kleine Bildschirme überlaufen, während max-width erst greift, sobald das Fenster es überschreitet.

Warum das Layout überhaupt deckeln?

Drei Gründe, in absteigender Stärke.

Zeilenlänge. Fließtext liest sich am besten bei etwa 45–75 Zeichen pro Zeile — dem seit Langem etablierten typografischen Band — und eine ungedeckelte Spalte ignoriert dieses Budget vollständig: Auf einem 2560px-Monitor läuft ein Absatz über die volle Breite bei 16px auf ungefähr (2560 − 132) ÷ 8 ≈ 300 Zeichen pro Zeile, ein Vielfaches über der Obergrenze des Bandes. Das ist der Fehler, der Deckelungen für alles, was gelesen werden soll, unverzichtbar macht.

Interaktionsdistanz. Zusammengehörige Bedienelemente driften auseinander, während sich das Layout dehnt: Ein Filterpanel, das am linken Rand verankert ist, und die Ergebnisse, die es steuert und die nach rechts wandern, können auf einem Ultrawide-Display mehr als einen halben Bildschirm auseinanderliegen — und jeder Blick zwischen ihnen wird zu einer Kopf- statt einer Augenbewegung.

Komposition. Ein bei 1200px entworfenes Layout behält seine Proportionen bei 2400 nicht: Das Bild-zu-Text-Verhältnis des Heros, die Beziehungen des Weißraums, das visuelle Gewicht einer Kartenreihe — alles dehnt sich aus den Verhältnissen heraus, in denen es entworfen wurde. Die Grenze ist das, was eine Komposition die Komposition bleiben lässt.

Woher kommen die gängigen Werte?

Der Bereich von 1100–1400px dominiert, weil dort zwölf Spalten lesbarer Textbreite plus ihre Stege und Ränder eben landen. Du kannst die Rechnung rückwärts laufen lassen und zusehen, wie sich die Konvention von selbst zusammensetzt.

Fang beim Text an. Longform-Fließtext wird üblicherweise um die 18–21px gesetzt; bei 21px belegt ein durchschnittliches Zeichen ≈10,5px, sodass eine Zeile mit 66 Zeichen — das klassische bequeme Maß — eine Spalte von ≈693px braucht. Gib dieser Artikelspalte 8 der 12 Spalten des Rasters. Bei 24px-Stegen muss die Spannweite 8 × Spaltenbreite + 7 × 24 ≈ 696px erfüllen, was sich zu einer Spaltenbreite von 66px auflöst. Jetzt summiere das ganze Raster bei den Desktop-Standardwerten von Scale Composer:

12 × 66  (Spalten)  =  792px
11 × 24  (Stege)    =  264px
 2 × 66  (Ränder)   =  132px
                       ──────
Raster gesamt       = 1188px  ≈ die 1200px-Konvention

Kleinere Schriftgrößen verschieben die Spannweiten, nicht die Schlussfolgerung — bei 16px ist eine Spalte mit 66 Zeichen ≈528px, nahe an einer 6-von-12-Spannweite (≈516px). So oder so landet die Grenze in derselben Gegend, weil sie dieselbe Frage beantwortet: Die Container-Maximalbreite ist die Breite, bei der einem 12-Spalten-Raster voller lesbarem Text die Gründe zum Wachsen ausgehen. Der Bereich von 1100–1400px ist keine Mode; er ist genau diese Rechnung, ausgewertet mit unterschiedlichen Schriftgrößen und Stegen.

Öffne die Anatomie des 1200px-Containers in Scale Composer — die Container-Maximalbreite ist ein einziger globaler Wert über alle Breakpoints hinweg, und die zwölf 66px-Spalten des Desktop-Tiers mit 24px-Stegen und 66px-Rändern ergeben zusammen 1188px darin.

Wann sollte ein Layout nicht gedeckelt sein?

Zwei etablierte Ausnahmen, eine partielle und eine totale.

Full-Bleed-Abschnitte. Heroes, Medienbänder und randlose Farbflächen brechen aus dem Container aus — aber ihr Inhalt bleibt darin. Das Muster ist ein äußerer Abschnitt ohne max-width, der den Hintergrund trägt, und ein innerer Container, gedeckelt und zentriert, der Text und Bedienelemente trägt:

.band {
  /* full-bleed: Hintergrund und Bilder laufen von Rand zu Rand */
}
.band > .container {
  max-width: 1200px;    /* der Inhalt darin bleibt gedeckelt */
  margin-inline: auto;
  padding-inline: 66px;
}

Das Band bekommt die Dramatik des vollen Viewports; die Überschrift darin richtet sich trotzdem an jedem anderen gedeckelten Abschnitt der Seite aus.

Datendichte Anwendungen. Dashboards, Datentabellen und Editoren nutzen Breite wirklich — 400px mehr sind eine weitere sichtbare Datenspalte, eine weitere Stunde auf der Timeline. Eine brauchbare Faustregel, angeboten als genau das: Dokumente werden gelesen, Anwendungen werden bedient — Lesen braucht die Grenze, Bedienen oft nicht. Viele Produkte sind ehrlich gesagt beides und finden den Mittelweg: Marketing- und Doku-Seiten gedeckelt, die App-Oberfläche fluid.

Schalte die Grenze ab und schau zu

Der Unterschied wird am schnellsten begreifbar, wenn du ihn umschaltest. In Scale Composer ist der Container eine einzige globale max-width, und sie lässt sich komplett deaktivieren — der Fall des fluiden Layouts. Schalte sie ab und schau zu, wie das Desktop-Raster die gesamte Vorschau beansprucht: Die Spalten dehnen sich, die Rastersumme jagt dem Viewport hinterher, und die Textspannweiten, die fürs Lesen dimensioniert waren, laufen über ihr Band hinaus — schalte den Container ab und sieh zu, wie das Raster fluid wird.