text-box-trim: Überflüssigen Zeilenabstand präzise entfernen

1. Das Problem: unsichtbarer Leerraum über und unter jedem Textblock

Wer schon einmal versucht hat, eine Headline oder einen Button-Text pixelgenau vertikal zu zentrieren, kennt das Phänomen: Egal wie sorgfältig padding und line-height gesetzt werden, der Text wirkt immer einen Hauch zu hoch oder zu tief. Der Grund liegt nicht im eigenen CSS, sondern in der Schriftart selbst, die für jede Zeile mehr vertikalen Platz reserviert, als die sichtbaren Buchstaben tatsächlich brauchen.

Dieser Platz heißt in der Typografie Leading und verteilt sich standardmäßig zur Hälfte über und zur Hälfte unter die Zeile. Bei einer einzelnen Textzeile in einem Button oder einer kurzen Headline summiert sich dieser Überschuss schnell zu mehreren Pixeln sichtbarem Abstand, der optisch wie eine falsche Zentrierung wirkt, obwohl das CSS technisch korrekt ist. Früher halfen nur negative Margins, die bei jedem Font-Wechsel neu ausgemessen werden mussten.

2. Font-Metriken verstehen: Ascent, Descent und Cap-Height

Jede Schriftdatei bringt eigene Metriken mit, die der Browser zur Berechnung der Zeilenhöhe nutzt: den Ascent (Höhe über der Grundlinie bis zur höchsten Oberlänge), den Descent (Tiefe unter der Grundlinie bis zur tiefsten Unterlänge) und den Line-Gap, einen zusätzlichen Puffer, den viele Schriftgestalter großzügig bemessen, damit mehrzeiliger Text nicht zu eng wirkt. Zusammen ergeben diese drei Werte die Standard-Zeilenhöhe einer Schrift.

Für einzeilige UI-Elemente wie Buttons oder Badges ist genau dieser Line-Gap-Puffer unerwünscht, weil er Platz reserviert, der visuell nie gebraucht wird. Die Cap-Height, also die Höhe eines Großbuchstabens wie H, liegt dagegen deutlich näher an dem, was das menschliche Auge als tatsächliche Texthöhe wahrnimmt. Genau diese Differenz zwischen technischer Zeilenhöhe und wahrgenommener Texthöhe ist es, die text-box-trim adressiert.

3. Warum Design-Tools wie Figma Text anders messen als der Browser

Design-Tools wie Figma zeigen einen Textrahmen standardmäßig sehr eng an der Cap-Height und der Baseline an, ohne den vollen Line-Gap-Puffer der Schriftart einzurechnen. Ein Entwickler, der ein Figma-Design pixelgenau nachbaut, erlebt deshalb regelmäßig, dass der Browser-Text spürbar mehr vertikalen Raum einnimmt als im Design-File, obwohl Schriftgröße und Zeilenhöhe identisch übernommen wurden. Das ist kein Bug, sondern ein grundsätzlich anderes Messverfahren.

Figma misst Text nach den sogenannten Font-Bounding-Box-Werten der Schrift, die oft enger sind als die für den Browser vorgeschriebene CSS-Zeilenhöhe. Diese Diskrepanz war lange eine der häufigsten Quellen für Design-Development-Reibung bei Design-Handoffs. text-box-trim schließt diese Lücke, weil es dem Browser erlaubt, sich gezielt an denselben Bezugslinien zu orientieren, die Design-Tools ohnehin schon für die Anzeige verwenden.

4. Die Property text-box-trim: trim-start, trim-end, trim-both

Die Property text-box-trim legt fest, an welcher Seite eines Textblocks der überschüssige Leading-Raum entfernt wird. Der Wert trim-start kappt den Raum oberhalb der ersten Zeile, trim-end den Raum unterhalb der letzten Zeile, und trim-both entfernt beides gleichzeitig. Der Standardwert none verhält sich wie bisher und ändert nichts am gewohnten Verhalten.

