Classes Responsivas do Bootstrap: De visible-xs a Container Queries

La em 2016, respondi uma pergunta no Stack Overflow em Portugues sobre as classes de visibilidade responsiva do Bootstrap 3 — visible-xs, hidden-md e companhia. Recebeu 5 votos, o que fazia sentido porque todo projeto Bootstrap esbarrava nisso em algum momento: voce precisava que um elemento aparecesse no celular mas sumisse no tablet, ou vice-versa, e os nomes das classes eram confusos.

A resposta ajudou as pessoas. Mas o modelo inteiro no qual ela foi construida — utilitarios de mostrar/esconder baseados em viewport — foi substituido por algo fundamentalmente melhor.

O Problema de 2016: Uma Matriz de Classes de Visibilidade

O Bootstrap 3 vinha com uma grade de classes de visibilidade responsiva que tentava cobrir cada combinacao de breakpoint:

<!-- 2016: Visibilidade responsiva do Bootstrap 3 -->
<div class="visible-xs hidden-sm hidden-md visible-lg">
  Mostra no celular e desktop, esconde no tablet
</div>

<p class="hidden-xs visible-sm">So mostra em tablets pequenos</p>

A nomenclatura era confusa. visible-xs significava “visivel apenas em telas extra-pequenas”, mas hidden-md significava “escondido em telas medias e nada mais.” Nao dava para combinar intuitivamente. Se voce queria algo visivel em xs e lg mas escondido em sm e md, precisava empilhar varias classes e torcer para acertar a logica.

Piorava com visible-xs-block, visible-xs-inline e visible-xs-inline-block — variantes que controlavam a propriedade display quando o elemento estava visivel. Eram nove classes so para telas extra-pequenas.

O Que Tornava Doloroso

O problema central era que o Bootstrap 3 vinculava visibilidade a breakpoints exatos:

1. Logica por breakpoint — Cada classe mirava um breakpoint, entao visibilidade complexa exigia empilhar 3-4 classes
2. Sem consciencia do componente — As classes respondiam ao viewport, nao ao container onde o elemento vivia
3. Acoplamento de propriedade display — Voce tinha que escolher entre variantes block, inline e inline-block, misturando preocupacoes de layout com visibilidade
4. Pesadelo de manutencao — Mudar sua estrategia de breakpoints significava auditar cada classe visible-* e hidden-* no projeto

Lembro de projetos onde as combinacoes de classes responsivas eram tao convolutas que os devs adicionavam comentarios acima de cada div explicando o que aparecia onde. Isso e um code smell.

A Abordagem de 2026: Classes Utilitarias e Container Queries

O Bootstrap 5 simplificou o modelo, e o CSS nativo foi ainda mais longe.

Utilitarios de Display do Bootstrap 5

<!-- 2026: Bootstrap 5 — utilitarios mais limpos e composiveis -->
<div class="d-none d-md-block">Escondido em telas pequenas, visivel a partir de md</div>

<div class="d-block d-lg-none">Visivel em telas pequenas, escondido a partir de lg</div>

Um padrao consistente: comece com um estado base, depois sobrescreva em breakpoints especificos. Chega de familias separadas visible-* e hidden-*. So d-none e d-{breakpoint}-{valor}. Muito mais facil de raciocinar.

Container Queries Nativas do CSS

Mas a verdadeira virada de jogo e o @container:

/* 2026: Container queries — responde ao pai, nao ao viewport */
.card-container {
  container-type: inline-size;
}

@container (min-width: 400px) {
  .card-details {
    display: block;
  }
}

@container (max-width: 399px) {
  .card-details {
    display: none;
  }
}

Isso e o que a gente sempre quis de verdade. Componentes que se adaptam com base no espaco disponivel, nao no viewport. Um card na sidebar pode mostrar detalhes extras quando tem espaco e esconde-los quando nao tem — independente do tamanho da tela.

O Que Mudou

A mudanca e de regras responsivas globais para consciencia local do componente. O Bootstrap 3 perguntava “qual a largura da tela?” O Bootstrap 5 pergunta “em qual breakpoint o comportamento deve mudar?” Container queries perguntam “quanto espaco esse componente realmente tem?”

Aquela resposta no Stack Overflow resolveu o problema imediato. Mas a licao real e que design responsivo funciona melhor quando componentes sao donos da sua propria logica de layout, nao quando um framework global dita isso.