Um card de serviço pode ter 310 pixels disponíveis em um monitor de 27 polegadas e 360 pixels em um celular. A diferença vem do lugar que ele ocupa na página. Com container queries no CSS, o card reorganiza imagem, texto e ações conforme a largura de um contêiner ancestral definido pela equipe. Isso permite usar o mesmo componente em uma grade, numa coluna lateral e em uma página de busca.

Quando olhar para o contêiner em vez da tela?

Imagine uma empresa de arquitetura com três lugares para exibir seus projetos. A página inicial tem uma grade de três colunas. A página de um projeto reserva uma coluna estreita para trabalhos relacionados. Já a página de categoria oferece uma listagem ampla, com a foto ao lado da descrição. As três áreas mostram os mesmos dados, mas pedem arranjos diferentes.

Se o card usar apenas a largura da janela para trocar de arranjo, um monitor amplo poderá acionar o modo horizontal até dentro da coluna lateral. A foto e o texto começam a disputar espaço. Uma consulta ao contêiner permite que a grade e a coluna lateral exibam o modo empilhado enquanto a listagem usa o modo horizontal na mesma janela.

A documentação do MDN sobre container queries apresenta essa diferença de escopo. O panorama CSS Wrapped do Chrome mostra um contexto mais amplo de evolução das ferramentas nativas de layout que as equipes podem incorporar ao trabalho em 2026.

Como definir o ponto em que o card muda de formato?

Monte o card empilhado primeiro. Reserve uma área para a foto, coloque o nome em seguida e mantenha a ação perto da informação que motiva o clique. Use o maior título que o CMS permite publicar e inclua pelo menos um exemplo com descrição em duas ou três linhas. Teste ainda o card sem foto e com uma imagem cuja área principal esteja próxima da borda.

Para o modo horizontal, some a largura mínima necessária para a imagem, a largura em que o texto continua confortável e o espaço entre as duas áreas. Se os testes pedirem 160 pixels para a foto, 245 para a informação e 24 de distância, você tem uma referência inicial de 429 pixels antes de considerar o preenchimento interno. O ponto final depende dos valores reais do seu componente.

Teste perto da fronteira, em especial um pouco antes e um pouco depois da mudança. Um layout pode parecer ótimo nos exemplos de 320 e 640 pixels e quebrar logo depois de cruzar seu limiar. Deixe o cartão crescer em altura quando o conteúdo pedir. A quebra de linha faz parte do arranjo e deve entrar nos critérios de revisão.

Como aplicar container queries sem multiplicar variantes?

Use uma camada externa para definir o contexto de consulta. Nela, declare container-type: inline-size e dê um nome por meio de container-name. A camada interna contém a imagem e o bloco de conteúdo. Em @container projeto (min-width: 28rem), por exemplo, a equipe pode alterar a grade interna para exibir dois grupos lado a lado. O valor é ilustrativo e precisa refletir o teste com conteúdo real.

A consulta usa um ancestral elegível do elemento estilizado. Por isso, vale separar a camada que fornece o tamanho da camada que recebe o novo arranjo. Nomear o contêiner também ajuda quando o card está dentro de uma seção que já declara o próprio contexto de consulta. Teste o componente nessa situação, especialmente se o site usa grades aninhadas.

Mantenha a base empilhada fora da regra. Ela fornece uma apresentação utilizável caso a consulta não seja aplicada. Quando a regra entrar, altere apenas o que depende da largura, como a disposição das colunas e o recorte da imagem. Um bom ponto de partida para registrar essa divisão é o guia da IV Criativa sobre design systems simples no Figma.

O que deve permanecer igual nos dois arranjos?

Preserve a ordem de leitura do conteúdo no HTML. Se o nome e a descrição dão contexto ao botão, essa relação deve continuar na versão horizontal. A grade pode posicionar a imagem em uma coluna separada enquanto a sequência de título, texto e ação permanece previsível no teclado. Percorra o card e os cartões vizinhos com Tab para verificar a sequência na página inteira.

Use o mesmo conjunto de informações essenciais nos dois modos. Em um card de portfólio, retirar a cidade ou o tipo de projeto para o texto caber pode levar a cliques em trabalhos irrelevantes. Para um catálogo B2B, a referência do item pode ser o dado mais útil quando a pessoa precisa encaminhar um orçamento. A organização de um catálogo digital B2B ajuda a decidir quais dados merecem permanecer.

Separe recorte de dimensionamento. A equipe pode aproveitar uma foto mais alta no modo empilhado e uma janela mais contida no modo horizontal, desde que o enquadramento preserve o produto, a pessoa ou a obra. Revise as fotos que têm menos margem. Elas revelam problemas que as imagens escolhidas especificamente para o protótipo costumam esconder.

Como testar com dados que vêm do CMS?

Crie um conjunto curto de cards com variações previsíveis. Inclua o título mais longo do acervo, uma etiqueta extensa, um item sem imagem e outro cujo texto tenha siglas. Adicione uma peça com caracteres acentuados e um título com palavra comprida sem espaço. Para uma loja, acrescente preços que ocupam larguras diferentes e mensagens de disponibilidade.

Coloque esse conjunto em páginas onde o componente já vive. Reduza a largura da janela e depois mantenha a janela fixa enquanto altera o espaço da coluna que hospeda o card. Esse segundo teste revela dependências indevidas da tela. Aumente o zoom e confira se os textos continuam legíveis, se os botões cabem e se as fotos ficam contidas em suas áreas.

Registre os resultados por faixa de largura e pelo tipo de falha observado. Se 420 pixels acomodam o conteúdo comum, mas fazem o título de um projeto específico encostar no botão, o relatório precisa indicar qual dado provocou o problema. A solução pode ser mudar a estrutura interna, aceitar uma linha adicional ou adiar a troca para o modo horizontal.

Media queries e container queries podem coexistir?

Sim. Use media queries para decisões ligadas à janela e às preferências do dispositivo, como a navegação global e a preferência por movimento reduzido. Use container queries para escolhas que mudam quando um componente recebe outra largura dentro da mesma página. A mesma grade geral pode empilhar a coluna lateral em telas menores, enquanto cada card avalia o espaço que ganhou depois dessa mudança.

Evite começar com muitos limiares. Uma base empilhada e um modo horizontal costumam oferecer uma primeira entrega fácil de testar. Se surgir um terceiro arranjo, descreva primeiro qual problema de conteúdo ele resolve. Um selo que cabe em uma linha adicional raramente justifica manter uma versão inteira do componente, com novas combinações para revisar.

Escolha um card usado em pelo menos dois contextos, anote o espaço mínimo que cada arranjo precisa e faça o teste com conteúdo do CMS. A implementação estará pronta para reutilização quando o card responder ao espaço disponível, preservar seus dados essenciais e continuar navegável em cada página que o hospeda.

Como documentar a regra para quem mantém o site?

No arquivo de design, mostre o card em três contextos reais e informe a largura disponível em cada um. Use o mesmo conteúdo nas três telas para que a equipe consiga comparar a reorganização. Inclua também um exemplo com descrição longa e uma nota sobre a ordem de leitura. Essa documentação dá ao desenvolvimento um critério mais preciso do que uma lista de tamanhos de aparelhos.

No CMS, descreva a orientação de recorte e mostre onde inserir a informação principal. Se o card precisar de mais espaço sempre que uma etiqueta editorial muda, revise a própria etiqueta com quem publica. O componente fica mais fácil de manter quando a regra visual e a orientação de conteúdo resolvem o mesmo problema.