Die Falle der vw-Einheit

Die Überschrift ging als font-size: 8vw in Produktion und sah auf dem Handy, für das sie gestaltet wurde, hervorragend aus — ≈31px auf einem 390px-Bildschirm, selbstbewusst und perfekt proportional. Der erste Screenshot von einem Büromonitor erzählte eine andere Geschichte: bei 1920px wurde dieselbe Überschrift mit ≈154px gerendert, sechs Wörter als Wand aus Text, und auf breiteren Monitoren wuchs sie immer weiter. Nichts war kaputt — in dem Sinne, dass der Browser genau das tat, was man ihm gesagt hatte. Das ist die vw-Falle in einem Satz: die Einheit tut genau eine Sache, und sie hört nie damit auf.

Nackte Viewport-Einheiten scheitern als Schriftgrößen aus vier mechanischen Gründen: vw hat keine Grenzen, es ignoriert sowohl den Browser-Zoom als auch die Schriftgrößen-Einstellungen (ein WCAG-1.4.4-Verstoß), es verschmilzt Größe und Wachstumsrate zu einer einzigen Zahl, und wenn Schrift und Abstände alle mit dem Viewport skalieren, ist nichts auf der Seite verankert. Die Standardlösung ist clamp() mit einem Ausdruck aus rem + vw; nacktes vw verdient nur bei Display-Text über den vollen Viewport mit einem rem-Boden einen Platz.

Dieser Leitfaden ist die Warnung in unserem Leitfaden zur fluiden Typografie — was schiefgeht, bei echten Breiten berechnet, und die Leiter der Lösungen.

Warum wird vw-Schriftgröße immer wieder geschrieben?

Weil die Verführung echt ist. Eine Deklaration — font-size: 4vw — und der Text ist perfekt proportional zum Bildschirm: keine Media Queries, keine Stufen, keine Tabellen mit Größen. Ein vw ist 1 % der Viewport-Breite (die Mechanik erklärt web.devs Leitfaden zu Viewport-Einheiten), 4vw liest sich also als „Text, der immer 4 % des Bildschirms einnimmt” — was genau danach klingt, was responsive Typografie sein sollte. Jedes Versagen weiter unten ist genau diese Eigenschaft aus einem anderen Blickwinkel betrachtet: die perfekte Proportionalität ist das Problem.

Was geht bei reinen vw-Schriftgrößen kaputt?

1. Keine Grenzen. 4vw sind ≈14px bei einem 360px-Viewport und ≈77px bei 1920px — beides aus derselben Deklaration. Es gibt keinen Boden unter der Lesbarkeit auf kleinen Bildschirmen und keine Decke über der Absurdität auf großen. Über die anderen Versagen lässt sich streiten; dieses ist reine Arithmetik.

2. Zoom-taub. Der Browser-Zoom skaliert das CSS-Pixel, was px- und rem-basierten Text skaliert — aber die CSS-Breite des Viewports schrumpft um denselben Faktor, sodass sich eine vw-basierte Größe auf dieselbe physische Größe neu berechnet. Auf 200 % gezoomt wächst reiner vw-Text überhaupt nicht, und er ignoriert aus demselben Grund die Schriftgrößen-Einstellung des Browsers. Das verstößt gegen WCAG 1.4.4. (Die vollständige Zoom-Arithmetik von rem gegenüber vw ist ein eigenes Thema; die Kurzfassung lautet: nur der rem-Anteil einer fluiden Größe reagiert auf Zoom.)

3. Steigungs-Sperre. Mit nacktem vw sind die Größe bei einer bestimmten Breite und die Wachstumsrate dieselbe Zahl. Du willst Fließtext mit 16px auf einem 360px-Handy? Das sind 16 / 360 × 100 ≈ 4,44vw. Aber 4,44vw wächst für jedes zusätzliche Viewport-Pixel mit derselben Rate weiter und landet bei ≈85px bei 1920px. Du kannst nicht sagen „16px auf Handys und von dort aus sanft nach oben” — die Wahl der Größe hat die Steigung gewählt, und die Steigung ist wild.

