Container queries e o futuro das telas

De regras do prédio para regras do apartamento

Vamos começar com uma analogia para deixar claro por que container queries são uma evolução importante. Até agora, media queries funcionavam assim: você definia regras baseadas no tamanho da janela do navegador. É como se você morasse em um prédio e todas as regras do condomínio se aplicassem igualmente a todos os apartamentos, independentemente do tamanho. Apartamento de 30m²? Mesmas regras do de 120m². Media queries são as regras do prédio.

Container queries mudam essa lógica. Com elas, cada componente pode ter regras próprias baseadas no tamanho do espaço que ele ocupa, não da página inteira. É como se cada apartamento pudesse definir sua própria organização interna: o de 30m² coloca a mesa na cozinha, o de 120m² tem uma sala de jantar separada. Cada um se adapta ao seu próprio espaço.

Na prática, isso significa que um card de produto pode se reorganizar automaticamente dependendo de onde ele aparece na interface. Na sidebar, com pouco espaço horizontal? A imagem fica em cima e o texto embaixo. Na área principal, com mais espaço? A imagem vai para o lado e o texto fica ao lado dela. O componente sabe quanto espaço tem e se adapta sozinho, sem depender de uma media query que olha para página inteira.

Por que isso importa para você, designer?

Se você trabalha com design systems ou componentes reutilizáveis (e se não trabalha ainda, provavelmente vai trabalhar em breve), container queries mudam a forma como você pensa. Antes, ao criar um componente no Figma, você pensava assim: "em tela de celular, esse card fica empilhado; em desktop, fica lado a lado." Você criava variantes baseadas no tamanho da tela.

Com container queries, a pergunta muda. Em vez de "qual o tamanho da tela?", a pergunta é "quanto espaço esse componente tem disponível?" E essa é uma mudança de paradigma. Um mesmo card pode aparecer pequeno na sidebar de um desktop e grande na área central de um celular. O comportamento do componente depende do contexto local, não do dispositivo.

Na hora de projetar, isso significa documentar não só as variantes por breakpoint de tela, mas também os pontos de adaptação do próprio componente. Quando você entrega um componente para o dev e diz "esse card tem três estados: compacto (abaixo de 280px de largura), médio (280-480px) e expandido (acima de 480px)", você está falando a linguagem de container queries. E o dev vai adorar essa conversa.

Não se preocupe se isso parecer abstrato agora, na prática, container queries são algo que o desenvolvedor implementa. Você só precisa saber que existem para pedir a coisa certa.

Telas dobráveis e o fim do tamanho previsível

E a coisa fica ainda mais interessante quando você considera as telas dobráveis. O Galaxy Fold, por exemplo, tem uma tela externa estreita e uma tela interna que, quando aberta, funciona quase como um tablet. O usuário pode abrir e fechar o celular a qualquer momento, e o layout precisa se adaptar instantaneamente.

Pense comigo: com media queries tradicionais, você precisaria prever cada combinação possível de tamanho de tela. Tela dobrada? Tela aberta? Tela aberta mas com o app dividindo espaço com outro? São cenários demais. Com container queries, o componente não precisa saber se está em um Fold aberto ou em um iPhone. Ele só precisa saber quanto espaço tem disponível e se reorganizar de acordo.

Essa é a direção que o design adaptativo está tomando em 2026: menos regras globais, mais inteligência local em cada componente.

Viewport units modernos: dvh, svh, lvh

Enquanto container queries resolvem o problema no nível dos componentes, existe outro problema no nível da página que você provavelmente já enfrentou sem saber o nome. Sabe quando você usa 100vh no CSS para criar uma seção que ocupa a tela inteira, e no celular ela fica maior do que deveria porque a barra de endereço do navegador está no caminho? Pois é. O vh (viewport height) clássico não considera essas barras dinâmicas dos navegadores mobile.

Por isso surgiram três novas unidades:

• dvh (Dynamic Viewport Height): se ajusta em tempo real conforme a barra de endereço aparece ou desaparece. Parece a opção ideal, mas esse ajuste tem custo: o layout "pula" quando a barra some ou reaparece durante o scroll. Por isso a recomendação é usar com moderação, em casos específicos como interfaces de chat ou barras fixas no rodapé.
• svh (Small Viewport Height): assume que todas as barras do navegador estão visíveis. Calcula o menor tamanho garantido de tela. É a escolha segura na maioria dos casos, especialmente para seções que precisam caber inteiras na tela, como heroes.
• lvh (Large Viewport Height): assume que todas as barras estão escondidas. Calcula o maior tamanho possível. Útil para backgrounds e seções visuais que podem sangrar um pouco.

Como designer, você não vai escrever 100dvh no código. Mas precisa saber que isso existe, porque afeta diretamente decisões de layout. Quando você cria uma landing page com uma seção hero que deveria ocupar exatamente a tela inteira no celular, e na implementação ela fica com scroll ou com conteúdo cortado, o problema pode ser o vh. E se você souber perguntar "vocês estão usando svh em vez de vh?", o dev vai saber que você entende do assunto.