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

Your design assumes three widths. An iPad does not.

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

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 and phones are 320, with laptops out at 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, and how unlikely that width was to change before the session ended.

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.

Business systems are where it hurts. The same component turns up in four places at four widths, and the code has no way to tell them apart. A full-page order table, the same table in a sidebar, a dashboard chart that also renders into an exported report, and finally the form nobody thinks about until the modal opens.

Media queries cannot hold that together. The component has no idea what context it is in. It reads the screen instead, 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, and why they are so hard to reproduce on somebody else's machine.

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.

This is not new. Container queries have been Baseline in browsers since February 2023. That is three and a half years. Style queries joined them in May 2026, when Firefox 151 shipped the last missing piece, so components can react to custom properties 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 looks like the app crashed when the only thing missing is width.

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 the three that show up in more than one place. A table and a card are nearly always on that list, the filter panel usually joins them, and those three cover most of the places where the layout decision is currently made against the wrong number. Convert them 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. Each one gets caught and reproduced separately, and then somebody has to work out how wide the window was before they can even start on the fix.

Over a year that is more work than converting three components. It never shows up as a single budget line, though, so nobody decides it, and the bill keeps arriving in instalments too small for anyone to query.

If you are tidying the system anyway, this sits near the front of the work we do during software modernization, because it is cheap, and the result shows up in every place that component lives. Two minutes will tell you whether it applies to you. Take one component and drop it into half the width. What else belongs in a page built with some care is in our ten points.