Vorgeschlagene Webfonts-API kommt nicht zu WordPress 5.9, landet möglicherweise zuerst in Gutenberg

Nach dem, was wie eine Flucht vor WordPress 5.9 aussah, wurde eine vorgeschlagene Webfont-API auf Eis gelegt. Die Funktion würde standardisieren, wie Theme- und Plug-in-Entwickler Schriftarten laden, und den Grundstein für zukünftige benutzerorientierte Funktionen legen.

Jono Alderson eröffnete im Februar 2019 ein Ticket für das Feature. In den letzten Monaten nahm der Vorschlag Fahrt auf. Die Pull-Anforderung hatte über 200 In-Ticket-Nachrichten, 93 Commits und Code-Genehmigungen von zwei Haupt-Committern. Die API schien bereit zu sein. In den vergangenen Tagen kam es jedoch zum Stillstand.

Andrew Ozz, ein führender WordPress-Entwickler, hat die Möglichkeit der neuen API-Landung in 5.9 im Wesentlichen gestoppt. Er erklärte, dass er nicht glaube, dass der Vorschlag für WordPress bereit sei.

„Rein als Code sieht es gut aus“, schrieb er in das Ticket. „Es ist wirklich gut dokumentiert (danke [Tonya Mark]!). Ich kann jedoch immer noch nicht erkennen, wie dies WordPress kurz- und langfristig verbessern würde. Wir unterhielten uns mit [Andrei Draganescu] und er schlug vor, dass dies idealerweise ein Feature-Plugin sein sollte, und ich stimme zu. Dann wäre es möglich gewesen, es wirklich in der Produktion zu testen, die Annahmen, die bei der Erstellung getroffen wurden, zu überprüfen (oder zu verwerfen) und es zu einer wirklich würdigen Ergänzung für WordPress zu machen. Für 5.9 ist es dafür jetzt leider zu spät.“

Eines der Probleme beim Testen von Feature-Plugins für APIs besteht darin, dass sie nicht oft übernommen werden, wie andere im Ticket angemerkt haben. Entwickler würden sich in den meisten Fällen nicht auf sie in der Produktion verlassen. Und der durchschnittliche Endbenutzer würde nichts speziell für Entwickler installieren.

„Dies als Feature-Plugin vorzuschlagen, ist eine elegante Möglichkeit, etwas um ein paar Jahre zu verzögern“, sagte Ari Stathopoulos, einer der Entwickler hinter der API. Er wies jedoch darauf hin, dass die REST-API eine Ausnahme sei, die gut genug funktionierte, um in WordPress portiert zu werden.

Der WordPress-Kernvorschlag wird wahrscheinlich zur weiteren Untersuchung in das Gutenberg-Plugin geschoben. Dies wäre eine Art Kompromiss zwischen dem Start als separates Feature-Plugin und dem Einstieg in WordPress 5.9.

Die Webfonts-API steht nicht in direktem Zusammenhang mit dem Blocksystem. Sowohl traditionelle als auch Block-Themes sowie Plugins könnten heute von dieser Funktion Gebrauch machen. Einige Gutenberg-Vorschläge stützen sich jedoch auf die Existenz der API, z. B. die Möglichkeit für Themenautoren, Webfonts über ihre theme.json Dateien zu definieren.

Ozz listete mehrere Fragen rund um den Vorschlag auf, und mehrere Entwickler antworteten darauf. Sein Hauptargument hing jedoch von der Praktikabilität ab, warum alles in der API notwendig sei, und erklärte, dass vorherige Antworten „im Prinzip“ gewesen seien und auf Annahmen zu beruhen schienen.

Auf der einfachsten Ebene würde die Webfonts-API Entwicklern ermöglichen, lokal gehostete Schriftarten oder solche von Google Fonts zu registrieren und zu laden. Entwickler könnten auch benutzerdefinierte Anbieter außerhalb der beiden Standardeinstellungen hinzufügen. Bei der ersten Iteration der vorgeschlagenen API ging es mehr darum, eine Grundlage zu schaffen, auf der in zukünftigen WordPress-Versionen aufgebaut werden kann.

