[YevheniiKotyrlo]

Problem

On main:

1. A range pair never matches. The compiler emits (400px < width < 800px) as an interval, and both runtimes answer every interval false.
2. A negated term the runtime cannot decide matches. Both runtimes answer such a term false, so not (fictional-feature: 3) applies everywhere. A keyword a feature does not take fares no better: lightningcss passes any identifier through as a feature's value, the media runtime reads (orientation: bogus) as portrait, and the container runtime answers it false, so @container not (orientation: bogus) applies in every container. MQ5 §3.1 makes each term unknown and its negation unknown, and Chromium, Firefox and WebKit apply neither.
3. The compiler drops a media term whose value it cannot resolve. Under or the term disappears, so not ((width: env(safe-area-inset-top)) or (width > 9999px)) applies; under and the whole block disappears. All three engines answer the opposite in both.
4. Container conditions keep what CSS Conditional 5 §5.4 discards. not (fictional-feature > 10px) and (fictional-feature > 10px) or (width > 0px) apply, where §5.4 selects no container.
5. A feature in a boolean context never matches: (width), (hover), (color), (prefers-color-scheme) (MQ5 §2.4.2).
6. The device answers several features wrongly. (hover: hover) and (hover: none) both match on every device; pointer and any-pointer are never measured, so not (pointer: fine) applies on every device; color, color-index, monochrome, grid, scripting and update are never measured; and (grid: 0) never matches, because grid's value compiles to a boolean.
7. A keyword is compared as written, so (orientation: LANDSCAPE) and (prefers-color-scheme: DARK) never match, and (orientation: Landscape) matches in portrait. A keyword is ASCII case-insensitive (css-values-4 §4.1), and all three engines match each as its lowercase form.

Solution

• Media and container queries compare through one function, compareMediaFeature, so each operator has one meaning, and a range pair is its two comparisons.
• Both evaluate in three-valued logic (MQ5 §3.1), through a small kleene.ts. A term is unknown when the runtime does not measure its feature, when its feature holds an env(), which no browser takes as a feature's value, when the compiler could not otherwise resolve its operand (which now compiles to null), or when the runtime cannot order it (an em or vw bound, a calc()). The compiler makes a term unknown when its keyword is not one Media Queries 4 or 5 gives the feature: orientation, hover, any-hover, pointer, any-pointer, prefers-color-scheme, prefers-reduced-motion, scripting and update. A rule applies only when its condition is true, and the compiler emits no rule for a condition its unknown terms and unresolved operands leave no way to be true.
• A container condition holding a size feature the runtime does not know, or an env() value, compiles to no rule, as Chromium and WebKit drop it (§5.4); any other value the compiler cannot resolve leaves its term unknown, so an or keeps its other terms. A style() query compiles to an unknown term.
• In a boolean context, zero, none and no-preference are false (MQ5 §2.4.2, §12), and every other value is true.
• The runtime reports the features whose value is the same on every React Native screen: color is 8, color-index, monochrome and grid are 0, scripting is enabled and update is fast. An <mq-boolean> compiles to its integer (MQ4 §5.3).
• hover, any-hover, pointer and any-pointer answer by the input the device has shown (MQ5 §7.1, §7.2, §7.3): a touchscreen cannot hover and points coarsely, so iOS and Android answer none and coarse until a pointer hovers an element with a :hover style, and hover and fine from then on, where any-pointer also keeps the touchscreen's coarse; every other platform answers hover and fine. Tailwind's hover:, which guards :hover with (hover: hover), keeps working wherever a pointer hovers.
• The compiler folds a keyword to lowercase where it reads a feature's value, so the keyword check and the comparison read one spelling.
• The runtime's min-width, max-width, min-height and max-height arms go: lightningcss compiles each to a range on width or height.

#451's container-rejection test expected not ((width > 100px) and style(--theme: dark)) to apply at no width. In a 50px container the conjunction is false whatever style() answers, so its negation is true, and all three engines apply it; I changed that expectation.

Tests

• src/__tests__/native/compare.test.ts: the shared comparison, range pairs, operands it cannot order, and the boolean-context rule.
• src/__tests__/native/kleene.test.ts: negation, conjunction and disjunction over the three values, and short-circuiting.
• src/__tests__/native/condition-semantics.test.tsx: each condition rendered against a screen or a 400x200 container, and hover, pointer and any-pointer on each platform before and after a pointer hovers an element. The undecidable, boolean-context, device-feature and keyword cases render as in Chromium 153, Firefox 155 and WebKit 26.6, the iOS and Android input cases as in their touch contexts and the others as on a desktop, and the §5.4 container cases as in Chromium and WebKit.
• src/__tests__/compiler/condition-semantics.test.ts: which blocks the compiler emits for an unresolved value, an unknown container feature, a style() query and a condition no device can make true.
• On main, 93 of the 178 cases in the two condition-semantics files and container-rejection.test.tsx fail.

