Variable Fonts und wie man sie (nicht) einsetzen sollte

Das Ausspielen von Software am Freitag ist begleitet vom Mythos, dass es schiefgeht – ja fast schon schiefgehen muss, wenn es kritisch ist. Murphy lässt grüßen. Die Erfahrung zeigt jedoch, dass es auch sehr häufig einfach glattgeht und die Statistik würde vermutlich mit den anderen Werktagen nicht gnädiger sein. Bugfixing am Wochenende bleibt allerdings hartnäckiger im Gedächtnis als an einem normalen Arbeitstag. So ist es auch uns kürzlich ergangen.

Rollout

Am 6. Mai spielten wir die Umstellung von der statischen Variante der Schrift Source Sans Pro auf den Variable Font aus. Den Branch hatten wir länger getestet und sogar eine öffentliche Testseite eingerichtet, mit der wir uns alte und neue Fonts im Vergleich auch mal auf Nicht-Arbeitsgeräten von Zuhause ansehen konnten. Schriften im Web sind dabei komplizierter, als es auf den ersten Blick erscheinen mag. Zum einen kommt es dabei auf das Zusammenspiel von Browser und Betriebssystem an, zum anderen auf deren Versionen. Außerdem können Schriften auch noch unterschiedlich gut funktionieren, je nachdem was für ein Monitor genutzt wird und wie hoch dessen DPI sind. Insgesamt also viele Faktoren und Kombinationen. Der Rollout lief problemlos durch, auch einige Stunden nach der Änderung war alles ruhig. Feierabend. Wochenende. Yay?

Nay! Rollback?

Am darauffolgenden Samstag schaute der Autor dieser Zeilen ins Forum und bemerkte zwei Threads zum Schriftbild. Es kristallisierte sich ein Problem mit dem Firefox auf Windows 7 bis 8.1 heraus, was dann auch nachvollzogen werden konnte. Angaben zur Schriftfettung (font-weight) wurden anscheinend nicht ausgewertet und immer der dünnste Schriftschnitt ausgegeben, was zu einem nur sehr schwer leserlichen Schriftbild führte.
Am selben Tag wurde noch versucht, einen Fix für das Problem zu finden, aber auf die Schnelle tat sich keine brauchbare Lösung auf, sodass nur noch der Rollback blieb.

Was sind eigentlich Variable Fonts?

Web-Fonts sind eigentlich so aufgebaut, dass man pro Schriftschnitt eine eigene Datei hat. Beispielsweise die Source Sans Pro in normaler Darstellung (regular) und fett (bold) sind bereits zwei Dateien. Will man diese Varianten auch noch kursiv (italic) verwenden, bedeuten die Kombinationen (regular-italic und bold-italic) zwei weitere Dateien. Jede zusätzliche Variante zieht mehr Schriftdateien nach sich, die geladen werden müssen. Daher versucht man, sich auf wenige Schriftschnitte zu reduzieren. Aus gestalterischem Gesichtspunkt ist das zwar auch durchaus zu empfehlen, jedoch würde manches Mal der Einsatz eines anderen Schriftschnitts dem Layout auch gut tun.

Variable Fonts funktionieren hingegen anders. Es gibt eine Schriftdatei, die sogenannte Variations-Achsen hat. Das sind steuerbare Parameter zum Verändern des Schriftbilds. Zum einen gibt es Standard-Achsen, aber Fonts können auch ganz eigene Achsen haben, die dann ebenfalls über CSS gesteuert werden können. In unserem Fall ging es aber nur um die Standard-Achsen für Kursiv und Fettung.

Die richtige Einbindung mit Fallback