4. Alles proportional, nichts verankert. Dieselbe Logik wird dann auf Innenabstände und Ränder angewendet („sie skalieren, also passen sie zusammen”), und die Seite wird zum Maßstabsmodell: bei jeder Breite dasselbe Plakat, aus näherer oder größerer Entfernung fotografiert. Die Proportionen von Text zu Raum passen sich nie an, die Informationsdichte steigt auf größeren Bildschirmen nie — ein Desktop-Monitor zeigt das Handy-Layout, vergrößert. Eine Seite, auf der alles proportional zum Viewport ist, ist von einem gezoomten Handy-Design nicht zu unterscheiden.

Was rendert 4vw eigentlich?

Die Tabelle, die den Fall belegt — nacktes 4vw gegen ein begrenztes clamp, das für dieselbe Aufgabe gebaut wurde (eine Display-Überschrift, die auf Handys ≈28px groß sein und bei 48px gedeckelt werden soll):

Dort, wo die beiden Spalten grob übereinstimmen — irgendwo im oberen 700er-Bereich — liegt genau die Art von Breite, bei der 4vw während der Entwicklung in irgendjemandes Browser „richtig aussah”. Überall sonst laufen sie auseinander, und die clamp-Spalte ist diejenige, die eine Designerin in jeder Zeile abnicken würde.

Die zweite Spalte, live: öffne ein begrenztes fluides Setup in Scale Composer — der fluide Modus wird durch vier Zahlen definiert (die Basis bei vp-min, die Basis bei vp-max und die beiden Viewports), und der CSS-Export schreibt jeden fluiden Wert als clamp mit seinem echten Pixelbereich in einem Kommentar: die Grenzen, die 4vw nie hatte, explizit gemacht.

Wie behebt clamp() jedes Versagen?

Die Lösungen stapeln sich, eine pro Versagen:

• Grenzen: clamp(min, …, max) stellt einen Boden und eine Decke wieder her — die Desaster auf kleinen und riesigen Bildschirmen werden zu den zwei flachen Zonen der Kurve.
• Zoom: der bevorzugte Ausdruck mischt rem mit vw. Im clamp der Tabelle stammt der Großteil der Größe im mittleren Bereich aus dem rem-Term, sodass der Zoom den Großteil des Texts erreicht.
• Steigung: Achsenabschnitt und Steigung sind zwei unabhängige Zahlen. „16px bei 360px und ein sanfter Anstieg” ist jetzt ausdrückbar: der rem-Term setzt den Anker, der vw-Term setzt die Rate.
• Verankerung: die Root-clamp-Architektur — ein fluides clamp auf der Root-Schriftgröße, alles andere in rem, das darauf reitet — skaliert Schrift und Abstände auf einer gemeinsamen Steigung, während Rahmen und feine Geometrie in px bleiben. Die Seite atmet; sie zoomt nicht.

Wann sind Viewport-Einheiten für Schriftgrößen legitim?

Eine einzige Ausnahme, präzise formuliert: Display-Text über den vollen Viewport — eine Hero-Zeile, eine Plakat-Zahl — bei dem plakatartige Skalierung die eigentliche Gestaltungsabsicht ist, und nur mit einem rem-Boden:

font-size: max(2rem, 6vw);

Das max() garantiert, dass der Text nie unter 2rem gerendert wird, und bei tiefem Zoom übergibt der schrumpfende CSS-Viewport die Kontrolle an den rem-Boden, sodass der Text nicht dauerhaft zoom-taub ist. Über den normalen Bereich skaliert er weiterhin wie ein Plakat — was hier der Sinn ist. Dieser Kompromiss ist für ein paar Display-Wörter vertretbar; er ist ein schlechter Kompromiss für Überschriften im Fließtext und gar kein Kompromiss für Fließtext.

Ersetze die Zahl, die zwei Aufgaben hatte

Nimm die Lehre der Tabelle mit ins Werkzeug: lade das begrenzte Setup und ändere jeweils einen Parameter — erhöhe die Basis bei vp-max und beobachte, wie die Pixelbereich-Kommentare des Exports folgen, während der Boden stehen bleibt. Dass Größe und Steigung sich unabhängig voneinander bewegen, ist die gesamte Reparatur: 4vw war eine Zahl mit zwei Aufgaben, und clamp() ist die Degradierung, die sie brauchte.