Immer wieder gut: Browser und Silbentrennung

Eine Anekdote aus dem Agenturalltag

Artikel von:
Søren Birkemeyer
Veröffentlicht am:2026-11-05

In diesem Beitrag

Wieder mal Silbentrennung, wieder mal der Gemeinsame Bundesausschuss (GBA): Ein Screenshot von einem Android-Smartphone zeigt, dass auf einer Seite lange Wirkstoffnamen über den Rand des Inhaltsbereichs hinauslaufen und einen horizontalen Scrollbalken erzeugen.

Auf einem Samsung Galaxy S26 ist zu sehen, dass der Text ohne umzubrechen weiterläuft und die Seite über ihr eigentliches Layout hinaus seitlich scrollbar ist. Das Ergebnis sieht kaputt aus.

Auf dem iPhone der Kollegin? Alles in Ordnung. In Firefox auf dem Laptop? Auch.

Ein neuer Fall aus der Kategorie "Spaß mit der Silbentrennung". Los geht's!

Lange Zeichenketten ohne Leerzeichen

Die Übeltäter sind Zeichenketten, die in einigen Kombinationen von System und Browser keine offensichtlichen Trennstellen haben, z. B. lange URLs, die als Linktext im Fließtext stehen:

g-ba.de/bewertungsverfahren/methodenbewertung/letzte-aenderungen/rss.xml

URLs haben keine Leerzeichen, dafür jede Menge Schrägstriche. Tatsächlich beschränkt sich das Problem nicht auf URLs. Auf Seiten zur Nutzenbewertung von Arzneimitteln stehen Wirkstoffkombinationen wie

Darunavir/Cobicistat/Emtricitabin/Tenofoviralafenamid

in Überschriften und Listen. Auch hier trennt ein Chrome-Browser auf Android nicht, so dass die Zeile ca. 632px breit wird und Nutzende einen seitlichen Scrollbalken sehen. Horizontales Scrollen ist übrigens nicht nur lästig, sondern auch ein Verstoß gegen das WCAG-Kriterium 1.4.10 "Reflow" bzw. den BITV-Prüfschritt 9.1.4.10 "Inhalte brechen um"[1]. Dass es auf dem iPhone trotzdem passt, liegt an der Silbentrennung: Safari trennt die Wirkstoffe selbst (Darunavir/Cobi- | cistat/Emtricitabin/Tenofovi- | ralafenamid), Chrome auf Android dagegen trennt Zeichenketten mit Schrägstrich gar nicht.

Drei Browser, zwei Meinungen