Verification

Every ci.yml job passes on this head merged into main with #477's harness fix, on Ubuntu with Node 22.18.0 with yarn test at 1556 passed, and the iOS dev build on macOS 27.0.1 with Xcode 27.0, where CI pins 26.6.

Device evidence, before and after: #426 (comment)

Known limits

• lightningcss 1.30.1 rewrites (min-width) as (width). MQ4 §2.4.4 makes (min-width) a syntax error, but here it now matches as (width) does.
• The runtime orders only numbers, so an em or vw bound and a calc() are unknown; fix(compiler): read a media query's em and rem against the font size rem inlines #494 resolves an em and a rem in a media query. A style() query is unknown too, since the runtime does not read the custom property it names.
• A container's inline-size and block-size are unknown until fix(native): measure inline-size and block-size container queries #480 measures them, and a ratio is until fix: evaluate aspect-ratio media and container queries #425 compiles it.
• A held color scheme of null, which colorScheme.get() reads as the system's, is unknown; fix(native): make colorScheme.set move every reader of the scheme #415 resolves both through one function.
• On iOS and Android, (hover: hover) and (pointer: fine) wait for a hover event, so a block either guards stays off until a pointer hovers an element with a :hover style.
• User preferences other than the color scheme are not measured, so they are unknown, and so are their negations: not (prefers-reduced-motion: reduce) applies nowhere, where main applies it everywhere; feat(native): evaluate prefers-reduced-motion so motion-reduce / motion-safe work on native #388 measures reduced motion.

Merge order

Range pairs moved here from #425, so this no longer builds on it. It shares lines with #425 (both media-query.ts files), #388 (both media-query.ts files and the jest helper, where it folds a keyword the same way and drops the evaluator's file-wide eslint-disable too), #415 (native/conditions/media-query.ts), #459 (compiler/compiler.types.ts, native/conditions/media-query.ts), #480 (native/conditions/container-query.ts), and #482 and #484 (native/react/interaction.ts); whichever lands second, I re-cut. #494 builds on this one.

[YevheniiKotyrlo]

Outdated: #426 is now re-written on top of #425, so the two no longer conflict.

The original note

Cross-referencing #425 and #426, which conflict — flagging it now rather than at merge time.

They are independent siblings (git merge-base is main; neither is an ancestor of the other) and git merge-tree reports content conflicts in four files: src/compiler/compiler.ts, src/compiler/container-query.ts, src/__tests__/compiler/media-query.test.ts, src/__tests__/native/container-queries.test.tsx.

The hazard is in the [] (interval) arm of testContainerQuery, because a plausible resolution silently reverts work:

• fix: evaluate aspect-ratio media and container queries #425 evaluates the interval — testMediaFeatureInterval(condition, value) — and also maps inline-size / block-size.
• fix: evaluate range pairs, and answer a condition the runtime cannot decide with unknown #426 returns UNKNOWN unconditionally and never evaluates it, because at the time it was written an unorderable bound had no safe answer.

Taking #426's arm wholesale therefore un-fixes #425's range container queries. Taking #425's wholesale loses #426's three-valued handling, where false is the one answer a negation turns into a match.

The resolution that is correct in both directions evaluates the interval and returns UNKNOWN only when a bound is unorderable.

One more line worth keeping whichever way it lands: #426's boolean-context arm uses isTruthyFeatureValue (Number.isFinite(value) && value !== 0), and the plain value !== 0 form admits NaN, Infinity and -Infinity. That is reachable — @container (aspect-ratio) compiles to ["!!","aspect-ratio"] and the feature value is width / height, so a zero-height container yields Infinity and the weaker form matches where it should not.

A two-case test pins both halves, and neither branch passes it alone:

1. @container box (400px < width < 800px) over a 500x100 container must match. (fix: evaluate aspect-ratio media and container queries #425 ✅ · fix: evaluate range pairs, and answer a condition the runtime cannot decide with unknown #426 ❌)
2. @container box (10em < width < 20em) and its not (…) twin must both fail over the same container — an unorderable bound is unknown, not false. (fix: evaluate aspect-ratio media and container queries #425 ❌, its negation matches · fix: evaluate range pairs, and answer a condition the runtime cannot decide with unknown #426 ✅)

[YevheniiKotyrlo]

Outdated: #426 is now re-written on top of #425, so the two no longer conflict.

The original note

Correction to my note above — I undercounted the conflict set, and the omission was the load-bearing file.

git merge-tree --write-tree fix/container-query-defects fix/media-condition-semantics reports seven conflicted files, not four:

src/compiler/compiler.ts
src/compiler/container-query.ts
src/compiler/media-query.ts                  ← omitted above
src/native/conditions/container-query.ts     ← omitted above
src/native/conditions/media-query.ts         ← omitted above
src/__tests__/compiler/media-query.test.ts
src/__tests__/native/container-queries.test.tsx

src/native/conditions/container-query.ts is the file whose []-arm resolution my note describes, so leaving it off the list made the note harder to act on rather than merely incomplete.

A second resolution needs the same care, in src/compiler/container-query.ts's "not" arm. main has return query ? ["!", query] : undefined. #425 changes parseContainerCondition to return a discriminated union, so its arm becomes query.type === "condition" ? ["!", query.condition] : undefined — which DROPS an unrepresentable operand. #426 keeps main's return type and writes return ["!", query ?? ["?"]], so an unrepresentable operand negates to unknown (MQ5 §3.1).

Taking #426's arm onto #425's types does not compile — query is an object there and never nullish. Taking #425's arm silently reverts #426's fix. The resolution that keeps both is #425's discriminant with #426's fallback:

["!", query.type === "condition" ? query.condition : (["?"] as MediaCondition)]

And one more, in src/native/conditions/compare.ts. #426 introduces MediaFeatureOperand = Exclude<StyleDescriptor, undefined> | null and a parseMediaFeatureOperand that can hand the comparator null; compare.ts exists only on #425, where both operands are typed StyleDescriptor, which excludes null. On the merge those call sites are a compile error rather than a silent null === null → true — so it self-flags, but the fix is to widen both operands and guard left !== null before the equality shortcut.

[YevheniiKotyrlo]

Device evidence — before / after

UNFIXED — The control and the pink bar paint, the two blue ones do not. A range pair and (width) in a boolean context never match, and the unmeasured color-gamut answers false, so its negation applies.

FIXED — The control and both blue bars paint, the pink one does not. A range pair is its two comparisons, (width) is true because the width is not zero, and not (color-gamut: srgb) is unknown, so it applies nowhere.

before — 3.1.0-rc.0	after — with this PR

Android 16 emulator (API 36, GLES on the host GPU), 1140×2400 @ 480dpi, both frames from one run. before is the published 3.1.0-rc.0 plus what my test app needs from my other patches to run: the native and native-internal subpath exports, PR 459, cascade-layer ranking, and a shim that compiles a class-qualified :root inert. after adds the rest of my open PRs, this one included. One of them shows on every screen: PR 417 narrows a var()-valued font-family to one family, so the after sets its text in the theme's face where the before falls back to the platform's.

Keywords in any case, on main and here

condition-semantics.test.tsx renders each query against the screen or container named. Chromium 153, Firefox 155 and WebKit 26.6 agree with this PR on every row.

query	where	main	this PR
(orientation: LANDSCAPE)	600x400 screen	no match	match
not (orientation: LANDSCAPE)	600x400 screen	match	no match
(orientation: Landscape)	400x600 screen	match	no match
(prefers-color-scheme: DARK)	dark scheme	no match	match
@container (orientation: LANDSCAPE)	400x200 container	no match	match
@container not (orientation: LANDSCAPE)	400x200 container	match	no match

Unknown keywords and the input features, on main and here

A probe renders each query against the screen or container named, on main and on this head. Chromium 153, Firefox 155 and WebKit 26.6 answer every row before a pointer hovers as this PR does, the iOS and Android rows in their touch contexts and the macOS rows on a desktop; MQ5 §7.1 and §7.2 give a touchscreen's pointer as coarse and its hover as none.

query	where	main	this PR
(orientation: bogus)	400x600 screen	match	no match
not (orientation: bogus)	600x400 screen	match	no match
@container not (orientation: bogus)	400x200 container	match	no match
(hover: hover)	iOS or Android, before a pointer hovers	match	no match
(hover: hover)	iOS or Android, once a pointer hovers	match	match
(hover: none)	macOS	match	no match
(hover)	macOS	no match	match
(pointer: coarse)	iOS or Android	no match	match
(any-pointer: coarse)	iOS or Android	no match	match
(pointer: fine)	macOS	no match	match
not (pointer: fine)	macOS	match	no match