Usando o novo layout restrito em temas de bloco do WordPress

Um dos principais objetivos do WordPress Site Editor (e, sim, agora é o "nome oficial) é mover o estilo básico do bloco da CSS para JSON estruturado. Os arquivos JSON são legíveis por máquina, o que os torna consumíveis pelo Editor de sites baseado em JavaScript para configurar os estilos globais de um tema diretamente no WordPress.

Ainda não está tudo lá! Se olharmos para o tema padrão Twenty Twenty-Two (TT2), havia dois problemas principais não resolvidos: interações de estilo (como :hover, :active, :focus), E as margens e preenchimento de contêineres de layout. Você pode ver como eles foram corrigidos temporariamente no TT2 style.css arquivo em vez de torná-lo no theme.json arquivo.

WordPress 6.1 corrigi esses problemas e o que eu quero fazer é olhar especificamente para o último. Agora que temos estilos JSON-ificados para as margens e preenchimento de contêineres de layout, isso nos abre para maneiras mais flexíveis e robustas de definir o espaçamento em nossos layouts de tema.

De que espaçamento estamos falando?

Em primeiro lugar, já temos preenchimento de nível raiz que é uma maneira sofisticada de descrever o preenchimento no elemento. Isso é bom porque garante espaçamento consistente em um elemento que é compartilhado em todas as páginas e posts.

Mas há mais do que isso, porque agora temos uma maneira de os blocos ignorarem esse preenchimento e se alinharem em largura total. Isso é graças a alinhamentos com reconhecimento de preenchimento que é um novo recurso opcional em theme.json. Portanto, mesmo se você tiver preenchimento no nível raiz, ainda poderá permitir, digamos, que uma imagem (ou algum outro bloco) saia e ocupe a largura total.

Isso nos leva a outra coisa que obtemos: layouts restritos. A ideia aqui é que qualquer bloco aninhado no layout respeite a largura do conteúdo do layout — que é uma configuração global — e não flua para fora dele. Podemos substituir esse comportamento bloco a bloco com alinhamentos, mas chegaremos lá.

Vamos começar com…

Preenchimento no nível raiz

Novamente, isso não é novo. Tivemos a capacidade de definir preenchimento no elemento em theme.json desde o experimental Plugin Gutenberg introduziu na versão 11.7. Nós o colocamos no styles.spacing objeto, onde temos margin e padding objetos para definir o espaçamento superior, direito, inferior e esquerdo no corpo:

{
  "version": 2,
  "styles": {
    "spacing": {
      "margin": {
        "top": "60px",
        "right": "30px",
        "bottom": "60px",
        "left": "30px"
      },
      "padding": {
        "top": "30px",
        "right": "30px",
        "bottom": "30px",
        "left": "30px"
      }
    }
  }
}

Esta é uma configuração global. Então, se fôssemos abrir o DevTools e inspecionar o elemento, veríamos estes estilos CSS:

body {
  margin-top: 60px;
  margin-right: 30px;
  margin-bottom: 60px;
  margin-left: 30px;
  padding-top: 30px;
  padding-right: 30px;
  padding-bottom: 30px;
  padding-left: 30px;
}

Legal. Mas aqui reside a questão de como podemos permitir que alguns blocos saiam desse espaçamento para preencher a tela inteira, de ponta a ponta. É por isso que o espaçamento está lá, certo? Isso ajuda a evitar que isso aconteça!

Mas, de fato, há muitos casos em que você pode querer quebrar esse espaçamento em uma instância única ao trabalhar no Block Editor. Digamos que colocamos um bloco de imagem em uma página e queremos que ele tenha largura total, enquanto o restante do conteúdo respeita o preenchimento no nível da raiz.

Entrar…

Alinhamentos com reconhecimento de preenchimento

Ao tentar criar o primeiro tema WordPress padrão que define todos os estilos no theme.json arquivo, designer-chefe Kjell Reigstad ilustra os aspectos desafiadores de quebrar o preenchimento de nível de raiz neste Problema do GitHub.

Novos recursos no WordPress 6.1 foram criados para resolver esse problema. Vamos nos aprofundar nos próximos.

useRootPaddingAwareAlignments

Um novo useRootPaddingAwareAlignments propriedade foi criada para resolver o problema. Na verdade, foi introduzido pela primeira vez no plugin Gutenberg v13.8. o pull request original é uma boa cartilha sobre como funciona.

{
  "version": 2,
  "settings": {
    "appearanceTools": true,
    "useRootPaddingAwareAlignments": true,
    // etc.
  },

Logo de cara, observe que esse é um recurso que temos que aceitar. A propriedade é definida como false por padrão e temos que defini-lo explicitamente como true para habilitá-lo. Observe também que temos appearanceTools definido para true tão bem. Isso nos ativa nos controles da interface do usuário no Editor do site para bordas de estilo, cores de link, tipografia e, sim, espaçamento que inclui margem e preenchimento.

Configuração appearanceTools definido para true opta automaticamente os blocos em margem e preenchimento sem ter que definir qualquer um settings.spacing.padding or setting.spacing.margin para true.

quando nós habilitarmos useRootPaddingAwareAlignments, recebemos propriedades personalizadas com valores de preenchimento de raiz que são definidos no elemento na parte frontal. Curiosamente, ele também aplica o preenchimento ao .editor-styles-wrapper class para que o espaçamento seja exibido ao trabalhar no Editor de bloco de back-end. Muito legal!

Consegui confirmar essas propriedades personalizadas do CSS no DevTools enquanto pesquisava.

Possibilitando useRootPaddingAwareAlignments também aplica o preenchimento esquerdo e direito a qualquer bloco que suporte os valores de largura “conteúdo” e “largo” na imagem Estilos globais acima. Também podemos definir esses valores em theme.json:

{
  "version": 2,
  "settings": {
    "layout": {
      "contentSize": "640px",
      "wideSize": "1000px"
    }
  }
}

Se as configurações de Estilos globais forem diferentes do que está definido em theme.json, os Estilos Globais terão precedência. Você pode aprender tudo sobre como gerenciar estilos de tema de bloco no meu último artigo.

• contentSize é a largura padrão para blocos.
• wideSize fornece uma opção de layout “amplo” e estabelece uma coluna mais larga para os blocos se esticarem.

Então, esse último exemplo de código nos dará o seguinte CSS:

/* The default content container */
.wp-container-[id] > * {
  max-width: 640px;
  margin-left: auto !important;
  margin-right: auto !important;
}

/* The wider content container */
.wp-container-[id] > .alignwide {
  max-width: 1000px;
}

[id] indica um número único gerado automaticamente pelo WordPress.

Mas adivinhe o que mais temos? Alinhamento completo também!

.wp-container-[id] .alignfull {
  max-width: none;
}

Veja isso? Ao habilitar useRootPaddingAwareAlignments e definindo contentSize e wideSize, também obtemos uma classe CSS de alinhamento completo para um total de três configurações de contêiner para controlar a largura dos blocos que são adicionados às páginas e postagens.

Isso se aplica aos seguintes blocos específicos de layout: Colunas, Grupo, Conteúdo da postagem e Loop de consulta.

Controles de layout de bloco

Digamos que adicionamos qualquer um dos blocos específicos de layout mencionados acima a uma página. Quando selecionamos o bloco, a interface do usuário de configurações do bloco nos oferece novas configurações de layout com base no settings.layout valores que definimos em theme.json (ou a IU de estilos globais).

Estamos lidando com blocos muito específicos aqui — aqueles que podem ter outros blocos aninhados dentro. Então, essas configurações de layout são realmente sobre como controlar a largura e o alinhamento desses blocos aninhados. A configuração “Blocos internos usam a largura do conteúdo” é habilitada por padrão. Se desativá-lo, então não temos max-width no contêiner e os blocos dentro dele vão de ponta a ponta.

Se deixarmos a opção ativada, os blocos aninhados aderirão ao contentWidth or wideWidth valores (mais sobre isso daqui a pouco). Ou podemos usar as entradas numéricas para definir custom contentWidth e wideWidth valores nesta instância única. Isso é uma grande flexibilidade!

Blocos largos

As configurações que acabamos de ver são definidas no bloco pai. Depois de aninharmos um bloco dentro e selecioná-lo, temos opções adicionais nesse bloco para usar o contentWidth, wideWidth, ou vá em largura total.

Observe como o WordPress multiplica as propriedades personalizadas CSS de preenchimento de nível raiz por -1 para criar margens negativas ao selecionar a opção “Largura total”.

Usando um layout restrito

Acabamos de abordar o novo espaçamento e alinhamentos que obtemos com o WordPress 6.1. Esses são específicos para blocos e quaisquer blocos aninhados dentro de blocos. Mas o WordPress 6.1 também apresenta novos recursos de layout para ainda mais flexibilidade e consistência nos modelos de um tema.

Caso em questão: o WordPress reestruturou completamente seus tipos de layout Flex e Flow e nos deu uma constrangido traçado tipo que torna mais fácil alinhar layouts de bloco em temas usando as configurações de largura de conteúdo na interface do usuário de estilos globais do editor de site.

Layouts flexíveis, de fluxo e restritos

A diferença entre esses três tipos de layout são os estilos que eles geram. Isabel Brison tem uma excelente redação que descreve bem as diferenças, mas vamos parafrasear aqui para referência:

• Disposição do fluxo: Adiciona espaçamento vertical entre blocos aninhados no margin-block direção. Esses blocos aninhados também podem ser alinhados à esquerda, à direita ou ao centro.
• Layout restrito: Mesmo negócio exato de um layout de fluxo, mas com restrições de largura em blocos aninhados com base no contentWidth e wideWidth configurações (seja em theme.json ou estilos globais).
• Esquema flexível: Isso permaneceu inalterado no WordPress 6.1. ele usa Caixa flexível CSS para criar um layout que flua horizontalmente (em uma linha) por padrão, mas também pode fluir verticalmente para que os blocos se empilhem uns sobre os outros. O espaçamento é aplicado usando o CSS gap propriedade.

Essa nova lista de tipos de layout cria nomes de classes semânticas para cada layout:

classe de layout semântico	Tipo de layout	Blocos suportados
.is-layout-flow	Layout de fluxo	Colunas, grupo, conteúdo de postagem e loop de consulta.
.is-layout-constrained	Layout restrito	Colunas, grupo, conteúdo de postagem e loop de consulta.
.is-layout-flex	Layout flexível	Colunas, botões, ícones sociais

Justin Tadlock tem um extenso artigo sobre os diferentes tipos de layout e classes semânticas, incluindo casos de uso e exemplos.

Atualizando seu tema para oferecer suporte a layouts restritos

Se você já estiver usando um tema de bloco de sua própria autoria, você vai querer atualize-o para suportar layouts restritos. Só é preciso trocar algumas coisas em theme.json:

{
  "version": 2,
  "settings": {
    "layout": {
      "type": "constrained", // replaces `"inherit": true`
      "type": "default", // replaces `"inherit": false`
    }
  }
}

Estes são temas de blocos lançados recentemente que habilitaram configurações de espaçamento com useRootPaddingAwareAlignments e ter um atualizado theme.json arquivo que define um layout restrito:

Desativando estilos de layout

Os estilos de layout básicos são recursos padrão fornecidos no WordPress 6.1 Core. Em outras palavras, eles são ativados imediatamente. Mas podemos desativá-los se precisarmos com este pequeno trecho em functions.php:

// Remove layout styles.
add_theme_support( 'disable-layout-styles' );

Grande aviso aqui: desativar o suporte para os tipos de layout padrão também remove todo o estilo básico desses layouts. Isso significa que você precisará criar seus próprios estilos para espaçamento, alinhamentos e qualquer outra coisa necessária para exibir o conteúdo em diferentes contextos de modelo e bloco.

Resumindo

Como um grande fã de imagens de largura total, o novo layout contido do WordPress 6.1 e os recursos de alinhamento com reconhecimento de preenchimento são dois dos meus favoritos até agora. Juntamente com outras ferramentas, incluindo melhor margem e controle de preenchimento, tipografia fluida, e blocos de Lista e Citação atualizados, entre outros, é uma prova sólida de que o WordPress está caminhando para uma melhor experiência de criação de conteúdo.

Agora, temos que esperar e ver como a imaginação e a criatividade de designers comuns e criadores de conteúdo usam essas ferramentas incríveis e as levam a um novo nível.

Por causa das iterações de desenvolvimento do editor de sites em andamento, devemos sempre antecipar um caminho difícil pela frente. No entanto, como otimista, estou ansioso para ver o que acontecerá na próxima versão do WordPress 6.2. Algumas das coisas que estou observando de perto são coisas como características sendo consideradas para inclusão, suporte para posicionamento fixo, novos nomes de classe de layout para invólucros de blocos internos, opções atualizadas de alinhamento do rodapé e adicionando opções de layout restrito e de fluxo aos blocos de cobertura.

Esta Problemas do GitHub nº 44720 lista as discussões relacionadas ao layout programado para WordPress 6.2.

Recursos adicionais

Consultei e fiz referência a muitas fontes enquanto investigava tudo isso. Aqui está uma grande lista de coisas que achei úteis e acho que você também pode gostar.

Tutoriais

Postagens do WordPress

Solicitações e problemas de pull do GitHub