A maneira como escrevemos CSS para temas do WordPress está em meio a mudanças radicais. Recentemente compartilhei uma técnica para adicionando suporte ao tipo fluido no WordPress por meio de theme.json, um novo arquivo que WordPress tem se esforçado muito para se tornar uma fonte central de verdade para definir estilos em temas do WordPress que suportam recursos de edição de site completo (FSE).

Espere, não style.css Arquivo? Ainda temos isso. Na verdade, style.css is ainda é um arquivo necessário em temas de bloco, embora seu papel seja bastante reduzido a meta-informações usadas para registrar o tema. Dito isso, o fato é que theme.json ainda está em desenvolvimento ativo, o que significa que estamos em um período de transição onde você pode encontrar estilos definidos lá, em styles.css ou mesmo no nível do bloco.

Então, como o estilo realmente se parece nesses dias do WordPress FSE? É isso que quero abordar neste artigo. Há uma falta de documentação para temas de blocos de estilo no Manual do desenvolvedor de temas WordPress, então tudo o que estamos cobrindo aqui é o que reuni sobre onde as coisas estão atualmente, bem como discussões sobre o futuro dos temas do WordPress.

A evolução dos estilos do WordPress

Os novos recursos de desenvolvimento incluídos no WordPress 6.1 nos aproximar de um sistema de estilos que são completamente definidos em theme.json, mas ainda há muito trabalho a fazer antes que possamos nos apoiar totalmente nele. Uma maneira de termos uma ideia do que está por vir em versões futuras é usando o Plugin Gutenberg. É aqui que os recursos experimentais geralmente são testados.

Outra maneira de ter uma ideia de onde estamos é observando a evolução da temas padrão do WordPress. Até o momento, existem três temas padrão que suportam a edição completa do site:

Mas não comece a negociar o CSS em style.css para pares de valor de propriedade JSON em theme.json agora mesmo. Ainda existem regras de estilo CSS que precisam ser suportadas em theme.json antes de pensarmos em fazer isso. As questões significativas restantes estão atualmente sendo discutidas com o objetivo de mover completamente todas as regras de estilo CSS para theme.json e consolidar diferentes fontes de theme.json em uma UI para definir estilos globais diretamente no Editor de sites WordPress.

Isso nos deixa em uma situação relativamente difícil. Não só existe nenhum caminho claro para substituir estilos de tema, mas não está claro de onde vem a fonte desses estilos - é de diferentes camadas de theme.json arquivos, style.css, o plugin Gutenberg ou outro lugar?

Sua marca theme.json em vez de style.css?

Você pode estar se perguntando por que o WordPress está se movendo em direção a uma definição de estilos baseada em JSON em vez de um arquivo CSS tradicional. Ben Dwyer, da equipe de desenvolvimento do Gutenberg, articula eloquentemente por que o theme.json abordagem é um benefício para desenvolvedores de temas.

Vale a pena ler o post do Ben, mas a carne está nesta citação:

A substituição de CSS, seja layout, predefinição ou estilos de bloco, apresenta um obstáculo à integração e interoperabilidade: a paridade visual entre o frontend e o editor se torna mais difícil de manter, atualizações para blocos internos podem entrar em conflito com substituições. CSS personalizado é, além disso, menos portátil em outros temas de bloco.

Ao encorajar os autores do tema a usar theme.json API sempre que possível, a hierarquia de estilos definidos “base > tema > usuário” pode ser resolvida corretamente.

Um dos principais benefícios de mover CSS para JSON é que JSON é um formato legível por máquina, o que significa que pode ser exposto na interface do usuário do WordPress Site Editor buscando uma API, permitindo assim que os usuários modifiquem os valores padrão e personalizem a aparência de um site sem escrever qualquer CSS. Ele também fornece uma maneira de estilizar blocos de forma consistente, ao mesmo tempo em que fornece uma estrutura que cria camadas de especificidade de modo que as configurações do usuário tenham a maior prioridade sobre aquelas definidas em theme.json. Essa interação entre estilos de nível de tema em theme.json e os estilos definidos pelo usuário na interface do usuário de estilos globais é o que torna a abordagem JSON tão atraente.

Os desenvolvedores mantêm a consistência no JSON e os usuários ganham flexibilidade com personalizações sem código. Isso é um ganha-ganha.

