Progressiver HTML Blocksatz mit Silbentrennung

von Marco Pfeiffer (Bear­beitet am )

Einige Browser unter­stützen Silben­tren­nung über CSS. Hier ein Trick für Block­satz wenn Silben­tren­nung vorhanden ist.

Schon mal eine Zeitung gesehen und danach eine News-­Seite? Das Schrift­bild von Zeitungen ist meistens deutlich schöner als das von Websei­ten. Woran liegt das? Mir fallen 3 Gründe ein. Einmal die meist recht hübsche Serif-­Schriftart welche auf einem low-DPI Monitor aller­dings furchtbar aussieht. Dann allge­mein die recht niedrige Auflö­sung auf modernen Desktop-P­C’s. und zuletzt der Block­satz, welche den Text schön gleich­mäßig aussehen lässt.

Text mit Blocksatz

“Block­satz können wir im Web auch!” wird nun der eine oder andere sagen und es stimmt, text-a­lign: justify erlaubt auch uns Block­satz zu verwenden.

Das Ergebnis sieht dann so aus:

Sieht gut aus, doch wenn man anfängt den Text zu lesen, sollten die großen Abstände zwischen den Wörtern auffal­len. Beson­ders in der deutschen Sprache haben wir zum Teil sehr lange Wörter. Der Browser darf aber nur an Leerstellen und anderen Sonder­zei­chen umbre­chen. Damit der Block­satz dann noch funktio­niert, müssen sehr große Abstände im Text einge­fügt werden.

Text mit Blocksatz und Silbentrennung

Direkt viel besser als ohne Silben­tren­nung! Das beste daran ist, dass es mit der css Eigen­schaft hyphens auch mühelos in den Text einge­fügt werden kann… wenn es vom Browser unter­stützt wird, denn die Browser-Un­ter­stüt­zung für hyphens ist nicht sonder­lich gut und wenn wir uns darauf verlassen werden einige unserer Besucher den Lücken­haften Block­satz von oben sehen.

Die einfachste garantiert lückenlose Implementierung

Eine neues Feature in css, das ich bisher selten gesehen hab, ist die @supports CSS at-rule. Das hängt vermut­lich mit der Browser-Un­ter­stüt­zung für @supports zusam­men­hängen und dem Fakt das alle Browser, die es unter­stüt­zen, auch meistens alles können was man braucht. Deswei­teren gibt es ja auch Modernizr, welches von allen relevanten Browsern unter­stützt wird.

Aller­dings wird der @support Block von Browsern, die es nicht unter­stüt­zen, ignoriert und da die hyphens Eigen­schaft sowieso nur von wenigen Browsern verstanden wird, ist die überschnei­dung von Browsern mit @supports- und hyphens support relativ groß. Daher schlage ich so etwas vor:

@supports ((-webkit-hyphens: auto)
        or (   -moz-hyphens: auto)
        or (    -ms-hyphens: auto)
        or (        hyphens: auto)) {

    /*
     * Das lang Attribute ist sehr wichtig für die automatische Silbentrennung.
     * Daher erlaube ich es nur im Zusammenhang mit bestimmten Sprachen.
     * Mozilla hat eine schöne Liste mit welchen Sprachen in welchem Browser unterstützt wird:
     * https://developer.mozilla.org/en-US/docs/Web/CSS/hyphens#Browser_compatibility
     */
    [lang^=de] p,
    [lang^=en] p {
        text-align: justify;
        -webkit-hyphens: auto;
           -moz-hyphens: auto;
            -ms-hyphens: auto;
                hyphens: auto;
    }

    /*
     * Es können bestimmte Elemente in Paragrafen vor kommen
     * auf denen eine Silbentrennung nicht sehr schön ist.
     */
    a, b, abbr, strong {
        -webkit-hyphens: manual;
           -moz-hyphens: manual;
            -ms-hyphens: manual;
                hyphens: manual;
    }
}

Browser-Unterstützung

Wenn wir uns die Browser-Un­ter­stüt­zung für hyphens angucken sehen wir, dass @supports von allen wichtigen Browsers unter­stützt wird die automa­ti­sche hyphens unterstützten. Aller­dings gibt es 2 Ausnah­men. Der Safari unter­stützt es erst seit Version 9 (und iOS 9) und der IE versteht auch kein @supports. Diese werden die at-rule einfach ignorieren und den text dann auch ohne Block­satz anzeigen.

Was aller­dings viel schlimmer ist, ist das der Chrome die hyphens Eigen­schaft überhaupt nicht unter­stützt. Daher muss der Text auf jeden Fall auch ohne Silben­tren­nung und Block­satz gut aus sehen.

Ein weiteres Problem ist, dass die Browser alle eine andere Imple­men­tie­rung verwen­den, welche nicht Zwangs­läufig auf einem Wörter­buch basiert. W3C sagt uns:

CSS Text Level 3 does not define the exact rules for hyphe­na­tion […] . CSS Text Module Level 3 vom 10 October 2013

Ich hab die Eigen­schaft nur im Safari und Firefox getestet und dort waren die Ergeb­nisse identisch. Dennoch sollte man sich nicht auf eine perfekte Silben­tren­nung verlassen und eventuell Redak­teuren die Möglich­keit geben diese für einzelne Paragra­phen zu deaktivieren.

Plattformübergreifende Silbentrennung

Eine Lösung, bereits jetzt platt­for­m­über­grei­fend Silben­tren­nung zu bieten, ist alle Wörter vorher mit ­ zu trennen. Aller­dings wird niemand freiwillig seinen Text mit diesen “soft hyphen” ausstatten wollen. Das Thema der automa­ti­schen Silben­tren­nung im Web scheint bisher auch nicht sehr verbreitet zu sein, daher gibt es nicht viele Softwa­re-­Bi­blio­theken die man dafür verwenden kann.

Für den Browser gibt es den JavaS­crip­t-­Po­ly­fill Hyphenator.js, welcher mit etwas Konfi­gu­ra­tion ganz gut funktio­niert. Was mir nur nicht gefällt ist, dass der Text kurzzeitig nicht sichtbar ist bis die Biblio­thek die ­s einge­baut hat. Man ist außerdem an bestimmte CSS-Klassen gebun­den, da der Hyphe­nator die CSS-Re­geln nicht interpretiert.

Eine weitere Möglich­keit ist phpHyphenator welche scheinbar eine Portie­rung von Hyphenator.js ist. Ich hab diese aller­dings bisher nicht auspro­biert und das fehlen einer Dokumen­ta­tion sowie die Tatsa­che, dass die Biblio­thek Funktionen global definiert, werden mich wahrschein­lich auch in Zukunft davon abhal­ten. Generell sollte jedes php Projekt zumin­dest mit composer Kompa­tibel sein, was dieses Projekt ebenfalls nicht ist.

Schlusswort

Silben­tren­nung ist eine nette Spiele­rei, aber noch nicht ganz bereit für den Einsatz. Es Fehlen noch Dinge wie die Angabe wie viele Zeichen vor und nach dem Binde­stich auftau­chen sollen. Diese Features sind zwar im CSS Text Module Level 4 vom 28 October 2015 geplant und auch zum Teil im Safari mit -webkit-hyphenate-limit-before/after unter­stützt, aber dann haben wir schon so viele Möglich­keiten wie die Seite aussehen kann, dass es vermut­lich den Aufwand nicht wert ist. Natür­lich könnte man in der @support Regel alle diese Eigen­schaften als Bedin­gung rein kippen, aber dann gibt es das Feature aktuell nur für iPads und Safari.