Warum klappt es in Firefox? Weil Firefox nach einem Schrägstrich umbrechen darf, solange keine Ziffer folgt. So sieht es auch der Unicode-Algorithmus für Zeilenumbrüche (UAX #14)[2] vor.

Chrome und Safari dagegen behandeln ASCII-Zeichen mit einer eigenen, historisch gewachsenen Tabelle, die nur ausgewählte Umbruchstellen erlaubt – laut Quelltext-Kommentar in Chromium[3] orientiert an Firefox 3.6 und dem Internet Explorer. Der Schrägstrich ist nicht als Umbruchstelle aufgeführt.

Eine kuriose Nebenwirkung dieser gewachsenen Tabelle ist, dass sie nur ASCII-Zeichen betrifft; steht nach dem Schrägstrich ein Zeichen wie "Ä" oder "é", bricht Chrome sehr wohl um. Die passenden Bugreports gibt es übrigens schon lange: bei WebKit seit 2010[4], bei Chromium seit 2023[5]. Es gibt leider keine Anzeichen, dass sich Browser-Entwicklungsteams in nächster Zeit mit diesem Thema befassen werden. Die Unicode-Spezifikation erlaubt den Umbruch nach dem Schrägstrich, sie verlangt ihn aber nicht.

Drei Lösungsansätze

1. overflow-wrap: break-word

Eine Zeile CSS, die wir für alle Texte definieren und über unser Design System auf alle 5 Websites und 8 Extranets des GBA verteilen können. Der Browser bricht nur dann innerhalb eines Wortes um, wenn es sonst zu einem Scrollbalken führen würde[6]. Normaler Text bleibt unverändert.

Der Haken: die Umbruchstelle ist beliebig, also z. B.

Darunavir/Cobicistat/Emtric
itabin/Tenofoviralafenamid

anstatt typografisch ideal nach dem Schrägstrich.

2. <wbr> HTML-Element für Zeilenumbruch-Gelegenheit

Eine automatische PHP-Funktion könnte beim Erzeugen des HTMLs jeder Seite nach jedem Schrägstrich zwischen zwei Wörtern ein <wbr>[7] einfügen. Dieses HTML-Element ist genau dafür gedacht, dem Browser einen Fingerzeig zu geben, dass an dieser Stelle umgebrochen werden darf, wenn es nötig ist. <wbr> wird beim Kopieren des Textes in die Zwischenablage nicht berücksichtigt und von Screenreadern ignoriert. Typografisch gesehen wäre es die schönste Lösung.

Aber: das ist ein zusätzliches HTML-Element. In bestimmten Situationen, z. B. im <title>, in HTML-Attributen, in RSS-Feeds und Text-E-Mails würde es zu Ausgabefehlern führen, daher kann dieser Ansatz nicht so global eingesetzt werden wie die CSS-Lösung. Im Umkehrschluss heißt das, jedes Template müsste einzeln angepasst werden, und in allen zukünftigen Erweiterungen müsste erwogen werden, ob die Funktion anzuwenden wäre.

3. Unsichtbare, breitenlose Leerzeichen durch die Redaktion

Grundsätzlich wäre denkbar, dass die Redaktion im CMS manuell ein Zeichen U+200B ("breitenloses Leerzeichen") direkt nach den Schrägstrichen einfügt. Das würde analog zu <wbr> dazu führen, dass auch Chrome hier umbricht.

Großer Nachteil: diese breitenlosen Leerzeichen sind für alle unsichtbar, werden aber beim Kopieren in die Zwischenablage mitgenommen und machen kopierte URLs ungültig. Zudem wäre es ebenfalls keine allgemeine Lösung, sondern müsste für immer von der Redaktion bei der Pflege aller Texte auf allen Seiten bedacht werden.

Exkurs: Was sagen andere?

Der Duden ist eindeutig: URLs bricht man am besten nach einem Schrägstrich um, und zwar ohne zusätzlichen Trennstrich[8]. Genau das würde der <wbr>-Ansatz automatisieren.

Bei KERN, dem UX-Standard für die deutsche Verwaltung, findet sich overflow-wrap: break-word im Quellcode einzelner Komponenten wie Accordion und Details, dokumentiert ist das Verhalten nicht.

Andere Seiten, z. B. das Bundesinstitut für Arzneimittel und Medizinprodukte (BfArM) oder das unabhängige Institut für Qualität und Wirtschaftlichkeit im Gesundheitswesen (IQWiG), stehen vor der gleichen Herausforderung und lösen sie entweder durch hartes Abschneiden, Umbruch mitten im Wort oder sie akzeptieren den horizontalen Scrollbalken.

Einen offensichtlichen Branchenkonsens gibt es also nicht.

Pragmatismus vor Perfektion

Wir haben uns letztendlich für die CSS-Lösung entschieden. Dieser Ansatz ist nicht perfekt, aber gut genug. Vor allem verschieben wir so keine Verantwortung für das Entwicklungsteam oder die Redaktion in die Zukunft. Diese kleine, aber feine Zeile CSS wird mit dem nächsten Release unseres Design Systems allen Projekten zur Verfügung stehen.

Warum ist der unschöne Umbruch mitten in einer URL oder in Wirkstoffnamen unserer Ansicht nach gut genug? Er betrifft nur lange Zeichenketten vor allem auf schmalen Bildschirmen, das sind eher Randfälle. Uns sind heute nur drei Nutzenbewertungsverfahren sowie Links auf RSS-Feeds im Service-Bereich bekannt, auf die das zutrifft. Sollte er sich in der Praxis doch als störend erweisen, können wir die Situation neu bewerten und einen der verworfenen Ansätze nachrüsten.

Silbentrennung ist und bleibt ein spannendes Thema!

  1. BIK BITV-Test: Prüfschritt 9.1.4.10 Inhalte brechen um ↩
  2. Unicode: UAX #14: Unicode Line Breaking Algorithm ↩
  3. Chromium-Quelltext: Kommentar, Stand 05.11.2026 ↩
  4. WebKit: Bug 41103 – Consider matching either Firefox or IE better in the characters that allow a linewrap ↩
  5. Chromium: Issue 40073909 – Inconsistency in line-breaking due to special-casing of ASCII ↩
  6. MDN: overflow-wrap ↩
  7. MDN: <wbr> ↩
  8. Duden: Worttrennung bei URLs ↩

Interesse geweckt?

Wir hören gerne zu, wenn Sie Fragen oder Anmerkungen zu diesem Thema haben. Und wenn Sie ein Projekt, ein Produkt, ein Problem oder eine Idee mit uns besprechen möchten, freuen wir uns erst recht über ein Gespräch!

Kontakt aufnehmen

Hallo, wir sind webfactory 👋

Seit 1997 entwickeln wir mit Sitz in Bonn maßgeschneiderte Websites und Webanwendungen für Unternehmen und öffentliche Auftraggeber. Wir stehen für langlebige Lösungen, Barrierefreiheit und partnerschaftliche Zusammenarbeit auf technisch höchstem Niveau. Unter anderem bieten wir: