Feste vs. fluide Spalten

Nimm eine Seite, die du für gut gebaut hältst, und zieh das Browserfenster langsam von breit nach schmal. Achte darauf, was sich bewegt. Die Spalten stauchen sich zusammen und schlucken jeden Pixel, den du wegnimmst — aber die Stege dazwischen bleiben stehen, und die Ränder an den Kanten ebenso. Dann, irgendwo bei einer gerätegroßen Breite, schnappt das Layout um: aus zwölf Spalten werden acht, und die Stauchung beginnt von einer breiteren Spalte aus von vorn. Dieser Rhythmus aus langsamem Flexen und plötzlichem Umschnappen ist die Frage fest vs. fluid — und sie ist bereits beantwortet.

In dem Rastermodell, das die meisten modernen Layouts verwenden, sind die Spalten fluid — 1fr-Tracks, die Änderungen des Viewports aufnehmen — während Stege und Ränder innerhalb jeder Breakpoint-Stufe fest bleiben. Ein festes vs. fluides Raster ist deshalb selten eine Entweder-oder-Entscheidung: Die praktische Frage ist, welche der drei Breiten flext, und die übliche Antwort lautet: nur die Spalten.

Dieser Artikel behandelt diese Arbeitsteilung, die zwei ehrlichen Alternativen an den Extremen — alles fest, alles fluid — und wie fluide Spalten mit Breakpoints zusammenspielen, mit den Zahlen einer Stufe, berechnet an beiden Enden ihres Bereichs. Es ist die Ebene der Design-Entscheidungen des Layout-Rasters; das CSS, das sie umsetzt, wohnt an anderer Stelle im Cluster.

Welche Teile eines Rasters sollten flexen?

Ein Raster besteht aus drei Breiten — Spalten, Stege, Ränder — und sie verdienen unterschiedliche Behandlung, weil sie unterschiedliche Aufgaben erfüllen.

Stege fest. Der Steg ist Rhythmus: das wiederkehrende Intervall, das Spalten als eine Familie lesbar macht. Lässt du die Stege mit dem Viewport skalieren, atmen die Abstände zwischen allem unvorhersehbar — dieselben zwei Spalten liegen auf einem Bildschirm 24px auseinander und auf einem anderen 31px, und das Abstands-System der Seite hört klammheimlich auf, ein System zu sein. Abstände liegen nah an der Identität: Sie sind eines der Dinge, an denen ein Leser ein Layout wiedererkennt, also bleiben sie stehen.

Ränder fest pro Stufe. Der Rand ist der Rahmen. Ein Rahmen, der kontinuierlich wächst und schrumpft, wirkt wie Instabilität an der Seitenkante; ein Rahmen, der auf Smartphones bei 16px hält und bei bekannten Breiten hochstuft, wirkt wie ein bewusstes Passepartout um den Inhalt.

Spalten fluid. In den Spalten wohnt der Inhalt, und Inhaltsflächen sind auf eine Weise elastisch, wie es Abstände nicht sind — ein Absatz liest sich bei 68px mehr Breite kaum anders, aber ein sichtbar wackelnder Steg fällt auf. Also nehmen die Spalten die gesamte Veränderung auf: Die festen Bestandteile werden oben abgezogen, und 1fr-Tracks teilen sich, was übrig bleibt. Fluid bedeutete früher Prozent-Arithmetik von Hand — Spaltenbreiten als mühsam errungene Dezimalzahlen wie 8,333%. Die fr-Einheit hat diese Arithmetik in den Browser verlagert, der die Rest-Division nun live bei jeder Viewport-Breite ausführt.

Wie sieht ein vollständig festes Raster aus?

Die vom Druck abstammende Alternative: Spalten, Stege und Ränder alle fest, die gesamte Fläche eine bekannte Größe, und die überschüssige Breite des Viewports wird durch Zentrieren in die äußeren Ränder gekippt. So funktionierten frühe Web-Layouts (die 960px-Ära), und sie überlebt dort, wo ihre Tugenden weiter gelten — Dokumente, Lese-Apps, alles, dessen Ideal „jedes Mal dieselbe Seite” ist. Ein festes Maß ist für lange Texte wirklich gut: Die Zeilenlänge driftet nie aus dem angenehmen Bereich.

