Ari Stathopoulos a annoncé une proposition de implémenter une API de polices Web dans le noyau WordPress. L’objectif est de standardiser la façon dont les auteurs de thèmes enregistrent et mettent en file d’attente les styles de police. Il peut également servir de base à d’autres fonctionnalités sur la route.
Jono Alderson a ouvert le billet d’origine pour une telle API en février 2019. La discussion s’est poursuivie par intermittence depuis lors, mais n’a que récemment pris de l’ampleur.
La proposition permettrait aux développeurs d’enregistrer des polices à partir de fichiers locaux ou d’une URL de feuille de style comme celles fournies par Google Fonts et d’autres API tierces. Cela refléterait les fonctions utilisées pour charger les scripts et les styles avec WordPress, de sorte que les développeurs devraient effectuer une transition sans trop de courbe d’apprentissage. Cependant, certains paramètres sont différents et tiennent compte de la gamme de fonctionnalités plus large nécessaire pour prendre en charge les polices Web.
Le chargement de polices Web n’est pas nouveau pour les auteurs de thèmes. Il existe plusieurs méthodes à utiliser, selon que les fichiers sont locaux ou servis par une API tierce. Cependant, WordPress n’a jamais proposé de solution, la chose la plus proche d’un standard étant le copier-coller de ce que faisaient les thèmes Twenty*. Cependant, divers projets ont vu le jour au fil des ans pour gérer une fonctionnalité que de nombreux auteurs de thèmes implémentent presque comme une seconde réflexion.
L’année dernière, Stathopoulos et d’autres membres de l’équipe des thèmes WordPress ont lancé le Projet de chargeur de polices Web, une bibliothèque intégrée pour les développeurs. Il permettait aux auteurs de thèmes de charger des feuilles de style à partir de l’API Google Fonts, puis de les stocker localement sur le serveur de l’utilisateur.
J’ai même touché à un paquet de chargement de polices à la fois, en créant un ensemble simple de fonctions pour mettre en file d’attente et retirer les feuilles de style des polices. C’était une idée construite au-dessus d’un tutoriel écrit par José Castaneda en 2016. Cependant, j’emprunte actuellement le méthode utilisée dans la Blockbase d’Automattic thème, en utilisant un mélange de functions.php et theme.json.
Le chargement des polices est une affaire relativement simple, donc on peut se demander pourquoi il y a un besoin d’une API de base pour le faire. C’est parce que les normes simplifient les tâches de routine pour tout le monde. Lorsque de telles conventions existent, chaque développeur peut regarder quelques lignes de code et comprendre immédiatement ce qui se passe. Cela nous permet également de créer de nouvelles fonctionnalités sur une base solide à l’avenir.
Une chose à ne pas négliger de l’annonce est la mention de theme.json:
Avec les récents progrès de Gutenberg, les styles globaux et un effort pour consolider les options et les interfaces utilisateur dans l’éditeur de site, une API Webfonts devient une nécessité car elle permettra aux développeurs de thèmes de définir des polices dans leurs fichiers theme.json.
Stathopoulos aussi noté dans la demande de tirage qu’une fois ce correctif terminé, la prochaine étape consisterait à soumettre un nouveau ticket pour l’enregistrement des polices Web lors de l’analyse theme.json.
Le fichier JSON de thème est le code sous-jacent du système de styles global avec lequel de plus en plus d’utilisateurs interagiront dans les mois et les années à venir. Si nous construisons maintenant une API de chargement de polices, cela nous laisse de la place à explorer. Cela peut même ouvrir de futures intégrations dans l’interface utilisateur du backend.
Je ne sais pas encore à quoi cela pourrait ressembler, mais cela ouvrira la voie à un auteur de thème averti pour expérimenter de nouvelles expériences utilisateur autour des polices.
Il ne semble pas y avoir de moyen d’enregistrer des polices commerciales à partir d’API comme Adobe Fonts. Cependant, Stathopoulos a noté l’année dernière que cela pourrait être une possibilité. “Ajouter un argument supplémentaire dans l’un des appels pour permettre de peaufiner les en-têtes de requête (et donc autoriser l’authentification API) est quelque chose que nous pouvons certainement faire”, a-t-il déclaré. a commenté le billet original.
J’aime la proposition. Il peut y avoir quelques problèmes à résoudre, mais plus nous normalisons ces fonctionnalités communes, mieux c’est. Cela crée moins de travail pour les auteurs de thèmes, leur permettant de se concentrer davantage sur la définition de leurs conceptions.
Comme ça:
Comme Chargement…