In CSS, how do you express AND, OR, and NOT across @media conditions, and what does the leading only keyword do?

## The anatomy of a query An `@media` rule takes a comma-separated *list* of media queries. Each query is an optional media type (`all`, `print`, `screen`, `speech`) plus zero or more *conditions* in parentheses, joined by logical keywords. If the media type is omitted it defaults to `all`, which is why `@media (width >= 40rem)` and `@media all and (width >= 40rem)` behave identically. ```css @media screen and (width >= 40rem) { } /* ^type ^join ^condition */ ``` When a media type appears, `and` is required between it and the first condition. `@media screen (width >= 40rem)` is invalid. ## AND `and` between parenthesised conditions requires all of them: ```css @media (width >= 40rem) and (orientation: landscape) and (hover: hover) { } ``` There is no limit on how many you chain, and the browser short-circuits nothing you can observe — either the whole conjunction matches or the block does not apply. ## OR — the comma CSS has no `or` in the original Level 3 syntax. The comma plays that role, and it separates *entire queries*, not conditions: ```css @media print, (width < 30rem) { .sidebar { display: none; } } ``` This applies when printing **or** when the viewport is narrow. A very common misreading treats the comma as "and", producing rules that fire far more often than intended. The mental model to hold: a comma-separated list matches if *any* member matches — it is a union. Media Queries Level 4 added an explicit `or` keyword usable between parenthesised conditions: ```css @media ((width < 30rem) or (orientation: portrait)) { } ``` The catch is that you may not mix `and` and `or` at the same nesting level without parentheses — the grammar forbids the ambiguous `A and B or C` precisely so that nobody has to memorise a precedence table. Parenthesise, or fall back to the comma form, which every browser has understood since media queries shipped. ## NOT `not` at the front of a query negates *that whole query*: ```css @media not screen and (width >= 40rem) { } ``` This is read as `not (screen and (width >= 40rem))` — it applies to everything except wide screens, including print at any width. It does **not** mean "non-screen media that are wide". Because negation binds to the entire query, `not` in one member of a comma list affects only that member: ```css @media not print, (width >= 60rem) { } ``` Level 4 also permits negating an individual condition, which is often what you actually want: ```css @media (not (hover: hover)) { .tooltip { display: none; } } ``` ## `only` `only` is the fossil in the syntax. In the era of browsers that understood media *types* but not media *features* — notably Internet Explorer 8 and earlier — a rule like `@media screen and (min-width: 40em)` would be parsed as plain `@media screen` and applied unconditionally, breaking layouts. Prefixing `only` produced a token those browsers did not recognise, so they skipped the rule entirely. In every current browser `only` has no effect whatsoever; it is legal, it must be followed by a media type, and its presence in a modern stylesheet is copy-paste inheritance, not technique. ## Media types worth knowing Only three matter in practice: `all` (the default), `screen`, and `print`. `speech` exists for speech synthesisers. The long tail from the CSS 2.1 era — `tty`, `tv`, `projection`, `handheld`, `braille`, `aural` — was deprecated in Level 4; browsers keep them parseable so old stylesheets don't break, but they never match. In particular `handheld` never meant "phone" in any browser you will meet, and a query aimed at it is dead code. A related instinct worth resisting: media *types* are not device categories. There is no `@media mobile`. Everything a phone browser does is `screen`, and the way you distinguish it is by querying dimensions or input capability, never by type. ## Invalid queries fail closed A malformed query — a stray unparenthesised condition, an unknown feature name, a comparison operator on a discrete feature — is invalid, and an invalid query simply never matches. Nothing is logged in the page, and the entire block silently does nothing. When a media block "isn't applying," checking the query's validity before debugging the declarations inside it saves a lot of time. In a comma list, one invalid member is dropped while the valid ones still work, which can make a partially-broken rule look intermittently correct.