Wichtig ist, dass text-box-trim nur an den Außenkanten des gesamten Textblocks wirkt, nicht zwischen einzelnen Zeilen eines mehrzeiligen Absatzes. Der Zeilenabstand innerhalb eines Fließtexts bleibt also unverändert, nur der erste und letzte sichtbare Rand des Blocks wird beschnitten. Das macht die Property gezielt für Container nutzbar, bei denen die Außenmaße exakt zum Text passen sollen, ohne die Lesbarkeit mehrzeiliger Absätze zu beeinträchtigen.

/* Grundsyntax: Leading oben UND unten entfernen */
.card-headline {
  text-box-trim: trim-both;
  text-box-edge: cap alphabetic;
}

/* Nur oben trimmen, z. B. wenn darunter noch Zeilenabstand
   zum naechsten Element gewuenscht ist */
.section-title {
  text-box-trim: trim-start;
  text-box-edge: cap text;
}

/* Kurzschreibweise: text-box kombiniert trim und edge */
.hero-title {
  text-box: trim-both cap alphabetic;
}

5. text-box-edge: cap, ex, text und alphabetic als Bezugslinie

Während text-box-trim festlegt, welche Seite beschnitten wird, bestimmt text-box-edge, bis zu welcher Bezugslinie geschnitten wird. Der Wert cap schneidet oben bis zur Oberkante der Großbuchstaben, ex bis zur Oberkante der Kleinbuchstaben wie x, und text orientiert sich an der vollen, von der Schriftart definierten Textgrenze inklusive Akzentzeichen.

Am unteren Ende ist alphabetic der gebräuchlichste Wert, weil er exakt an der Grundlinie endet und Unterlängen wie bei g oder y bewusst nicht mit einrechnet. Die beiden Werte werden als Paar angegeben, ein Wert für oben und einer für unten, zum Beispiel text-box-edge: cap alphabetic. Wird nur ein Wert angegeben, gilt er für beide Seiten gleichermaßen.

/* Vergleich verschiedener Edge-Kombinationen an derselben Headline */
.edge-cap-alphabetic {
  text-box-trim: trim-both;
  text-box-edge: cap alphabetic; /* engster, praezisester Schnitt */
}

.edge-ex-text {
  text-box-trim: trim-both;
  text-box-edge: ex text; /* etwas grosszuegiger, sicherer bei Akzenten */
}

/* Fuer mehrsprachigen Content mit Umlauten und diakritischen
   Zeichen ist "text" als obere Kante die sicherere Wahl */
.headline-de-fr {
  text-box-trim: trim-start;
  text-box-edge: text;
}

6. Praxis: Buttons mit exakt zentriertem Text

Buttons sind der klassische Anwendungsfall, weil ihr vertikales Padding oben und unten meist identisch gesetzt wird, der Text aber wegen des Leading-Überhangs trotzdem leicht nach oben verschoben wirkt. Mit text-box-trim: trim-both und text-box-edge: cap alphabetic entspricht die tatsächliche Texthöhe der Cap-Height, wodurch symmetrisches Padding auch symmetrisch aussieht, ganz ohne empirisch ausprobierte Korrekturwerte.

Besonders bei kleinen UI-Elementen wie Chips, Badges oder Tab-Beschriftungen summiert sich der Effekt: Schon ein bis zwei Pixel Differenz fallen bei einer Zeilenhöhe von 20 Pixeln deutlich ins Auge. Wer ein konsistentes Design-System pflegt, kann die Regel einmal für alle interaktiven Text-Elemente definieren und muss danach bei jedem neuen Button-Typ nicht erneut manuell nachjustieren.

.btn {
  display: inline-flex;
  align-items: center;
  padding-block: 0.625rem; /* oben und unten identisch */
  padding-inline: 1.25rem;
  border-radius: 0.5rem;
  background: #4a1d96;
  color: white;
  font-weight: 600;
}

.btn > .btn-label {
  text-box-trim: trim-both;
  text-box-edge: cap alphabetic;
}

7. Praxis: Headlines und Hero-Sections ohne Zeilenabstand-Versatz

Bei großen Hero-Headlines mit engem line-height fällt der Leading-Überhang besonders stark auf, weil die Schriftgröße den absoluten Pixel-Wert des Überschusses proportional vergrößert. Ein Hero-Titel mit 64 Pixeln Schriftgröße kann so mehrere Pixel Leerraum über der ersten und unter der letzten Zeile tragen, was den vertikalen Rhythmus einer Seite spürbar aus dem Takt bringt, gerade wenn die Headline in ein eng abgestimmtes Grid-System eingebettet ist.

Für mehrzeilige Headlines empfiehlt sich trim-start auf dem obersten und trim-end auf dem untersten sichtbaren Textblock, während der Zeilenabstand zwischen den einzelnen Zeilen davon unberührt bleibt. So bleibt die Lesbarkeit des mehrzeiligen Textes erhalten, während sich der Abstand zu Elementen davor und danach exakt an der optischen Textgrenze orientiert, statt an der technischen Zeilenhöhe der Schriftart.

.hero-headline {
  font-size: clamp(2.5rem, 5vw, 4rem);
  line-height: 1.05;
  text-box-trim: trim-both;
  text-box-edge: cap alphabetic;
  margin-block: 0; /* kein Ausgleich mehr durch negative Margins noetig */
}

.hero-headline + .hero-lead {
  margin-block-start: 1rem; /* exakter Abstand ohne Leading-Puffer */
}

8. Fallback für Browser ohne Unterstützung

Da text-box-trim eine vergleichsweise neue Property ist, unterstützen nicht alle im Feld eingesetzten Browser sie bereits. Weil die Property in nicht unterstützenden Browsern einfach ignoriert wird, ohne Fehler zu werfen, bleibt das Layout im schlimmsten Fall bei der alten, etwas großzügigeren Optik, statt komplett zu brechen. Ein progressives Enhancement ist damit ohne zusätzlichen Aufwand automatisch gegeben.

Wer den optischen Unterschied zwischen unterstützenden und nicht unterstützenden Browsern minimieren will, kann zusätzlich mit @supports gezielt prüfen, ob die Property verfügbar ist, und nur dann kleinere Anpassungen an Padding oder Margin vornehmen, die sonst zu einem doppelten Versatz führen würden. Für die meisten UI-Elemente reicht jedoch der native Fallback völlig aus, ohne dass zusätzlicher CSS-Code nötig wird.

.btn-label {
  /* Basis-Padding fuer Browser ohne text-box-trim */
  padding-block: 0.75rem;
}

@supports (text-box-trim: trim-both) {
  .btn-label {
    text-box-trim: trim-both;
    text-box-edge: cap alphabetic;
    /* engeres Padding, weil der Leading-Puffer bereits entfernt ist */
    padding-block: 0.625rem;
  }
}

9. Browser-Support und Einordnung gegenüber älteren Ansätzen

Unterstützung für text-box-trim und text-box-edge ist bei modernen Chromium- und WebKit-basierten Browsern bereits gelandet, während andere Engines an der Implementierung arbeiten. Vor dem produktiven Einsatz lohnt sich immer ein Blick auf eine aktuelle Kompatibilitätstabelle, weil sich der Support-Stand bei einer noch jungen Property schnell ändern kann.

Gegenüber älteren Ansätzen wie manuell kalibrierten negativen Margins oder JavaScript-Bibliotheken, die Font-Metriken zur Laufzeit auslesen, bietet die native Property drei klare Vorteile: Sie funktioniert unabhängig vom konkreten Font, bricht nicht beim Austausch der Schriftart, und sie kostet keine zusätzliche Rechenzeit im Browser, weil die Metriken bereits beim Rendern der Schrift bekannt sind.

10. Zusammenfassung

11. FAQ: text-box-trim: Das Wichtigste auf einen Blick