Add display-mode variants for pwa

[mrleblanc101]

Summary

Add display-mode variants to allow developer of PWA to create media query based on the display-mode of the user.
Relates to: #19698, #10194, #6755, #4955

Test plan

I followed https://github.com/tailwindlabs/tailwindcss/blob/main/.github/CONTRIBUTING.md.

I installed the rust toolchain and build the binary.
I ran pnpm tdd and all test run fine (except those that were already failing on main).
I ran pnpm build && pnpm vite and tested in the playground.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro

Run ID: d30a74fe-c1db-49da-9a78-1537c9521602

📥 Commits

Reviewing files that changed from the base of the PR and between ad66939 and 47dfc38.

⛔ Files ignored due to path filters (1)

• packages/tailwindcss/src/__snapshots__/intellisense.test.ts.snap is excluded by !**/*.snap

📒 Files selected for processing (2)

• packages/tailwindcss/src/variants.test.ts
• packages/tailwindcss/src/variants.ts

---

Walkthrough

This pull request adds six new display-mode variants to TailwindCSS: standalone, minimal-ui, browser, fullscreen, picture-in-picture, and window-controls-overlay. Each variant generates a corresponding @media (display-mode: ...) media query rule. The implementation registers these as static variants in the core variant engine, and comprehensive test coverage verifies that each variant produces correct CSS output for utilities like *-flex and properly rejects invalid modifier forms.

🚥 Pre-merge checks | ✅ 4

✅ Passed checks (4 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title directly describes the main change: adding display-mode variants for PWA development, which matches the core changeset.
Description check	✅ Passed	The description explains the feature addition, references related issues, and documents the testing process performed by the contributor.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[greptile-apps]

Confidence Score: 3/5

The change introduces a naming conflict that would force a breaking rename later if Tailwind adds a :fullscreen pseudo-class variant, which is a reasonable future addition.

The fullscreen variant maps to a display-mode media query, but :fullscreen is an established CSS pseudo-class with broad browser support. Tailwind is likely to want to expose that pseudo-class as a variant too, and both would claim the same fullscreen: prefix. Resolving that conflict later would require a breaking rename of the display-mode variant. The remaining names (browser, standalone) are also generic enough to create confusion or future collisions. The rest of the implementation is technically correct and well-tested.

packages/tailwindcss/src/variants.ts — the six new variant names need reconsideration before merging.

_{Reviews (1): Last reviewed commit: "Add newer spec values" | Re-trigger Greptile}

[greptile-apps]

fullscreen name will collide with a :fullscreen pseudo-class variant

fullscreen already exists as a widely-supported CSS pseudo-class (:fullscreen from the Fullscreen API). These two concepts are semantically different: @media (display-mode: fullscreen) detects a PWA installed in fullscreen mode, while :fullscreen targets any element that entered fullscreen via element.requestFullscreen(). If Tailwind later adds the :fullscreen pseudo-class variant—which is a natural addition—both would claim the fullscreen: prefix, causing a breaking conflict. The other display-mode variants (following the pointer-none / any-pointer-coarse precedent) suggest a display-mode-fullscreen name would be unambiguous.

Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!

[greptile-apps]

Naming convention diverges from existing multi-value media feature pattern

Existing multi-value media features prefix variant names with the property: pointer-none, pointer-coarse, pointer-fine, any-pointer-none, etc. These display-mode variants break that pattern by using bare values (standalone, browser, fullscreen). Following the same convention would produce display-mode-standalone, display-mode-browser, etc., which avoids collision with other uses of generic terms like browser or standalone and makes it immediately clear these are media-feature variants rather than pseudo-class or state variants.

Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!