Existem outros benefícios, com certeza, e Mike McAlister, do WP Engine, lista vários neste tópico do Twitter. Você pode encontrar ainda mais benefícios neste discussão aprofundada no blog Make WordPress Core. E depois de ler isso, compare os benefícios da abordagem JSON com as maneiras disponíveis de definir e substituir estilos em temas clássicos.

Definindo estilos com elementos JSON

Já vimos muito progresso em relação a quais partes de um tema theme.json é capaz de estilizar. Antes do WordPress 6.1, tudo o que podíamos fazer era criar títulos e links. Agora, com o WordPress 6.1, podemos adicionar botões, legendas, citações e títulos para a mistura.

E fazemos isso definindo Elementos JSON. Pense nos elementos como componentes individuais que vivem em um bloco do WordPress. Digamos que temos um bloco que contém um título, um parágrafo e um botão. Essas peças individuais são elementos, e há uma elements objeto em theme.json onde definimos seus estilos:

{
  "version": 2,
  "settings": {},
  // etc.
  "styles": {
    // etc.
    "elements": {
        "button": { ... },
        "h1": { ... },
        "heading": { ... },
    },
  },
  "templateParts": {}
}

Uma maneira melhor de descrever elementos JSON é como componentes de baixo nível para temas e blocos que não precisam da complexidade dos blocos. Eles são representações de primitivos HTML que não são definidos em um bloco, mas podem ser usados ​​entre blocos. Como eles são suportados no WordPress (e no plugin Gutenberg) é descrito no Manual do Editor de Blocos e esta Tutorial completo de edição do site por Carolina Nymark.

Por exemplo, os links são estilizados no elements objeto, mas não são um bloco por si só. Mas um link pode ser usado em um bloco e herdará os estilos definidos no elements.link objeto em theme.json. No entanto, isso não encapsula totalmente a definição de um elemento, pois alguns elementos também são registrados como blocos, como os blocos Heading e Button — mas esses blocos ainda podem ser usados ​​em outros blocos.

Aqui está uma tabela dos elementos que estão atualmente disponíveis para estilizar em theme.json, cortesia de Carolina:

Como você pode ver, ainda é cedo e muito ainda precisa passar do plugin Gutenberg para o WordPress Core. Mas você pode ver como seria rápido fazer algo como estilizar todos os títulos em um tema globalmente sem procurar seletores em arquivos CSS ou DevTools.

Além disso, você também pode começar a ver como a estrutura de theme.json forma camadas de especificidade, indo de elementos globais (por exemplo, headings) a elementos individuais (por exemplo, h1) e estilos de nível de bloco (por exemplo, h1 contidos em um bloco).

Informações adicionais sobre elementos JSON estão disponíveis em esta proposta do Faça WordPress e este bilhete aberto no repositório GitHub do plugin Gutenberg.

Especificidade JSON e CSS

Vamos continuar falando sobre a especificidade do CSS. Mencionei anteriormente que a abordagem JSON ao estilo estabelece uma hierarquia. E é verdade. Estilos que são definidos em elementos JSON em theme.json são considerados estilos de tema padrão. E qualquer coisa que seja definida pelo usuário na interface do usuário de estilos globais substituirá os padrões.

Em outras palavras: estilos de usuário carregam mais especificidade do que estilos de tema padrão. Vamos dar uma olhada no bloco Button para ter uma ideia de como isso funciona.

estou a usar Tema vazio, um tema WordPress em branco sem estilo CSS. Vou adicionar um bloco de botão em uma nova página.

OK, sabemos que o WordPress Core vem com um estilo leve. Agora, vou mudar para o tema TT3 padrão do WordPress 6.1 e ativá-lo. Se eu atualizar minha página com o botão, o botão muda de estilo.

Você pode ver exatamente de onde esses novos estilos estão vindo em TT3 theme.json Arquivo. Isso nos diz que os estilos de elemento JSON têm precedência sobre os estilos do WordPress Core.

Agora vou modificar o TT3 substituindo-o por um theme.json arquivo em um tema filho, onde a cor de fundo padrão do bloco Button é definida como vermelho.

