You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[css-contain-3] Can we allow custom properties in dimensional container queries? #8088
Currently, dimensional queries allow relative units and resolve those units on the container:
html{container: root / inline-size;font-size:32px;}/* 32px em size, equivalent to (inline-size > 960px) */@container root (inline-size > 30em){...}
Style queries (according to the spec) currently compare computed values - which means they also resolve custom properties in the query condition (again, using the container as context for the resolution):
/* true in a theme container using the background color that matches the value of `--bg-dark` on that same container */@container theme style(background-color: var(--bg-dark)){ … }
It would be great if we're able to do something similar for dimensional queries:
/* true in a container with inline-size greater than the value of `--small-container` on that same container */@container(inline-size > var(--small-container)){ … }
This has been a highly-requested feature in media queries, but it seems like container queries should actually make it possible - since we have an element that we can use as context for resolving the custom property.
What would it take to specify that? Would we need to know in advance that the variable has the right type, e.g. requiring @property to define the custom property as a <number>? Are there other approaches we should consider, that wouldn't rely on @property?
Reacted by Roman Komarov, Raura, Felix Becker, Sergey Vinogradov and artix38
Are there other approaches we should consider, that wouldn't rely on @Property?
Could specify that a value that is a token sequence is parsed (post-substitution, CQ-evaluation-time) according to the feature on the other side of the comparison. Then define what that means for each feature, e.g. [inline-size, etc] -> <length>, orientation -> portrait | landscape, etc.
Reacted by Miriam Suzanne, Alexander, Andrei Elkin, Lea Verou and Raura
The CSS Working Group just discussed [css-contain-3] Can we allow custom properties in dimensional container queries?, and agreed to the following:
RESOLVED: Allow var references in container queries without particular type safety. Will check the type when a query is evaluated against a container
The full IRC log of that discussion
<dael> miriam: With container queries we are resolving against a specific container which is an element on the page. Which mean we resolve relative units. If we query >30em we know what an em is.
<dael> miriam: Similar with style queries we can resolve costom values in the query against the container
<dael> miriam: Have practice to resolve things that need an element. Can we take that and allow custom properties to be used in a dimensional query?
<dael> miriam: There would be 2 ways we could define it. Main problem is we need to resolve a type and make sure it's a number or length or whatever we need. Could either rely on @Property which is a little manual or could say define types expected for each dimansional feature
<dael> miriam: anders lays that out in a comment. inline-size is a length etc.
<dael> miriam: I think this woulc be a great thing. moving toward custom MQ. Slightly different, but a lot of same impact
<dael> TabAtkins: Definitely should do this and extremely good. I don't think need to be fancy what we get out the end. Don't need @Property or do anything for types beyond what is there defining syntax. All need to do is define what it means after substitution if it violates the query. Get an unknown or a false
<fantasai> +1
<dael> TabAtkins: Don't need to worry about types and more than we alreayd do. inline-size disallows red
<dael> miriam: I like that answer
<dael> astearns: Other opinions?
<dael> heycam: What happens if...you might have said it but what if variable isn't defined at computed value time
<dael> TabAtkins: It's guar invalid
<dael> astearns: Prop: Allow var references in container queries without particular type safety. Will check the type when a query is evaluated against a container
<dael> astearns: Concerns?
<dael> astearns: Objections?
<dael> RESOLVED: Allow var references in container queries without particular type safety. Will check the type when a query is evaluated against a container
<dael> astearns: This does seem cool
The value of a custom property can be substituted into the value of another property with the var() function.
But <mf-name> may be considered a descriptor, at best, not as a property.
Is @container (var(--property) > width) {} valid? Should var()-substitution be restricted to <mf-value>? Do you plan to allow other substitution functions, like env() or attr()?
Activity
andruud commentedon Nov 16, 2022
Could specify that a value that is a token sequence is parsed (post-substitution, CQ-evaluation-time) according to the feature on the other side of the comparison. Then define what that means for each feature, e.g. [inline-size, etc] ->
<length>, orientation ->portrait | landscape, etc.css-meeting-bot commentedon Jan 5, 2023
The CSS Working Group just discussed
[css-contain-3] Can we allow custom properties in dimensional container queries?, and agreed to the following:RESOLVED: Allow var references in container queries without particular type safety. Will check the type when a query is evaluated against a containerThe full IRC log of that discussion
<dael> miriam: With container queries we are resolving against a specific container which is an element on the page. Which mean we resolve relative units. If we query >30em we know what an em is.<dael> miriam: Similar with style queries we can resolve costom values in the query against the container
<dael> miriam: Have practice to resolve things that need an element. Can we take that and allow custom properties to be used in a dimensional query?
<dael> miriam: There would be 2 ways we could define it. Main problem is we need to resolve a type and make sure it's a number or length or whatever we need. Could either rely on @Property which is a little manual or could say define types expected for each dimansional feature
<dael> miriam: anders lays that out in a comment. inline-size is a length etc.
<dael> miriam: I think this woulc be a great thing. moving toward custom MQ. Slightly different, but a lot of same impact
<dael> TabAtkins: Definitely should do this and extremely good. I don't think need to be fancy what we get out the end. Don't need @Property or do anything for types beyond what is there defining syntax. All need to do is define what it means after substitution if it violates the query. Get an unknown or a false
<fantasai> +1
<dael> TabAtkins: Don't need to worry about types and more than we alreayd do. inline-size disallows red
<dael> miriam: I like that answer
<dael> astearns: Other opinions?
<dael> heycam: What happens if...you might have said it but what if variable isn't defined at computed value time
<dael> TabAtkins: It's guar invalid
<dael> astearns: Prop: Allow var references in container queries without particular type safety. Will check the type when a query is evaluated against a container
<dael> astearns: Concerns?
<dael> astearns: Objections?
<dael> RESOLVED: Allow var references in container queries without particular type safety. Will check the type when a query is evaluated against a container
<dael> astearns: This does seem cool
css-meeting-bot commentedon Jan 5, 2023
The CSS Working Group just discussed
[css-contain-3] Can we allow custom properties in dimensional container queries?.The full IRC log of that discussion
[css-contain-3] Allow var() references inside container size queries #…
mirisuzanne commentedon Mar 15, 2024
Added in ed383b5, happy for review.
mirisuzanne commentedon Mar 15, 2024
PR for WPT: web-platform-tests/wpt#45135
cdoublev commentedon Apr 4, 2024
Currently, replacing
<mf-value>withvar()in a container size query is only mentioned in a non-normative example.And the syntax does not allow it at the moment. It requires a valid CSS numeric type according to the feature value definition.
In CSS Variables:
But
<mf-name>may be considered a descriptor, at best, not as a property.Is
@container (var(--property) > width) {}valid? Shouldvar()-substitution be restricted to<mf-value>? Do you plan to allow other substitution functions, likeenv()orattr()?