Der Reiz der Funktion besteht nicht nur darin, Schriftarten zu laden. Technisch gesehen könnten Themenautoren dies mit einer einzigen Codezeile tun, wenn sie wollten. Vier Zeilen Code, wenn sie den aktuellen WordPress-Kernstandards folgen wollten, zumindest am Frontend.

Stathopoulos ratterte eine Liste von Verbesserungen herunter, die eine solche API für WordPress und seine Erweiterungen bringen würde.

• Designs könnten Schriftarten über ihre theme.json Dateien definieren.
• Schriftvorschau in der Schriftfamilienauswahl im Editor.
• Zeigt gültige Schriftstärken und -stile für eine Schriftfamilie an.
• Verbesserte Front-End-Leistung.
• Serverseitige Lokalisierung für bessere Leistung und Datenschutz.

Dies war eine kleine Auswahl der Argumente für die Aufnahme der API in den Kern von WordPress.

„Es gibt viele Verbesserungen in Gutenberg, die in der Schwebe sind und auf eine Webfonts-API warten“, schrieb Stathopolous in dem Ticket. „Das Fehlen einer Webfonts-API ist an dieser Stelle ein Blocker. Es ist kein Good-to-have-Artikel auf unserer Wunschliste, es ist eine Voraussetzung, um voranzukommen.“

Derzeit bezieht sich kein Standard speziell auf Webfonts in WordPress. Theme-Autoren huckepack von bestehenden Funktionen ab, um ein Stylesheet eines Drittanbieters oder ein benutzerdefiniertes mit @font-face Regeln einzureihen. Dies war im Laufe der Jahre eine allgemein akzeptierte Praxis in der Community der Themenautoren.

Viele haben es jedoch widerwillig akzeptiert. Mehrere haben benutzerdefinierte Skripte erstellt, um Schmerzpunkte zu lindern. Viele andere kopieren einfach die Methode, die das neueste Standard-WordPress-Theme gerade verwendet.

Eines der Ziele besteht darin, es so zu gestalten, dass sich Entwickler nicht um all die zusätzliche Arbeit kümmern müssen, die mit dem Laden von Webfonts verbunden ist. Es sollte wirklich nicht erforderlich sein, dass ein Design herausfindet, wie es sowohl im Editor als auch im Frontend geladen wird, das Vorladen handhabt oder die Lokalisierung berücksichtigt. Wenn Themes altern und APIs von Drittanbietern wie Google Fonts sich ändern, müssten Themes nicht aktualisiert werden, wenn WordPress sich im Hintergrund darum kümmert.

Das Problem, wie man Webfonts am besten lädt, vervielfacht sich, wenn man Plug-ins hinzufügt. Im Allgemeinen übernehmen Themes die ganze Schwerarbeit, wenn es ums Design geht. Einige Plugins springen jedoch in diese Seite der WordPress-Welt, um zusätzliche Stiloptionen hinzuzufügen. Es gibt keine Möglichkeit, Konflikte zu lösen, wenn mehrere Kopien derselben Schriftart geladen werden. Es gibt auch keine todsicheren Möglichkeiten, die Schriftarten eines Themas zu deaktivieren und sie über das Plugin zu ersetzen.

Ein solcher Plugin-Autor schickte mir eine E-Mail, um mich über Neuigkeiten zu informieren, die ich bereits kannte. Die Webfonts-API schien nicht mehr in WordPress 5.9 zu landen. Der Entwickler bereitete sich darauf vor, zusätzlich zu der neuen Funktion eine neue Website und einen neuen Dienst zu starten. Sie hatten sogar ein Maskottchen. Aktuell muss man wohl einfach abwarten.

Die Deadline für das Einfrieren des Features war vor zwei Tagen. Daher ist es unwahrscheinlich, dass die Webfonts-API wieder zum WordPress 5.9-Meilenstein hinzugefügt wird. Vielleicht sehen Entwickler es, wenn 6.0 landet. Vielleicht haucht das Verschieben in das Gutenberg-Plugin ihm etwas mehr Leben ein und ermöglicht es den Mitwirkenden, mit neuen Funktionen voranzukommen, die darauf angewiesen sind.