Mas observe o botão de pesquisa na última captura de tela. Deve ser vermelho também, certo? Isso deve significar que é estilizado em outro nível se a alteração que fiz estiver no nível global. Se queremos mudar ambos botões, poderíamos fazê-lo no nível do usuário usando a interface do usuário de estilos globais no editor do site.

Alteramos a cor de fundo de ambos os botões para azul e modificamos o texto também usando a interface do usuário de estilos globais. Observe que o azul a partir daí teve precedência sobre os estilos de tema!

O motor de estilo

Essa é uma ideia muito rápida, mas boa, de como a especificidade do CSS é gerenciada nos temas de bloco do WordPress. Mas não é o quadro completo porque ainda não está claro onde esses estilos são gerados. WordPress tem seus próprios estilos padrão que vêm de algum lugar, consome os dados em theme.json para obter mais regras de estilo e substitui aquelas com qualquer coisa definida em Estilos globais.

Esses estilos são inline? Eles estão em uma folha de estilo separada? Talvez eles sejam injetados na página em um ?

É isso que o novo Mecanismo de estilo espero que resolva. O Style Engine é uma nova API no WordPress 6.1 que visa trazer consistência à forma como os estilos são gerados e onde os estilos são aplicados. Em outras palavras, ele pega todas as fontes possíveis de estilo e é o único responsável por gerar estilos de bloco adequadamente. Eu sei eu sei. Mais uma abstração em cima de outras abstrações apenas para criar alguns estilos. Mas ter uma API centralizada para estilos é provavelmente a solução mais elegante, já que os estilos podem vir de vários lugares.

Estamos apenas dando uma primeira olhada no Style Engine. Na verdade, aqui está o que foi concluído até agora, de acordo com o bilhete:

• Audite e consolide onde o código gera CSS de suporte de bloco no back-end para que sejam entregues do mesmo local (em oposição a vários locais). Isso abrange regras CSS, como margem, preenchimento, tipografia, cores e bordas.
• Remova estilos repetitivos específicos de layout e gere nomes de classes semânticas.
• Reduza o número de tags de estilo embutido que imprimimos na página para suporte a bloco, layout e elemento.

Basicamente, essa é a base para estabelecer uma única API que contém todas as regras de estilo CSS para um tema, de onde quer que elas venham. Ele limpa a maneira como o WordPress injetaria estilos inline pré-6.1 e estabelece um sistema para nomes de classes semânticas.

Mais detalhes sobre os objetivos de longo e curto prazo do Style Engine podem ser encontrados neste Faça a discussão do WordPress Core. Você também pode seguir o problema de rastreamento e Mesa de projeto para mais atualizações.

Trabalhando com elementos JSON

Falamos um pouco sobre elementos JSON no theme.json e como eles são basicamente primitivos HTML para definir estilos padrão para coisas como títulos, botões e links, entre outros. Agora, vamos ver na verdade utilização um elemento JSON e como ele se comporta em vários contextos de estilo.

Os elementos JSON geralmente têm dois contextos: o nível global e os votos de nível de bloco. Os estilos de nível global são definidos com menos especificidade do que no nível de bloco para garantir que estilos específicos de bloco tenham precedência para consistência onde quer que os blocos sejam usados.

Estilos globais para elementos JSON

Vamos dar uma olhada no novo tema TT3 padrão e examinar como seus botões são estilizados. O seguinte é um copiar e colar abreviado do TT3 theme.json arquivo (aqui está o código completo) mostrando a seção de estilos globais, mas você pode encontrar o código original aqui.

{
  "version": 2,
  "settings": {},
    // ...
  "styles": {
    // ...
    "elements": {
      "button": {
        "border": {
          "radius": "0"
        },
        "color": {
          "background": "var(--wp--preset--color--primary)",
          "text": "var(--wp--preset--color--contrast)"
        },
        ":hover": {
          "color": {
            "background": "var(--wp--preset--color--contrast)",
            "text": "var(--wp--preset--color--base)"
          }
        },
        ":focus": {
          "color": {
            "background": "var(--wp--preset--color--contrast)",
            "text": "var(--wp--preset--color--base)"
          }
        },
        ":active": {
          "color": {
            "background": "var(--wp--preset--color--secondary)",
            "text": "var(--wp--preset--color--base)"
          }
        }
      },
      "h1": {
        "typography": { }
      },
      // ...
      "heading": {
        "typography": {
          "fontWeight": "400",
          "lineHeight": "1.4"
      }
      },
      "link": {
        "color": {
          "text": "var(--wp--preset--color--contrast)"
        },
        ":hover": {
          "typography": {
            "textDecoration": "none"
          }
        },
        ":focus": {
          "typography": {
            "textDecoration": "underline dashed"
          }
        },
        ":active": {
          "color": {
            "text": "var(--wp--preset--color--secondary)"
          },
          "typography": {
            "textDecoration": "none"
          }
        },
        "typography": {
          "textDecoration": "underline"
        }
      }
     },
    // ...
  },
  "templateParts": {}
}