Nach wie vor waren wir an den Features der Variable Fonts interessiert und der erste Dämpfer schreckte uns noch nicht ab. Weitere Recherchen und Tests brachten uns letztlich zu einer funktionierenden Lösung, die einen Fallback auf die statischen Schriftdateien beinhaltet. Besucherinnen und Besucher von heise online, deren Endgeräte keine Variable Fonts unterstützen, bekommen die statischen Fonts und bei der Verwendung eines Schriftschnitts, den der statische Font nicht anbietet, wird auf den nächsten passenden, angebotenen Schriftschnitt ausgewichen.

Der Variable Font wird dabei in diesem Format dem Browser bekannt gemacht:

@font-face {
  font-family: "Source Sans VF";
  font-weight: 200 900;
  src:
    url("source-sans-vf.woff2") format("woff2 supports variations"),
    url("source-sans-vf.woff2") format("woff2-variations");
}

Entscheidend ist hier die format-Angabe. Dass es aktuell zwei Format-Bezeichnungen für Variable Fonts gibt, kann erst mal mit einem Augenrollen ignoriert werden – sie verweisen beide auf dieselbe Datei. Wichtig ist, dass von der Variable Font nur Variable-Font-Formate angeboten werden und nicht z.B. noch eine TTF-Variante. Die font-weight-Angabe hier ist übrigens eine Eigenheit von Variable Fonts, die dem Browser die Spanne mitteilt, die dieser Font abdeckt.

Der statische Font wird weiterhin ganz normal definiert, wie man das bisher auch gemacht hat, mit einer Definition pro Variante:

@font-face {
  font-family: "Source Sans Pro";
  font-weight: 400;
  src: url("source-sans-pro-400.woff2") format("woff2");
}
@font-face {
  font-family: "Source Sans Pro";
  font-weight: 600;
  src: url("source-sans-pro-600.woff2") format("woff2");
}

Im CSS muss nun die Schrift wie folgt angewendet werden (für das Beispiel sind weitere Fallback-Systemschriften ausgespart):

body {
  font-family: "Source Sans Pro", sans-serif;
}

@supports (font-variation-settings: normal) {
  body {
    font-family: "Source Sans VF", sans-serif;
  }
}

Mit der @supports-Abfrage sorgen wir zunächst dafür, dass Browser, die Variable Fonts nicht unterstützen, direkt bei dem statischen Font bleiben. Ein aktueller Firefox unter Windows 7 unterstützt aber font-variation-settings und versucht daher zunächst den Variable Font zu laden. Letztlich tut er es allerdings unter Windows 7 nicht, da das angegebene Format (s.o.) nicht unterstützt wird. Nun greifen normale Fallback-Regeln von CSS und es wird auf den statischen Font ausgewichen.

Moderne Browser- und Betriebssystem-Kombinationen kennen das Variable-Font-Format und unterstützen font-variation-settings, weshalb diese gleich nur die Variable Fonts laden.

Auf dem Weg zu dieser Lösung haben wir diverse andere Kombinationen durchprobiert. Beispielsweise die beiden Schriften direkt in einer font-family-Angabe als Fallback-Schrift der anderen zu listen, führte in einigen Browsern zum Laden beider Schriften. Oder den Variable Font in einer gemeinsamen @font-face-Definition mit dem statischen Font zu definieren, hätte uns die Vorteile der Variable Fonts genommen, da wir dann keine Definition der Spanne einer Variations-Achse hätten angeben können.

Rollout – nochmal

Nachdem wir die richtige Kombination aus Schriftendefinition und -anwendung gefunden hatten, wurde natürlich wieder getestet – besonders mit den kritischen Kandidaten, aber auch noch einmal über diverse Browser- und Betriebssystemversionen hinweg.

Murphy nicht herausfordernd wählten wir für den erneuten Rollout diesmal einen Mittwoch. Am 18. Mai übertrat die überarbeitete Version die Schwelle zum öffentlichen Server und dazu wurde noch ein begleitender Foren-Beitrag geschrieben für etwaige Rückmeldungen. Diesmal jedoch ging der Austausch quasi unbemerkt über die Bühne. Feierabend.

(map)