Der Preis ist der Raum zwischen den Breakpoints. Bei einem 1100px-Viewport lässt ein festes 960px-Layout 140px toten Rand übrig, den weder Inhalt noch Rahmen nutzt; jeder Viewport zwischen zwei Design-Größen bekommt das kleinere Design plus Verschnitt. Feste Raster tauschen Anpassung gegen Gewissheit ein, und der Tausch wirkt nur dort fair, wo Gewissheit das Produkt ist.

Wie sieht ein vollständig fluides Raster aus?

Das entgegengesetzte Extrem entfernt die Container-Begrenzung vollständig: Die Spalten flexen bei jeder Breite ohne obere Grenze. Dashboards, Tabellen, Editoren und andere datendichte Anwendungen nutzen die Breite tatsächlich — ein 2560px-Monitor, der mehr Spalten eines Log-Viewers zeigt, ist ein Feature, und eine Begrenzung würde die buchstäblichste Ressource des Nutzers verschwenden: Pixel.

Die Kosten zeigen sich, sobald Text ins Spiel kommt: unbegrenzte Spalten bedeuten unbegrenzte Zeilenlängen, und Bedienelemente, die zusammengehören, driften auseinander, während sich der Raum zwischen ihnen dehnt. Ob man begrenzt, ist in einem Satz die Achse App vs. Dokument — Oberflächen, die Breite nutzen, bleiben unbegrenzt, Seiten, die gelesen werden, bekommen einen Container — und die Größe des Containers selbst ist ein eigenes Thema.

Wie spielen fluide Spalten mit Breakpoints zusammen?

Der standardmäßige responsive Rhythmus ist die Kombination der beiden Mechanismen: Spalten flexen zwischen Breakpoints, die Spaltenanzahl ändert sich an ihnen. Innerhalb einer Stufe teilt der Browser die übrige Breite kontinuierlich neu auf; an der Stufengrenze wird die angesammelte Breite in mehr Spalten reinvestiert, und jede Spalte setzt sich auf eine schmalere Breite zurück. Flexen, umschnappen, flexen.

Die Raster-Ansicht von Scale Composer macht das „Dazwischen” sichtbar, weil jeder Breakpoint zwei Breiten hat: die min-width, bei der die Stufe beginnt, und eine Vorschaubreite, die du irgendwo innerhalb des Stufenbereichs setzen kannst. Die standardmäßige Tablet-Stufe reicht von 768px bis 1199px — jede Breite in diesem Band ist dasselbe achtspaltige Raster, nur mit breiteren oder schmaleren Spalten.

Skaliere die Tablet-Stufe über ihren gesamten Bereich in Scale Composer — dieselben Spalten, dieselben 24px-Stege, dieselben 29px-Ränder; nur die Spaltenbreite bewegt sich.

Wie stark flext eine Spalte tatsächlich?

Nimm die standardmäßige Tablet-Stufe — 8 Spalten, 24px-Stege, 29px-Ränder — und berechne die Spaltenbreite an beiden Enden ihres Bereichs von 768–1199px. Die festen Bestandteile werden oben abgezogen: Ränder 2 × 29 = 58px, Stege 7 × 24 = 168px, also teilen sich die Spalten das, was der Viewport übrig lässt.

Eine Tablet-Spalte verdoppelt sich über ihre eigene Stufe fast — ≈67,8px bis ≈121,6px — während jeder Steg und jeder Rand auf den Pixel genau hält. Dann trifft die Desktop-Grenze ein und die Arithmetik setzt zurück: zwölf Spalten, breitere Ränder, und die Spaltenbreite schnappt zurück auf 67px. Das Flexen nimmt auf; das Umschnappen reinvestiert. Das ist der gesamte responsive Rhythmus in einer Tabelle.

Schalte die Begrenzung ab und spür den Unterschied

Die letzte Entscheidung — begrenztes Dokument oder unbegrenzte App — fällt leichter, nachdem man beide auf demselben Raster gesehen hat. Die maximale Container-Breite in der Raster-Ansicht lässt sich abschalten: eingeschaltet hört die Desktop-Stufe bei 1200px auf zu wachsen und die Ränder übernehmen; ausgeschaltet flexen die zwölf Spalten so breit weiter, wie das Fenster geht. Schalte die Container-Begrenzung auf demselben Raster in Scale Composer um.