Todos os botões são estilizados em nível global (styles.elements.button).

Podemos confirmar isso no DevTools também. Observe que uma classe chamada .wp-element-button é o seletor. A mesma classe também é usada para estilizar os estados interativos.

Mais uma vez, todo este estilo está acontecendo em nível global, vindo de theme.json. Sempre que usarmos um botão, ele terá o mesmo plano de fundo porque eles compartilham o mesmo seletor e nenhuma outra regra de estilo o substitui.

Como um aparte, o WordPress 6.1 adicionou suporte para estilizar estados interativos para certos elementos, como botões e links, usando pseudo-classes em theme.json - Incluindo :hover, :focus e :active — ou a interface do usuário de estilos globais. Engenheiro Automático Dave Smith demonstra esse recurso em um vídeo do YouTube.

Poderíamos substituir a cor de fundo do botão tanto em theme.json (de preferência em um tema filho, pois estamos usando um tema padrão do WordPress) ou nas configurações de Estilos Globais no editor do site (nenhum tema filho é necessário, pois não requer uma alteração de código).

Mas então os botões mudarão de uma só vez. E se quisermos substituir a cor de fundo quando o botão fizer parte de um determinado bloco? É aí que os estilos de nível de bloco entram em jogo.

Estilos de nível de bloco para elementos

Para entender como podemos usar e personalizar estilos no nível do bloco, vamos alterar a cor de fundo do botão que está contido no bloco Pesquisar. Lembre-se, existe um bloco Button, mas o que estamos fazendo é substituir a cor de fundo no nível do bloco Search. Dessa forma, estamos apenas aplicando a nova cor lá, em vez de aplicá-la globalmente a todos os botões.

Para isso, definimos os estilos no styles.blocks objeto em theme.json. Isso mesmo, se definirmos os estilos globais para todos os botões em styles.elements, podemos definir os estilos específicos de bloco para elementos de botão em styles.block, que segue uma estrutura semelhante:

{
  "version": 2,
  // ...
  "styles": {
    // Global-level syles
    "elements": { },
    // Block-level styles
    "blocks": {
      "core/search": {
        "elements": {
          "button": {
            "color": {
              "background": "var(--wp--preset--color--quaternary)",
              "text": "var(--wp--preset--color--base)"
            }
          }
        },
        // ...
      }
    }
  }
}

Vê isso? eu defino o background e text propriedades em styles.blocks.core/search.elements.button com duas variáveis ​​CSS predefinidas no WordPress.

O resultado? O botão de pesquisa agora está vermelho (--wp--preset--color--quaternary), e o bloco Button padrão mantém seu fundo verde brilhante.

Também podemos ver a mudança no DevTools.

O mesmo vale se quisermos estilizar botões que estão incluídos em outros blocos. E os botões são apenas um exemplo, então vamos ver outro.

Exemplo: estilizando títulos em cada nível

Vamos levar todas essas informações para casa com um exemplo. Desta vez, iremos:

• Estilize todos os títulos globalmente
• Estilizar todos os elementos do Título 2
• Estilizar elementos do título 2 no bloco Query Loop

Primeiro, vamos começar com a estrutura básica para theme.json:

{
  "version": 2,
  "styles": {
    // Global-level syles
    "elements": { },
    // Block-level styles
    "blocks": { }
  }
}

Isso estabelece o contorno para nossos estilos globais e de nível de bloco.

Estilize todos os títulos globalmente

Vamos adicionar o headings objetar aos nossos estilos globais e aplicar alguns estilos:

{
  "version": 2,
  "styles": {
    // Global-level syles
    "elements": {
      "heading": {
        "color": "var(--wp--preset--color--base)"
      },
    },
    // Block-level styles
    "blocks": { }
  }
}

Isso define a cor de todos os títulos para a cor base predefinida no WordPress. Vamos alterar a cor e o tamanho da fonte dos elementos Heading 2 no nível global também:

{
  "version": 2,
  "styles": {
    // Global-level syles
    "elements": {
      "heading": {
        "color": "var(--wp--preset--color--base)"
      },
      "h2": {
        "color": "var(--wp--preset--color--primary)",
        "typography": {
          "fontSize": "clamp(2.625rem, calc(2.625rem + ((1vw - 0.48rem) * 8.4135)), 3.25rem)"
        }
      }
    },
    // Block-level styles
    "blocks": { }
  }
}

Agora, todos os elementos do Título 2 são definidos para serem a cor predefinida primária com um tamanho da fonte fluida. Mas talvez nós queremos um fixo fontSize para o elemento Heading 2 quando usado no bloco Query Look:

{
  "version": 2,
  "styles": {
    // Global-level syles
    "elements": {
      "heading": {
        "color": "var(--wp--preset--color--base)"
      },
      "h2": {
        "color": "var(--wp--preset--color--primary)",
        "typography": {
          "fontSize": "clamp(2.625rem, calc(2.625rem + ((1vw - 0.48rem) * 8.4135)), 3.25rem)"
        }
      }
    },
    // Block-level styles
    "blocks": {
      "core/query": {
        "elements": {
          "h2": {
            "typography": {
              "fontSize": 3.25rem
            }
          }
        }
      }
    }
  }
}

Agora temos três níveis de estilos para os elementos Heading 2: todos os títulos, todos os elementos Heading 2 e os elementos Heading 2 que são usados ​​no bloco Query Loop.

Exemplos de temas existentes

Embora tenhamos visto apenas os exemplos de estilo para botões e títulos neste artigo, o WordPress 6.1 suporta o estilo de elementos adicionais. Há uma tabela descrevendo-os no “Definindo estilos com elementos JSON” seção.

Você provavelmente está se perguntando quais elementos JSON suportam quais propriedades CSS, sem mencionar como você as declararia. Enquanto esperamos pela documentação oficial, os melhores recursos que temos serão os theme.json arquivos para temas existentes. Vou fornecer links para temas com base nos elementos que eles personalizam e apontar quais propriedades são personalizadas.

Certifique-se de dar a cada theme.json arquivo uma boa aparência porque esses temas incluem excelentes exemplos de estilo de nível de bloco no styles.blocks objeto.

Resumindo

Mudanças frequentes no editor de site completo estão se tornando uma principais fontes de irritação para muitas pessoas, incluindo usuários de Gutenberg com experiência em tecnologia. Mesmo regras CSS muito simples, que funcionam bem com temas clássicos, não parecem funcionar para temas de bloco por causa da novas camadas de especificidade cobrimos anteriormente.

Em relação a Proposta do GitHub para redesenhar o editor do site em um novo modo de navegador, Sara Gooding escreve em um post do WP Tavern:

É fácil se perder ao tentar contornar o Editor do Site, a menos que você esteja trabalhando dia e noite dentro da ferramenta. A navegação é agitada e confusa, especialmente ao passar da navegação de modelos à edição de modelos e à modificação de blocos individuais.

Mesmo como um aficionado no início do mundo do editor de blocos de Gutenberg e temas de olhos bloqueados, tenho toneladas de minhas próprias frustrações. Estou otimista, no entanto, e prevejo que o editor do site, uma vez concluído, será uma ferramenta revolucionária para usuários e desenvolvedores de temas experientes em tecnologia. este tweet esperançoso já confirma isso. Enquanto isso, parece que devemos estar nos preparando para mais mudanças e talvez até um caminho acidentado.

Referências

Estou listando todos os recursos que usei enquanto pesquisava informações para este artigo.

Elementos JSON

Estilos globais

Mecanismo de estilo

Obrigado por ler! Eu adoraria ouvir suas próprias reflexões sobre o uso dos temas de bloco e como você gerencia seu CSS.