A API do WordPress Web Fonts chegou

A jornada em direção a uma API de fontes da web no WordPress tem sido uma montanha-russa de emoções para os desenvolvedores. Depois de ser retirado do lançamento do WordPress 5.9, ele foi movido para o projeto Gutenberg, onde poderia ser construído juntamente com recursos relacionados que dependiam dele.

A API foi incorporada ao plugin Gutenberg e deve chegar à versão 12.8. Os autores de temas que desejam testá-lo podem clonar a versão dev do plugin ou baixar a versão noturna do Gutenberg Times.

Jono Alderson abriu o tíquete original para uma API de fontes da web em fevereiro de 2019. No entanto, foi só no final de 2021 que ganhou uma massa de suporte e desenvolvimento. Pela maioria das contas, a API parecia pronta para ser enviada com o WordPress 5.9. No entanto, foi suspenso por Andrew Ozz, um dos principais desenvolvedores do WordPress.

Não foi uma decisão popular, mas pode ter sido a melhor direção. A API era limitada porque ainda não tinha suporte para theme.json . Estar disponível apenas através do PHP significava que os autores do tema estariam fazendo principalmente o que sempre fizeram – lançando sua própria solução. Este não foi o atraso para sua revelação, mas provavelmente será o caso de uso mais comum da API.

Enquanto muitos queriam ver esse recurso chegar ao WordPress 5.9, os meses extras deram tempo para evoluir para uma API mais limpa que se integra ao site e aos editores de conteúdo.

Os autores de temas agora podem definir definições de face de fonte junto com suas famílias correspondentes em arquivos theme.json , e o WordPress carregará automaticamente o CSS @font-face necessário no editor e no front-end. Eu testei isso extensivamente e não tive problemas.

A desvantagem potencial é que o recurso é fornecido apenas com suporte para um provedor local, o que significa que as fontes devem ser empacotadas com o tema. Um provedor do Google Fonts fazia parte da implementação original, mas foi removido posteriormente.

Ozz entra em mais detalhes em um ticket anterior, mas sua recomendação era abandonar o suporte do Google Fonts por enquanto:

Adicione suporte apenas para fontes locais por enquanto. Se o WordPress decidir incluir suporte para o Google CDN posteriormente, a implementação terá que considerar as leis e restrições de privacidade da web e estar vinculada a uma eventual API de consentimento do usuário, etc.

Artigo relacionado: Tribunal alemão multa proprietário do site por violar o GDPR usando fontes hospedadas pelo Google

Ari Stathopoulos, um dos desenvolvedores por trás da API de fontes da web, explicou que agrupar uma solução no núcleo que grava os arquivos de fonte diretamente no servidor melhoraria a privacidade:

Em vez de removê-lo, talvez possamos implementá-los corretamente, aplicando fontes da Web hospedadas localmente para melhorar o desempenho e a privacidade? Dessa forma, estaríamos dando um bom exemplo e veríamos uma melhoria significativa de desempenho e privacidade no ecossistema WP, pois temas e plug-ins que atualmente usam fontes do Google, fontes da Adobe e outros enfeites começarão a adotar a API.

Por enquanto, parece que as fontes locais são oficialmente suportadas, mas os autores de temas e plugins devem registrar provedores personalizados. Um medo de deixar de fora o suporte do Google Fonts é que haverá muitas soluções concorrentes em estado selvagem, em vez de um provedor sólido em que todos possam confiar. Quanto mais desenvolvedores constroem suas próprias rodas, é mais provável que diferentes implementações sejam enviadas com bugs ou problemas de segurança.

A Automattic já tem um patch de rascunho para um provedor do Google para Jetpack. Supondo que seja inserido no plug-in, sem dúvida entrará em conflito com um tema no caminho que registre seu próprio ID de provedor do google .

Apenas o suporte a fontes locais também pode criar tamanhos de download de temas maiores. Para muitos temas, isso não deve ser um problema. Um, dois ou três pacotes de fontes são razoáveis. No entanto, se as variações globais de estilo se tornarem populares, poderemos ver temas que enviam dezenas de fontes para cobrir vários designs pré-empacotados. Isso levará rapidamente a arquivos de tema inchados e, combinado com imagens suficientes, os autores do tema podem atingir o limite de 10 MB para envio ao diretório. Isso parece um pouco com o problema de amanhã, mas é algo para começar a pensar hoje.

Ainda existem alguns problemas que precisam ser resolvidos em torno da API. No entanto, passar por isso no início do ciclo de lançamento do WordPress 6.0 dará a todos tempo para testar e ajudar a melhorá-lo.

Testando fontes agrupadas

Existem dois métodos para registrar fontes da web com o WordPress. Para autores de temas, a solução mais simples é defini-los por meio de seus arquivos theme.json . Este é o método que abordarei abaixo, pois o arquivo é padrão desde o WordPress 5.8. Há um exemplo de PHP no ticket de pull request.

As chaves e valores theme.json correspondem principalmente à regra CSS @font-face . Os autores do tema devem retocá-lo se já faz um tempo desde que o usaram.

Para testar, registrei três fontes da web por meio do meu tema e a captura de tela a seguir mostra-as em ação no editor:

As fontes da Web devem ser registradas em settings.typography.fontFamily como parte de uma definição de família de fontes específica. Segue uma cópia do código que estou testando em um dos meus temas usando a fonte Cabin:

 { "settings": { "typography": { "fontFamilies": [ { "fontFamily": "\"Cabin\", sans-serif", "slug": "primary", "name": "Primary", "fontFace": [ { "fontFamily": "Cabin", "fontWeight": "400 700", "fontStyle": "normal", "src": [ "file:./public/fonts/cabin/Cabin-VariableFont_wdth,wght.ttf" ] }, { "fontFamily": "Cabin", "fontWeight": "400 700", "fontStyle": "italic", "src": [ "file:./public/fonts/cabin/Cabin-Italic-VariableFont_wdth,wght.ttf" ] } ] } ] } } }

Observe que file:./public/fonts/*.ttf é relativo à pasta do tema. Os autores do tema precisam ajustar isso para se adequar à estrutura do tema.