O WordPress 7.1, lançado em 19 de agosto de 2026, passou a permitir estilos responsivos de blocos para Tablet e Mobile diretamente no sistema de estilos. Na prática, isso abre duas trilhas: quem edita páginas pode alterar propriedades por viewport sem escrever media queries à mão; quem desenvolve temas pode definir os mesmos estados no theme.json e ainda ajustar os limites de Mobile e Tablet.
A lógica é desktop-first. O estilo normal do bloco é a base e continua valendo em todos os tamanhos até que uma propriedade seja sobrescrita em @tablet ou @mobile. Por isso, não existe uma chave @desktop.
Quais breakpoints o WordPress 7.1 usa por padrão
| Estado | Faixa padrão | O que acontece |
|---|---|---|
| @mobile | largura ≤ 480px | Os valores definidos em Mobile substituem a base dentro dessa faixa. |
| @tablet | 480px < largura ≤ 782px | Os valores de Tablet se aplicam acima de Mobile e até o limite de Tablet. |
| Base | acima de 782px, por padrão | Não usa uma chave especial; é o estilo normal do bloco. |
Esses limites podem ser alterados pelo tema. A documentação oficial também deixa claro que os breakpoints configurados são usados tanto pelos estilos responsivos quanto pela visibilidade de blocos e aparecem na pré-visualização de dispositivos do editor.
Trilha 1: usar estilos responsivos diretamente no editor
Para uma edição pontual, o fluxo mais simples é trabalhar pelo seletor de dispositivo do editor. Ative a edição responsiva, mude a prévia para Tablet ou Mobile e então ajuste uma propriedade de estilo do bloco. A mudança fica associada ao viewport ativo.
- No editor de blocos, abra o seletor de visualização de dispositivo na barra superior.
- Ative Responsive editing (edição responsiva).
- Selecione Tablet ou Mobile, ou redimensione a área de edição até a faixa desejada.
- Selecione um bloco com suporte de estilo e altere uma propriedade, como tamanho da fonte, cor, borda, espaçamento, dimensões ou layout.
- Volte ao Desktop para confirmar que o valor-base foi preservado.
- Confira também o outro viewport menor para verificar se ele herdou a base ou recebeu uma sobrescrita própria.
O comportamento é de herança: se você definir um tamanho de fonte no Desktop e não alterar esse campo em Tablet ou Mobile, o mesmo valor continua valendo. Só a propriedade modificada no viewport menor é sobrescrita.
O que é responsivo e o que continua global
Os estados responsivos se aplicam a propriedades expostas pelos suportes de estilo dos blocos, como tipografia, cor, fundo, borda, dimensões, espaçamento e layout. Isso não significa que todo controle da interface se torne automaticamente específico por viewport. Nos testes oficiais do WordPress 7.1, por exemplo, controles da barra do bloco, como alinhamento, continuavam valendo para todos os dispositivos, enquanto os ajustes de estilo do inspetor lateral eram o foco da edição por viewport.
Trilha 2: declarar @mobile e @tablet no theme.json
Autores de temas podem gravar os estados responsivos junto aos estilos de cada bloco. O exemplo abaixo mantém um padding de 3rem como base e o reduz para 1rem apenas em Mobile:
{
"styles": {
"blocks": {
"core/group": {
"spacing": { "padding": { "top": "3rem", "right": "3rem", "bottom": "3rem", "left": "3rem" } },
"@mobile": { "spacing": { "padding": { "top": "1rem", "right": "1rem", "bottom": "1rem", "left": "1rem" } } }
}
}
}
}
O mesmo padrão pode ser usado com @tablet. Também é possível combinar viewport com pseudoestado: a ordem documentada é viewport primeiro e pseudoestado depois, como @mobile contendo :hover.
Como mudar os breakpoints com settings.viewport
Os limites são configurados no nível superior de settings, não dentro de um bloco específico. Por exemplo:
{
"settings": {
"viewport": {
"mobile": "30rem",
"tablet": "45rem"
}
}
}
Com os dois valores válidos, isso gera uma faixa Mobile até 30rem e uma faixa Tablet acima de 30rem e até 45rem. O restante continua usando a base.
Quais unidades são aceitas
O WordPress 7.1 aceita comprimentos numéricos não negativos em px, em ou rem. Percentuais, valores sem unidade, funções CSS e outras unidades são ignorados. Assim, valores como 480px, 30em e 30rem são compatíveis; já 50%, 480 ou uma expressão com função CSS não atendem à regra documentada.
O que acontece se o breakpoint for inválido
- Se apenas Mobile ou apenas Tablet for válido, o estado válido mantém seu nome e vira uma consulta de largura máxima única.
- Se nenhum dos dois for válido, o WordPress volta aos padrões de 480px e 782px.
- Se Mobile e Tablet forem válidos, mas Tablet for menor ou igual a Mobile, apenas o breakpoint Mobile é usado.
- settings.viewport é global ao tema; não pode ter valores diferentes para cada tipo de bloco.
Por que não existe @desktop
A ausência de @desktop evita duplicar o estilo-base. Se um Group tem padding de 3rem na declaração normal, esse valor é o ponto de partida em qualquer largura. Um @tablet pode trocar apenas o padding, enquanto cor, borda e outras propriedades continuam herdadas. Um @mobile pode sobrescrever novamente apenas o que precisar.
Esse detalhe é importante para evitar configurações verbosas e para entender a cascata: Tablet e Mobile são exceções à base, não três conjuntos independentes de estilos.
Quando usar o editor e quando usar theme.json
| Cenário | Melhor ponto de partida |
|---|---|
| Ajuste visual de um bloco específico em uma página | Editor, com edição responsiva ativada. |
| Regra que deve valer para todas as instâncias de um tipo de bloco | Global Styles ou theme.json. |
| Padronizar breakpoints para o site inteiro | settings.viewport no theme.json. |
| Alterar apenas Desktop | Edite o estilo-base; não procure por @desktop. |
Checklist antes de publicar
- Confirme que o site está em WordPress 7.1 ou versão compatível com o recurso.
- Defina primeiro a base e depois apenas as exceções de Tablet e Mobile.
- Evite criar breakpoints diferentes por componente: o WordPress usa os valores globais de settings.viewport.
- Valide as unidades e a ordem Mobile < Tablet.
- Teste no seletor de dispositivo e também redimensionando o navegador no front-end.
- Verifique se propriedades não sobrescritas continuam herdando corretamente a base.
Fontes oficiais
A implementação e os limites foram documentados nas notas de desenvolvimento do WordPress 7.1 em Responsive block styles and configurable viewports in WordPress 7.1, no Theme.json Version 3 Reference e no guia de Global Settings & Styles. O fluxo de uso no editor também foi detalhado no Call for Testing: Responsive Styling. O lançamento final do WordPress 7.1 ocorreu em 19 de agosto de 2026, conforme o anúncio oficial da versão.
