Breakpoints: Inhalt statt Geräte

Suchst du nach einem Breakpoint-Spickzettel, findest du Viewport-Breiten, die nach Hardware benannt sind: iPhone, iPad, Laptop, Desktop. Solche Tabellen verrotten mit jedem Produktzyklus, und sie stimmten selbst frisch nie ganz — echte Geräte decken heute nahezu jede Breite ab 320px aufwärts ab. Die berühmteste Zahl darauf bringt es auf den Punkt: 768px ist das klassische iPad, das seinen Hochkant-Viewport meldet, 768 × 1024 CSS-Pixel. Dieses Gerät ist Museumshardware; die Zahl steckt noch immer in einem großen Teil der Stylesheets dieser Welt. Die Konvention hat ihr Gerät überlebt.

Ein CSS-Breakpoint ist eine Viewport-Breite, bei der sich das Layout ändert — und der langlebige Weg, einen zu setzen, führt dorthin, wo der Inhalt versagt, nicht dorthin, wo eine Geräte-Tabelle hinzeigt: wo die Zeilenlänge ihr lesbares Band verlässt, wo eine Seitenleiste den Inhalt daneben aushungert, wo Cards unter eine nutzbare Breite gequetscht werden. Dieser Beitrag — Teil unseres Leitfadens zum Layout-Raster — arbeitet diese Versagenssignale durch, erklärt, warum fast standardmäßige Werte meist trotzdem taugen, und wie Breakpoints als Tokens ausgeliefert werden.

Warum nicht einfach für Geräte gestalten?

Drei Gründe. Die Tabelle ist instabil: Jeder Produktzyklus fügt Breiten hinzu, und ein nach einem Gerät benannter Breakpoint erbt dieses ständige Nachwachsen. Die Media Query kannte das Gerät ohnehin nie — sie hat immer nur den Viewport gemessen, „iPad” war also stets eine höfliche Fiktion für „768px breit”. Und echte Fenster leben zwischen den Einträgen der Tabelle: Tablets im Split-Screen, verkleinerte Desktop-Fenster, Faltdisplays. Ein Layout, das nur bei den Breiten der Tabelle geprüft wurde, kann dazwischen trotzdem versagen; ein Layout, das nach seinen eigenen Versagenspunkten gesetzt ist, kann das nicht, denn die Versagenspunkte sind die Definition.

Wohin gehört ein Breakpoint?

Dorthin, wo ein Layout sichtbar aufhört zu funktionieren. Drei Versagenssignale decken die meisten Seiten ab, jedes mit einem beobachtbaren Symptom:

• Die Zeilenlänge verlässt das Band. Der Fließtext läuft über rund 75 Zeichen pro Zeile hinaus, und das Auge verpasst zunehmend den Rücksprung zur nächsten Zeile — erneut gelesene Zeilen, übersprungene Zeilen. Der Stopp gehört dorthin, wo die Textspalte ihr Budget überschreiten würde.
• Die Seitenleiste hungert den Inhalt aus. Seitenleiste und Inhalt zu lange nebeneinander zu halten quetscht die Inhaltsspalte unter das, was sie braucht, während die Seitenleiste bequem sitzt. Der Stopp gehört dorthin, wo das Nebeneinander erstmals beide Spalten nutzbar lässt.
• Die Cards werden gequetscht. Eine zu lange gehaltene Card-Reihe beschneidet ihre Titel und bricht ihre Buttons um — Cards unter rund 250–280px erfüllen ihre Aufgabe nicht mehr. Der Stopp gehört dorthin, wo die nächste Card in voller Arbeitsbreite passt.

Jedes Symptom benennt seine eigene Lösung, und der Breakpoint ist einfach die Breite, bei der die Lösung einsetzt.

Wie sieht ein inhaltsgetriebenes Audit aus?

Nimm eine Seite mit allen drei Zutaten — eine Artikelspalte, eine Feature-Reihe aus drei Cards, eine Seitenleiste — gesetzt in 16px-Fließtext, wo ein durchschnittliches Zeichen ≈8px einnimmt:

Zwei ehrliche Lesarten folgen daraus. Erstens landet das Audit ohnehin nahe an den Standard-Stopps — 768 deckt den Text ab (kommt etwas spät; zwischen ≈632 und 768 laufen die Zeilen leicht über, was du hinnehmen oder mit einem max-width auf der Spalte lösen kannst, das eine Versagen, das ein Deckel ohne Breakpoint behebt). Zweitens bekommt die Card-Reihe keinen eigenen Stopp: Drei nebeneinander werden bei ≈886px möglich, aber dort versagt nichts — zwei nebeneinander bleiben bis 1200 bequem. Möglich ist nicht dasselbe wie nötig.

Warum halten sich Standard-Breakpoints trotzdem?

Weil Ökosysteme konvergieren. Frameworks bündeln ihre Standardwerte nahe 640, 768, 1024 und 1280; Teams erben diese Werte, Tooling und Test-Setups setzen sie voraus, und Designer skizzieren daran. Und das ist meist in Ordnung — Inhalts-Toleranzen sind Bereiche, keine Punkte. Ein Layout, dessen echtes Versagen bei 730px liegt, ist mit einem Stopp bei 768 bestens bedient.

Die Ehrlichkeit gilt in beide Richtungen. Mach aus eigenen Breakpoints keinen Fetisch: Der Gewinn gegenüber fast standardmäßigen Werten ist meist klein, und ein maßgeschneiderter 743px-Stopp bringt vor allem Erklärungsaufwand. Aber behandle die Standards auch nicht als Physik: Das Inhaltsprinzip verdient sich seinen Platz genau dann, wenn ein Layout wirklich zwischen den Standard-Stopps versagt — das ist der Moment, in dem du berechtigt bist, einen zu verschieben.

Sollten Media Queries min-width oder max-width sein?

Mobile-first — die Basis-Styles bedienen die schmalste Stufe, und jede min-width-Query fügt hinzu, was eine breitere Stufe verdient — ist zum modernen Standard geworden, und zwar aus einem strukturellen Grund: Das schmale Layout ist meist das einfache (eine einzelne Spalte), also bleibt der Basisfall sauber und breitere Stufen sind additiv statt subtraktiv.

.cards {
  display: grid;
  grid-template-columns: 1fr;   /* mobil: eine Spalte */
  gap: 16px;
}
@media (min-width: 768px) {
  .cards { grid-template-columns: repeat(2, 1fr); gap: 24px; }
}
@media (min-width: 1200px) {
  .cards { grid-template-columns: repeat(3, 1fr); }
}

Jeder min-width-Guard ist der Einstiegspunkt einer Stufe; die vollständige Query-Syntax, samt der neueren Range-Formen wie (768px <= width < 1200px), findest du in MDNs @media-Referenz.

Wie werden Breakpoints zu design tokens?

Breakpoints sind Entscheidungen, und Entscheidungen driften, wenn sie nur in Stylesheets leben — ein Projekt bei 768, sein Geschwister bei 780, niemand erinnert sich warum. Behandelt man sie als Tokens, landen sie in derselben Pipeline wie Farbe und Schrift: In Scale Composer besitzt die Raster-Ansicht den Layout-Abschnitt des DTCG-Exports, in dem jeder Breakpoint seine min-width, Spalten, Spaltenbreite, seinen Steg und Rand mitliefert, neben der gemeinsamen Container-Maximalbreite. Ändere eine Stufe einmal, und jeder Konsument der Token-Datei sieht es. Der Figma-Export trägt dieselbe Struktur als Grid-Collection mit einem Modus pro Breakpoint, sodass ein Designer die Stufen so wechselt, wie er zwischen Hell und Dunkel wechseln würde.

Sieh dir die drei Stufen als Layout-Tokens in Scale Composer an — das Export-Panel der Raster-Ansicht zeigt die Werte jedes Breakpoints neben dem Raster, das sie erzeugt.

Wie viele Breakpoints brauchst du?

Drei Stufen decken die meisten Produkte ab — das Audit oben brauchte zwei Stopps für drei Versagenssignale. Eine vierte verdient ihren Platz nur, wenn ein echtes Layout zwischen den bestehenden Stopps versagt, und das Audit zeigt die Disziplin im Kleinen: Drei Cards nebeneinander passen ab ≈886px, aber bei 886 versagte nichts, also keine Stufe. Benenne das versagende Layout, berechne die Breite, bei der es versagt, und erst dann — füge in Scale Composer eine vierte Stufe mit eigener Spaltenzahl hinzu.