Media query generator with bounds that meet exactly

Because a viewport can be 767.5px wide and neither rule covers it. Both prefixes are inclusive, so an integer pair either collides on the shared value or, once you step the upper one down to 767, opens a window that fractional widths drop into — browser zoom, a scrollbar eating part of a device pixel, or a display whose CSS width simply is not a whole number. Bootstrap 5 subtracts 0.02px instead of 1px for exactly this reason, and chose 0.02 over 0.01 because WebKit rounded the smaller value up (bug 178261). This page will write either subtraction and shows the width of the resulting dead zone in the band table, but the real fix is the range syntax, where the upper bound is exclusive by definition and nothing is subtracted at all.

em, if the layout should follow a reader who enlarged their text. Inside a media query em and rem resolve to the same thing — the browser's initial font size, the value in the user's own settings — and never to the font-size you declared on the html element, because no element style has been computed at the moment the query is evaluated. A reader running a 20px default therefore gets 48em = 960px rather than 768px, and the layout changes when their text genuinely needs the room. A page that sets html { font-size: 62.5% } shows the split most sharply: 1rem is 10px in every declaration and still about 16px in every query. The panel above prints the initial font size measured from this browser next to the root size so you can watch the two disagree.

Yes — Firefox 102 in June 2022, Chrome and Edge 104 in August 2022 and Safari 16.4 in March 2023, so every browser released in the last three years parses it. An engine older than that treats the whole query as invalid and skips the styles inside rather than misapplying them, which is safe but not graceful. If you still support Safari 15 or an aging Android WebView, generate the legacy pair here as well and put it first, or let postcss-media-minmax rewrite the range form into min- and max- prefixes at build time.

Three causes, in the order worth checking. The operating system is not actually in dark mode: the query reports the system or browser setting, so an in-app theme switch has to be a class or a data attribute and cannot be a media query. The page has opted out — a meta color-scheme of light, or color-scheme: only light in CSS, pins the rendering and the query follows suit. Or the condition being tested is (prefers-color-scheme: no-preference), a value the specification kept but no shipping browser reports, which makes the block dead code. The live column in the table tells you which of light and dark this browser is answering with at this moment.

No, and it was never meant to be. pointer describes the primary input device, so a Windows laptop with a touchscreen usually reports pointer: fine while being perfectly touchable, and an iPad flips from coarse to fine the moment a trackpad is attached. Ask any-pointer: coarse whether a touch input exists at all, and pointer: coarse what the user is most likely using right now — the first decides hit-target size, the second decides layout. The same split applies to hover and any-hover, and hover: none is the query that should hide a tooltip which only appears on hover, because on a touchscreen the first tap fires :hover and the second activates the link underneath.

No — it asks for the motion that provokes vestibular symptoms to go, not the feedback that makes an interface readable. The setting exists for large-area movement: parallax, sliding page transitions, zooming, spinning, anything that sweeps a big region of the screen. Cross-fades, color changes and short opacity transitions are the accepted substitutes. The blunt implementation, collapsing every duration to 0.01ms, is what the stylesheet behind this page does and is a fair default for a text site, but on a product interface it also removes the 150ms fade that told someone a panel had opened.

Because a media query contributes no specificity — the rule inside competes on exactly the same terms as the rule outside. Two declarations with the same selector are then settled by source order, so a base rule written after the query wins at every width and the query looks broken. Keep queries below the rules they override, order lower-bound queries from narrow to wide, and note that an !important inside a query still loses to a later !important at the same specificity. When one rule set genuinely has to beat everything else, the cascade layer it sits in is the lever, not the query.