[css-contain-3][css-mediaqueries-5] Unified custom queries

[Que-tin]

The spec for Media Queries Level 5 currently specifies a way to define custom media properties like e.g. @custom-media --modern (color), (hover); with CSS Containment currently getting shipped beforehand, wouldn't it make sense to rename @custom-media to @custom-query, to create a reusable and unified way for creating custom properties that are including a query?

I mean if I get the idea of the current draft correctly, values inside of @custom-media could also be used inside of @container and @supports as well. But these aren't media, but feature & containment / container or even style queries.

Proposed @custom-query Solution

@custom-query --narrow-size (inline-size > 30em);
@custom-query --full-grid-support (display: grid) and (grid-template-columns: subgrid;);
@custom-query --is-special style(--is-round: true) and style(--is-highlighted: true);
@custom-query --combined-media-query-list (--narow-size), (--is-special);

@media (--narrow-window) {
 ...
}

@container card (--narrow-window) {
 ...
}

@container card (--is-special) {
 ...
}

@container card (--combined-media-query-list ) {
 ...
}

@supports (--full-grid-support) {
 ...
}

If from a technical stand point it isn't possible to get a unified solution for queries, this is a proposal for reusable custom-queries for supports & container, e.g. @custom-container fand @custom-supports.

[valtlai]

Related: #6698 (using custom env() variables in media queries)

[Que-tin]

Following recent discussions on this topic, I'd like to bring this topic back into focus

[andruud]

I have two questions surrounding @custom-media:

• Extrapolating from @custom-media, are we going to add @custom-supports, @custom-container, @custom-whatever in the future? (Is that nice?)
• Are we anyway going to add something else that makes @custom-media redundant? The css-env-1 spec already expects env() to work on MQs, and if we plan to do author-defined env(), then I'm not sure if @custom-media is needed at all. (EDIT: [mediaqueries-5] [css-env] Replace @custom-media with custom environment variables? #6698)

[romainmenke]

I think a large part of the use case is simply to give a name to queries.
So the feature is not being able to reuse 768px but instead to give a name to (width >= 768px)

Giving it a name implies several other aspects:

• listing all the named things gives an overview of all the predefined media queries in a project
• "jump to definition" and other niceties in code editors

I think this is mostly useful for @media and @container.
I am not convinced about @supports needing this for the same reasons.

This isn't that convenient with env() because there is nothing about a custom environment variable that communicates its intended use. You can't extrapolate "this project has a breakpoint on 768px" from a custom env variable, it might be defined for unrelated reasons.

[Que-tin]

@romainmenke with CSS Conditional Rules Module Level 5 defining @when as well as @else that accepts both media() and supports() as well as in combination, I think leaving @supports out of the loop when thinking about this is probably not the way to go.

But I'm with you that env() is more thought of as a way to save globally available values instead of full conditional rules.

env() should be used in combination with @custom-media | @custom-query , but shouldn't replace it.

[andruud]

@romainmenke Yeah, I do see that. Though those benefits are not such much about the thing having a name, but more about the thing having a type.

So you think @custom-<anything> is indeed the way to go, then?

[romainmenke]

The thing having a type is indeed important.

If @custom-<anything> is implementable and isn't an excessive burden to implementors then, yes I do think it is the way to go :)

But I don't have any strong attachment to the currently specified syntax.
Something more general purpose would also be fine.

Maybe something inspired by @property?:

@prelude --foo {
  syntax: "@media"; /* with some specific syntax to reference "whatever is valid in that other prelude" */
  value: (width >= 768px);
}

[andruud]

If @custom-<anything> is implementable and isn't an excessive burden to implementors then, yes I do think it is the way to go :)

It's quite implementable, and not a burden.

[romainmenke]

I also wrote some tests for @custom-media some time ago as part of the interop proposal: web-platform-tests/wpt#48480 Might be useful

[jimmyfrasche]

One thing in custom media specifically was the ability to use JS to override preference queries so that, for example, you could set dark mode based on a toggle on the page but just use regular media queries in the css. That may need to be moved elsewhere.