Bootstrap Responsive Classes: From visible-xs to Container Queries

Back in 2016, I answered a question on Stack Overflow in Portuguese about Bootstrap 3’s responsive visibility classes — visible-xs, hidden-md, and friends. It scored 5 upvotes, which made sense because every Bootstrap project hit this wall at some point: you needed an element to show on phones but vanish on tablets, or vice versa, and the class names were confusing.

The answer helped people. But the entire model it was built on — viewport-based show/hide utilities — has been replaced by something fundamentally better.

The 2016 Problem: A Matrix of Visibility Classes

Bootstrap 3 shipped a grid of responsive visibility classes that tried to cover every breakpoint combination:

<!-- 2016: Bootstrap 3 responsive visibility -->
<div class="visible-xs hidden-sm hidden-md visible-lg">
  Show on phones and desktops, hide on tablets
</div>

<p class="hidden-xs visible-sm">Only show on small tablets</p>

The naming was confusing. visible-xs meant “visible only on extra-small screens,” but hidden-md meant “hidden on medium screens and nothing else.” You couldn’t combine them intuitively. If you wanted something visible on xs and lg but hidden on sm and md, you needed to stack multiple classes and hope you got the logic right.

It got worse with visible-xs-block, visible-xs-inline, and visible-xs-inline-block — variants that controlled the display property when the element was visible. That was nine classes just for extra-small screens.

What Made It Painful

The core issue was that Bootstrap 3 tied visibility to exact breakpoints:

1. Breakpoint-specific logic — Each class targeted one breakpoint, so complex visibility required stacking 3-4 classes
2. No component awareness — Classes responded to the viewport, not to the container the element lived in
3. Display property coupling — You had to choose between block, inline, and inline-block variants, mixing layout concerns with visibility concerns
4. Maintenance nightmare — Changing your breakpoint strategy meant auditing every visible-* and hidden-* class in the project

I remember projects where the responsive class combinations were so convoluted that developers added comments above each div explaining what would show where. That’s a code smell.

The 2026 Approach: Utility Classes and Container Queries

Bootstrap 5 simplified the model, and native CSS went further.

Bootstrap 5 Display Utilities

<!-- 2026: Bootstrap 5 — cleaner, composable utilities -->
<div class="d-none d-md-block">Hidden on small screens, visible from md up</div>

<div class="d-block d-lg-none">Visible on small screens, hidden from lg up</div>

One consistent pattern: start with a base state, then override at specific breakpoints. No more separate visible-* and hidden-* families. Just d-none and d-{breakpoint}-{value}. Much easier to reason about.

Native CSS Container Queries

But the real game-changer is @container:

/* 2026: Container queries — respond to parent, not viewport */
.card-container {
  container-type: inline-size;
}

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

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

This is what we always actually wanted. Components that adapt based on their own available space, not the viewport. A sidebar card can show extra details when it has room, and hide them when it doesn’t — regardless of screen size.

What Changed

The shift is from global responsive rules to local component awareness. Bootstrap 3 asked “how wide is the screen?” Bootstrap 5 asks “at which breakpoint should behavior change?” Container queries ask “how much space does this component actually have?”

That Stack Overflow answer solved the immediate problem. But the real lesson is that responsive design works best when components own their own layout logic, not when a global framework dictates it.