Adding Installed Media Query Explainer by kyerebo · Pull Request #1315 · MicrosoftEdge/MSEdgeExplainers

kyerebo · 2026-05-07T21:21:02Z

The installed CSS media feature provides a reliable, boolean signal indicating whether the current document is running inside an installed web application window. It evaluates to true when the document is in an application context (a top-level browsing context with a manifest applied, presented in its own app window) and false otherwise.

alisonmaher · 2026-05-08T16:16:27Z

+
+## Introduction
+
+The **`installed` CSS media feature** provides a reliable, boolean signal indicating whether the current document is running inside an installed web application window. It evaluates to `true` when the document is in an application context (a top-level browsing context with a manifest applied, presented in its own app window) and `false` otherwise.


I don't think I've seen another MQ use "yes" and "no" as keywords. Is there precedence for this?

I wonder if instead we could format the MQ such that it describes the kind of host (not sure what the right terminology would be here, so please feel free to update based on your knowledge of the space)

@media (host-type: installed) { }

Then you'd have one for a non-installed type (the name of which I think should be fairly generic and not actually tied to the installed state). The benefit of this is that it could then be extended to other kinds of hosting environments in the future

Looking into this a bit further, I see for binary values we don't really use "yes/no".

I think a cleaner way is to have the media query check for presence as a boolean-style feature, so something like

@media (installed) { ... } @media not (installed) {...}

this feels more straight-forward and self-describing to me.

If we wanted to push for an enumerated MQ, we could go for something like

@media (app-context: installed) @media (app-context: browser)

We could also have both options in the explainer for now and leave it to CSSWG for a preferred direction to emerge during incubation.
WDYT?

I somewhat like the app-context approach since it allows for more extensibility in the future (whereas a strictly boolean approach would be limited and couldn't really be added to in the future). But I don't think including both would be a concern (and one could even be included in the other ideas considered section)

alisonmaher · 2026-05-08T16:19:02Z

+}
+```
+
+This feature separates the concept of "running as an installed app" from the app's current display mode, solving a long-standing gap in the web platform where developers lacked a clean, stable signal for installation state.


If you update the intro based on the section above, I think it'd be useful to dive into the concept of "the app's current display mode" and what that solution is, and why that isn't sufficient

Do you mean moving the contents of the "The display-mode Problem" section to the introduction?

Sorry, my wording there was confusing (even I'm confused :)) When I was originally reading the intro, I wasn't sure what was meant by "from the app's current display mode" so I think what I meant was giving more context on that in the intro to make that clearer (since it wasn't clear to me why that was insufficient or what it was).

But you could also keep that short and say the thing authors are trying to do and don't have a consistent way to do it, and dive into those existing solutions elsewhere. Up to you. But this was more so around ensuring enough context for the concepts introduced in the intro.

alisonmaher · 2026-05-08T16:28:45Z

+- **Showing app-specific UI** (e.g., a title bar, back navigation, or "open in browser" link) that only makes sense in an app window.
+- **Adapting layout** for the app window's chrome (or lack thereof).
+
+### The `display-mode` Problem


Since these are called out in alternatives considered, perhaps the intro could call these out briefly, and link to alternatives considered for more details, which would allow this section to be simplified

Making sure I understand the suggestion- simplify the intro section by removing the user-facing problems, mentioning the problems in the intro section, and linking them to alternatives considered?

Yeah touching on them in the intro, and leaving more details for these for that section (not sure if you need to link, but depending on how it is worded, you could link to that section, too)

alisonmaher · 2026-05-08T16:30:33Z

+
+## Goals
+
+- Provide a **stable, boolean signal** for "running in an installed app window" that is separate from display mode.


Maybe we can note a declarative and imperative signal here and remove the second bullet altogether

I could do something like Provide a **stable, boolean signal** for "running in an installed app window" that is separate from display mode that covers declarative and imperative use cases

I feel like we could be losing some clarity here though for simplification. Wdyt?

I was thinking of something like "Provide a declarative and imperative stable, boolean signal for "running in an installed app window" that is separate from display mode."

But now that I see it, I think that may be a lot to include in one bullet. I see now that one is more about it being stable, and the second is about having imperative and declarative, so that makes sense.

I was just thinking when I originally read it that "Require no new JavaScript API." felt more like a non-goal, so perhaps if that one is worded to say something like the signal should have an imperative and declarative option, that may help make the second one feel more like a goal rather than a non-goal

alisonmaher · 2026-05-08T16:39:26Z

+
+<!-- TODO: Add feedback from other browser vendors and web developers as discussions progress. -->
+
+| Stakeholder | Position | Notes |


Is this a new suggestion for explainers? If not, I don't think this is needed and can be tracked in ChromeStatus instead (so you don't need to update this in more than one place)

It's at the bottom of the template for explainers here https://github.com/w3ctag/explainer-explainer/blob/main/template.md

Do you think we can omit it regardless?

Interesting, maybe I haven't noticed it before. Yeah I think you can exclude it in this case. Might be an interesting call out for things where there is known pushback, but I think we can just rely on ChromeStatus for this one

akyereboah added 2 commits May 7, 2026 14:14

Adding Installed Media Query explainer

283de1a

Minor language adjustments

449892a

kyerebo changed the title ~~User/akyereboah/installed media query~~ Adding Installed Media Query Explainer May 7, 2026

Fixing quick links

317f821

alisonmaher reviewed May 8, 2026

View reviewed changes

akyereboah added 2 commits May 8, 2026 11:43

Shifted README.md entry to CSS category

42c2ecf

Applying edits for simplification

ecdb44a


		## Introduction

		The `installed` CSS media feature provides a reliable, boolean signal indicating whether the current document is running inside an installed web application window. It evaluates to `true` when the document is in an application context (a top-level browsing context with a manifest applied, presented in its own app window) and `false` otherwise.


		## Goals

		- Provide a stable, boolean signal for "running in an installed app window" that is separate from display mode.


		<!-- TODO: Add feedback from other browser vendors and web developers as discussions progress. -->

		\| Stakeholder \| Position \| Notes \|

Conversation

kyerebo commented May 7, 2026

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants