The tablet stopped being a tablet, and device breakpoints with it

Your design assumes three widths. An iPad does not.

That stopped being true with iPadOS 26, when Apple swapped Split View and Slide Over for freely resizable windows with macOS-style controls, added a menu bar and made external displays useful. iPadOS 27, out on 14 September, is mostly about speed, and Apple's own note picks out closing, switching and dragging windows during multitasking.

Which leaves a window that goes wherever somebody drags it.

A media query asks the wrong question

Picture 2013. The iPad is 1,024 points wide, phones are 320 and laptops 1,280. You write @media (min-width: 768px) and everyone reads it as tablet. It works, because screen size reliably told you what kind of machine was on the other end.

Apple has very little to do with that assumption dying. Windows split view kills it. So does Samsung DeX, a browser dragged into a third of a wide monitor, a Teams side panel, a report embedded in someone else's page through an iframe, and the foldable phone we wrote about separately.

Screen width no longer carries information about who is looking and with what. It is a width.

Your components want a different number. How much room did this particular component get. A product card in a four-across grid is 280 points wide on a forty-inch monitor, the same card inside an order detail gets 900, and a media query knows none of it, because it is busy asking the window.

Where it hurts most

Marketing sites ride it out. One column of text, a few images, nothing to argue about.

It hurts inside business systems, where the same component turns up in four places at four widths. A full-page order table and the same table in a sidebar. A dashboard chart that also has to render into an exported report. A form that lives on its own page until somebody opens it inside a modal.

Media queries cannot hold that together. The component has no idea what context it is in, so it reads the screen and gets at least one of those four placements wrong. That is where most of the tickets in the "the table looks weird on tablet" genre actually come from.

Container queries ask properly

Instead of the screen, the component asks its parent how much room it got.

.panel {
  container-type: inline-size;
  container-name: panel;
}

@container panel (min-width: 40rem) {
  .order-table {
    display: table;
  }
}

@container panel (max-width: 40rem) {
  .order-table {
    display: block;
  }
}

The same table is now right on a full page and right in a sidebar, and nobody had to know what it was running on. Container queries have been Baseline in browsers since February 2023, three and a half years ago. Style queries joined them in May 2026 when Firefox 151 shipped the last missing piece, so a component can react to a custom property set on an ancestor too.

None of which touches navigation. A main menu sizes itself against the whole window and a media query is still the right tool there, along with the overall arrangement of the screen. Touch targets are a separate question again, and @media (pointer: coarse) is the one that answers it. Nine hundred points tells you nothing about whether a mouse or a thumb is aiming at the thing, which is exactly the trap an unfolded phone sets.

Four things nobody warns you about

A container cannot query itself. To change an element based on its own width you have to wrap it and make the wrapper the container, which in practice is one extra div every time you do it.

Grid items have the same restriction. Do not make one the container, or the sizing chases its own tail.

Flexbox will happily make content disappear. The container needs explicit or intrinsic sizing information, or it collapses to nothing, the page looks empty, and the whole thing presents as a crash when a single width is all that is missing.

And a custom property in the condition does not work. @container (min-width: var(--tablet)) looks valid and quietly never applies.

Where to start and what it costs

One file per component, usually an afternoon.

Start with three that appear in more than one place. There is almost always a table, a card and a filter panel among them. Convert those and leave everything else alone.

Why this never gets decided

Device media queries do not take a system down. They produce a steady drip of tickets saying that something looks odd somewhere, and every one of them gets caught, reproduced and fixed on its own.

Over a year that is more work than converting three components. It never shows up as a single budget line, though, so it never gets decided and keeps being paid for in instalments.

If you are tidying the system anyway, this sits near the front of the work we do during software modernization. And you can find out in two minutes whether it applies to you, by taking one component and dropping it into half the width. What else belongs in a page built with some care is in our ten points.