Silbentrennung und typografisch korrekte Anführungszeichen sind auch im Jahr 2020 noch nicht überall anzufinden. Ausgerechnet Chrome und die Webkit/Blink-Browser hinken hier Firefox hinterher. Das Problem ist (mal wieder) nicht so trivial, wie der erste Blick vermuten lassen würde. Was das Ganze mit der Locale und dem Browser-Standard-CSS zu tun hat, versuche ich hier im Artikel mal zu erklären.
Auslöser für meine Gedanken war ein Tweet, beziehungsweise der dort verlinkte Artikel zu Silbentrennung auf deutschen Websites:
Die Silbentrennung, oder besser Wortrennung, basiert zwar meistens auf Silben, aber nicht immer. Entscheidender ist die Bedeutung, also die Sinnabschnitte (Morpheme). Ein paar Beispiele machen das deutlicher:
Türk-linke vs. Tür-klinke
Fluch-torte vs. Flucht-orte
Urin-stinkt vs. Ur-instinkt
Nun stellt Phillip in dem kurzen Artikel die These auf, dass das CSS-Feature hyphens nur dann funktioniert, wenn die Sprache für Deutsch zum Beispiel mit <html lang="de"> eingestellt ist, da die Spezifikation Bezug nimmt auf ISO 639-1 Codes. Folglich wäre de-DE oder de-DE-formal, was WordPress ausgibt, falsch. Daher klappt das mit der Silbentrennung dann auch nicht. Ich hatte schon damals Bedenken, ob das wirklich stimmt, denn obwohl diese Codes nicht mal in der Liste stehen, so besagt BCP 47 („best current practice“) ganz klar, dass die language tags sich aus mehreren Komponenten zusammensetzen. Und das ist nicht nur region und variant, sondern noch viel mehr:
language-extlang-script-region-variant-extension-privateuse
Warum klappt es denn bei ihm nicht? Ein Blick zur Dokumentation bei mozilla zu hyphens erklärt es.
Sein „Beweis“, war die kaputte Funktion auf Chrome für Android. Nur laut der Dokumentation ist auf Chrome (inkl. Android) und vielen anderen Browsern die Silbentrennung nur für die englische Sprache implementiert.
Hyphenation dictionary for English (en, en-*)
Die Tabelle erklärt gleich noch mehr. Die Sprachzuweisung beschränkt sich nicht nur auf die ISO 639-1 Codes, sondern erwischt mit der Wildcard „*“ auch sämtliche Regionen und Varianten.
Warum ist das aber so? Wieso wird das nur pro Sprache umgesetzt? Jetzt kommen wir wieder zu dem Punkt vom Anfang des Artikels. Damit die Worttrennung nicht nur silbenbasiert ist und zur reinen Silbentrennung verkommt und solche Blüten wie „Urin-stink“ (statt Ur-instinkt) hervorbringt, benötigen die Browser Wörterbücher („Hyphenation dictionaries“). Da sie die Sinnabschnitte nicht erkennen können, hilft nur eine Datenbank mit den bekannten Ausnahmen. Programme wie InDesign haben solche Wörterbücher. Aber Browser haben dies mit Ausnahme von Firefox leider noch nicht umgesetzt. Zumindest nicht für andere Sprachen als Englisch. Klar, denn die Anzahl an Sprachen ist groß und auch die Wörterbücher sind groß – viel Ballast für eine sehr spezifische Funktion.
Hier ist schön zu sehen, dass in Chrome in Englisch beim letzten Wort eine Trennung zwar gemacht wird, aber die deutsche Ausnahme des Wortes Urinstinkt nicht beherzigt wird und daher ein Fehler entsteht.
Ist die Sprache auf Deutsch gestellt, wird korrekt getrennt, aber auch hier ist nicht alles perfekt. Das Wort Fluchtorte scheint in der Datenbank nicht zu existieren.
Der aufmerksame Leser und die aufmerksame Leserin wird nun sagen: „Halt mal, wieso klappt das denn überhaupt in Chrome? Weiter oben hast Du doch geschrieben, dass Chrome das gar nicht unterstützt!“
Das liegt an folgendem Hinweis:
autovalue is only supported on macOS and Android and for languages the OS provides hyphenation for.
Wenn also das Betriebssystem ein bestimmtes Wörterbuch anbietet, dann kann auch Chrome (sowie Edge und Opera) eine entsprechende Wortrennung umsetzen. Leider habe ich keine Quelle gefunden, welche Sprache in welcher macOS-Version unterstützt wird. Für Edge gibt es dazu noch eine weitere Einschränkung:
Only works if the specified language is the same as the language of the underlying OS.
Für Edge kann das also nur für Deutsch funktionieren, da mein Betriebssystem auf Deutsch gestellt ist.
Offensichtlich bietet also Android in diesem speziellen Fall das Wörterbuch nicht direkt an, weshalb die Worttrennung nicht richtig funktioniert. Aber es gibt noch eine weitere Möglichkeit warum es speziell bei Android scheitert. Die Berechnung von Wortrennungen ist sehr aufwändig und aus Performance-Gründen ist Hyphenation daher in manchen Fällen standardmäßig deaktiviert.
Die Worttrennung ist nicht das einzige Problem dieser Art. Die weniger bekannten Inline-Zitate mit dem HTML-Befehl <q> sind ebenfalls abhängig von der Sprachauszeichnung im HTML-Dokument.
In allen Browsern werden die öffnenden Anführungszeichen korrekt unten (wie eine 99) gesetzt und die schließenden Anführungszeichen oben (wie eine 66), wenn die Sprache auf de gestellt ist:
Ist die Sprache auf en gestellt, dann sind die öffnenden Anführungszeichen korrekterweise oben (wie eine 66) und die schließenden Anführungszeichen sind auch oben (aber wie eine 99):
In Edge, Safari und Vivaldi geht aber plötzlich etwas kaputt, wenn die Sprache auf de-DE oder de-DE-formal gestellt ist, so wie es WordPress standardmäßig über die language_attributes()-Funktion macht.
Offensichtlich scheint das Standard-CSS in den Browsern hier etwas zu spezifisch zu sein. Die Werte können aber einfach repariert werden:
html[lang^="de"] q::before {
content: '\201E';
}
html[lang^="de"] q::after {
content: '\201C';
}
Quelle: https://gist.github.com/glueckpress/bf2128102b0a6b3250f6
Oder man überschreibt einfach die Werte für die globalen Anführungszeichen (open-quote und close-quote):
quotes: "\201E" "\201C"
Fazit
Für die Silbentrennung ist die Art der Sprachauszeichnung (de oder de-DE oder de-DE-formal) egal. Solange der Browser oder das Betriebssystem ein Wörterbuch für die gewählte Sprache bereitstellen, funktioniert die Silbentrennung. Perfekt sind diese Wörterbücher jedoch nicht. Manuelle Nacharbeit durch das Setzen von ­ an geeigneter Stelle kann trotzdem noch notwendig werden.
Für Inline-Zitate ist die Kritik von Phillip tatsächlich berechtigt. Nur bei de wird das Element in allen Browsern korrekt ausgegeben. Safari und Vivaldi scheitern bei Sprachangaben mit Region und/oder Variante. In Anbetracht der nicht direkt verbauten Unterstützung in den Editoren ist das aber kaum relevant.
Du kennst noch mehr solcher sprachspezifischen Besonderheiten oder du hast die Liste gefunden, wo die Unterstützung der Hyphenation-Wörterbücher pro macOS-Version aufgeschlüsselt ist? Dann freue ich mich über einen Kommentar. Genauso bei Hinweisen zu Fehlern, Ergänzungen oder Lob. 🙂
