[css-contain] What is the migration path for Container Queries?

@eeeps

While at-rules provide their own test for positive support, there is currently no way to test for lack of at-rule support.

With the introduction of media-queries it became common practice to start with a reasonable fallback outside the query, and add progressive enhancement inside the query. That progressive approach also works with some container-queries (see Andy Bell's example), but it falls apart if an author wants to use media-queries as the fallback. Ideally, authors would be able to test for the lack of container-query support, and only apply media-queries when CQ is unsupported (see @eeeps codepen attempt).

If all browsers release 1D containment (or any other new property/value syntax) at the same time as container queries, Eric's approach should work:

@container {
  /* progressive enhancements */
}

/* query negative support for the related new property/value */
@supports not (contain: inline-size) {
  @media (...) { /* fallback media-queries */ }
}

It's not likely that any browser would release @container before releasing inline-size containment, but it is possible a browser would release 1d containment first. If that is the only new syntax to test, it could result in some false negatives: browsers that support both inline-size & @media, but not @container, would miss out on the fallback media-queries. That's not ideal.

I think the only way to ensure this migration path works smoothly is to include container-query-specific syntax that can be tested by @supports. The inline-size value might work for that, but only if browsers are careful to implement both features together.

@container

We've talked about wanting to be able to test for at-rule existence in @supports in the past (I can't find the issues for it right now), but it might very well make sense to just allow a trivial "does this at-keyword look like something you support?" test, like `@supports at-rule(@container) {...}

Both of our solutions exclude the long list of browsers supporting @media without support for @supports. In your case, browsers would also have to implement @supports at-rule() fairly broadly before @container is available, or it's not terribly useful. In order to use either pattern, authors would be hiding the media-query fallback from a long list of previously-supported browsers. Adding new support syntax might be a good idea long-term (also for layers and scope?), but in the immediate case it seems like it would make the issue more dramatic?

True, but fixing it "better" now makes the next time this problem comes up less troublesome. ^_^

Right, I absolutely support the feature. I'm not sure it solves the immediate issue. :)

That feature would be more powerful if it can also test support for the at-rule condition, like @supports at-rule(@media (prefers-reduced-motion: reduce)) {...}. As a bonus, I could infinitely nest @supports at-rule(@supports at-rule(@supports at-rule(…))) {…}, and that would keep me entertained for at least 20 minutes.

Just for reference, with the syntax I suggested in #2463 at-rules with descriptors and with nested rules would be covered for testing via @supports.

Sebastian

@SebastianZ

So a few syntax options that I've seen in the comments here or linked…

/* possibly using a function like at-rule() or rule() */ 
@supports (@container) { … }
@supports (@container (width > 20em)) { … }
@supports (@container, width > 20em) { … }

This would certainly be helpful for things like @container and new @media features.

@SebastianZ your linked syntax also includes a style block, since it's mainly concerned with testing descriptors inside a rule. Not clear if that's meant to be required, or part of what you're suggesting here?

@SebastianZ

@SebastianZ your linked syntax also includes a style block, since it's mainly concerned with testing descriptors inside a rule. Not clear if that's meant to be required, or part of what you're suggesting here?

The syntax is meant to take any kind of at-rule to let the UA do a simple syntax pass to check whether the at-rule is supported or not. So, in the simplest case you'd then have something like this:

@supports (@container { * { color: wheat; } }) {
  ...
}

There's a lot of power in that, but I think ideally the simplest case could be a bit more focused on the at-rule and its arguments. Maybe if blocks were allowed to be empty?

@supports (@container {}) { ... }
@supports (@media (prefers-reduced-motion: reduce) {}) { ... }

... Maybe if blocks were allowed to be empty?

@supports (@container {}) { ... }
@supports (@media (prefers-reduced-motion: reduce) {}) { ... }

Actually, they are, so that is totally valid syntax.

Sebastian

@mirisuzanne

+1 to @mirisuzanne's suggestion of:

@supports (@container {}) { ... }
@supports (@media (prefers-reduced-motion: reduce) {}) { ... }

This is definitely needed and useful for negation to apply styles when progressively enhancing container queries:

@supports not (@container {}) { ... }

This is more resilient than @supports not (contain: inline-size) {...} because inline containment could be implemented separately of @container.

@rules

The CSS Working Group just discussed [css-contain] What is the migration path for Container Queries?.

The full IRC log of that discussion

<dael> Topic: [css-contain] What is the migration path for Container Queries?
<dael> github: https://github.com//issues/6175
<dael> miriam: This issue started abotu container queries. A few potential ways authors could test for them. Using @supports and checking for something like contain-inline-size. Not entirely reliable.
<dael> miriam: If browsers impl 1d separately. With @rules provide positive case but can't test for negative, lack of support
<dael> miriam: Lack would be ideal here and for several other upcoming @rules
<dael> miriam: That lead us to a previous proposal from Sebastian. Possibility of doing a supports check on an @rule. Adding syntax. Una summerized at end of thread. Putting @rule inside @supports
<dael> emilio: Prefer dedicated function. Some @rules only valid in some parts of stylesheet. Not easy to hook into generic parsing algo.
<dael> emilio: We added a selector function to test for selectors. I think a MQ like container query function would be fine with MQ inside
<dael> miriam: Generically for all @rules so we don't add new funct for each rule?
<dael> emilio: We don't know how future @rules will handle stuff inside them. Separate function with syntax I think is a bit more; how would you test for nesting? Just a style rule inside with random stuff? Seems, I don't know. Maybe fine
<dael> miriam: Part of issue I see is this feature is the most powerful the farther away...we want this supported long before the @rules we add otherwise you lose utility
<gregwhitworth> q+
<dael> emilio: I think sep function is most straightforward for this. Impl more generically may be fine for rules we have. For @import would be a bit annoying. Blink, WK, and Gecko trigger import loads from parsing and it's not valid everywhere.
<dael> myles: Hard to say in future we'll never add statefulness ot @rules. I don't think @rule will be valid in any context will be always true
<dael> dbaron[m]: When designing @supports one intention is adding for @rules would be via a function
<dael> dbaron[m]: One of the interesting things that comes up with @rules is they often have rules for how to ignore bits of syntax inside of them. I think @supports has to key off of is this @rule valid in a way that it will produce something. And @media rule with invalid MQ that would get ignored would still be supported by @support definition
<dael> emilio: Good point. Invalid media lists just get parsed.
<gregwhitworth> ack gregwhitworth
<dael> emilio: That generic way doesn't work. PRefer specific functions for things. Maybe @-rule and take a keyword to see if browser understands in any wya
<dael> dbaron[m]: Not sure how useful to check do you understand thiskeyword vs entire @rule
<dael> emilio: The same way we have @supports(selector) and takes a list we'd have @supports(media and a media definition inside it that's specific on when you can consider supported.
<dael> dbaron[m]: I hadn't read whole issue, but examples in comments I'm not sure what' intended by some of the examples. Multiple interpretations
<dbaron[m]> The example I was commenting on was: @supports (@media (prefers-reduced-motion: reduce) {}) { ... }
<dael> florian: For function emilio suggested with care dbaron[m] suggested we could do something like that if it plugs into some part of parser. @support doesn't have dedicated code path. You plug into existing machinery
<dael> emilio: True.
<dael> emilio: Saying we should...if you do at @rule level then what dbaron[m] says applies. @media(garbage) is valid. We should say it prses but doesn't have fallback
<dael> dbaron[m]: Good reason for separate @supports for media functions. But not sure devs will understand why @rule doesn't work
<dael> florian: So far I don't htink has been possible to tell UA which isn't on a media type and UA which doesn't parse
<dael> emilio: Observable. If you don't parse the serialization returns not all
<dael> emilio: Can't from CSS itself but you can from JS
<dael> emilio: And MQ5 changes that but no one impl it yet
<dael> florian: Thinking for example like features like Grid which is not CSS Grid. It's a bool and everybody returns 0 because no browser is in a terminal.
<dael> emilio: I think we parse that. Same with color and other things that are matched fixed. We parse it.
<dael> florian: I think prop is manigable but have to be careful along the way
<dael> astearns: Prop you're referring to?
<dael> florian: @supports function dedicated to media types or expressions
<dael> emilio: And fix for container
<dael> miriam: Was I hearing 2 approaches? @supports rule and then rule name and other is @supports expression and that's separate features?
<dael> emilio: Rather then @supports rule it's a function. If it's empty you return if you support rule and if has content you parse and try and return
<dael> astearns: I'm confused emilio.
<dael> astearns: I agreed with miriam interpretation. Have an @rule function in an @supports which would say if you support @rule
<dael> emilio: That's another option
<dael> emilio: Is it useful tos ay do you support @container as is or do you want to say do you support htis container condition?
<dbaron[m]> I had been thinking of things like @supports at-rule(@container ... {}) {} and @supports media-expression((width: 200px)) {}
<dbaron[m]> though possibly rule() rather than at-rule()
<dael> astearns: For @container do we need expression checking? Or just if @container rule?
<dael> miriam: Both is useful. knowing if rule is supported at all is most useful
<dael> emilio: @supports and anything else immediately returns false. We can define a syntax. When browser impl container queries the syntax can be used anywhere.
<dael> emilio: A generic @supports @rule would be more generic
<dael> florian: Concerned it would work at first and problems later
<dael> florian: If you say I support this @rule authors will assume it works with what they want in the rule
<dael> emilio: I think given we've determined want one for media expressions one for container expressions makes sense
<dael> miriam: And if had container function that could accept an expression and you did @supports not-container function that would give you...?
<dael> emilio: I think that should work now and browsers should do right thing now. I fyou write @supports not whatever we should parse the thing inside. We we don't we should fix that
<dael> astearns: Wondering...talking about @rule function but also a media expression function and container expression function. Wonder if rule could take multi param where first is rule type and following are expressions valid in that rule
<dael> emilio: Problem is you don't know what future @rules will support
<dael> florian: Some have most sytnax before opening { and some it's within {
<dael> dbaron[m]: And you end up inventing an additional syntax that is not what you're testing for support for
<miriam> https://codepen.io/mirisuzanne/pen/VwPVpeK
<dael> myles: IN @fontface we added descriptors. Would htis prop allow authors to determine if ascent-override is supported?
<dael> emilio: There's a good question about if existing syteax should support parsing descriptors
<dael> dbaron[m]: Could add a descriptor function. Or we could say they're valid in there b/c similar to prop
<oriol> miriam, you have a typo, it's @supports, not @support. Then it's green
<dael> florian: Should keep them separate. A bit of name collision
<dael> emilio: Right. We can have function that takes fontface descriptor. Proposal as is doens't address but trivial to add
<dael> florian: Descriptor with first param as a rule and second is descriptor with same syntax as properties?
<dael> emilio: Resonable. Or add fontface-descriptor
<dael> myles: Don't need to design new feature
<fantasai> s/feature/feature on the call/
<dael> astearns: Yes, we're far afield from original question. But if want to do right for container and container expressions need to consider how would look for other @rules
<dael> emilio: Perhaps go to issue and flesh this out for next week
<dael> emilio: Proposing syntax for container and media; precise syntax
<dael> astearns: For a function that tells you if @rule is supported and other to tell you if expressions are supported
<dael> emilio: Yeah. Not clear if you want the is the @rule supported at all. Maybe footgun. Maybe just media, container, fontface, and so on
<dael> astearns: Okay
<dael> miriam: Works for me
<dael> astearns: Additional comments?
<dael> plinss: Random thought from miriam original comment on negative case. Generic @rule that's @else which is only for if previous @rule doens't apply
<dael> fantasai: There's an issue on that
<dael> TabAtkins: On the generic when/else. not the else/if you can tack to anything
<dael> plinss: This would be @container else
<dael> florian: Else proposed would be @support and @media but not designed to work on any. @fontface else isn't clear
<dael> plinss: Sure. Some it doesn't make sense for. It could be openended. Don't have to disallow but it would never apply for @fontface unless browser doesn't support it
<dael> astearns: I'll take action to find the else issue and point it to this one
<dael> astearns: Anything else on this?

Feels a bit inconsistent not to require at-rule() or something. You don't need more than one lookahead token to see that this is an at-rule and not a declaration, but still.

@lilles

@lilles My understanding of the discussion was that we're leaning towards individual functions for each at-rule:

@supports not media(width > 40em) { … }
@supports not container(min-width: 40em) { … }

(Here's a codepen demo of how it might work for Container Queries)

There was also mention of an @else rule that can be appended to any conditional block:

@container (min-width: 40em) { … }
@else { /* condition is negative */ }

And, while I like that idea, I don't think it does what we want here. I would expect @else to apply when the condition is negative (width is less than 40em), not when the condition is lacking browser support. I'm not sure we want to conflate those.

@container

The CSS Working Group just discussed [css-contain] What is the migration path for Container Queries?, and agreed to the following:

RESOLVED: Have unknown @supports expressions evaluate to false for all @support rules
RESOLVED: Create a container function that can test if @supports checks for a particular container query

The full IRC log of that discussion

<dael> Topic: [css-contain] What is the migration path for Container Queries?
<dael> github: https://github.com//issues/6175
<dael> miriam: Talked a couple weeks ago. confusion on intent. Going for @supports should always treat unknowns as unsupported
<dael> miriam: Allows new funt and testin work backward compat
<dael> miriam: 2 resolutions. 1) any unknown supports eval as unsupported 2) add container funt for testing support of specific container conditions
<dael> florian: When you say treat unknown as unsupported at top level, you mean immediately?
<dael> miriam: Yeah
<dael> miriam: Being able to negate it and have it return true is essential here
<dael> TabAtkins: Good with this
<dael> astearns: Changing behavior for all supports rules?
<dael> miriam: Right now not interop on this
<dael> miriam: Chart in the thread of current handling
<dael> astearns: Thanks
<dael> TabAtkins: Spec is unclear. Does not define. Was intended to be different, but Nina convinced me this is better
<dael> florian: Didn't we have prop for unified syntax for combo of media and supprot queries?
<dael> TabAtkins: That's my when/else proposal. We'll deal with that when it comes up
<dael> florian: Okay. Might be a problem, but not as important as containers
<dael> astearns: Prop: Unknown at-supports evaluate to false and add that to spec for all supports rules
<dael> florian: For this use case it's right. Will it always be or should we specialize to supports query for containers?
<dael> miriam: I can't see situation for other behavior. Any new type of check we add to at-supports to determine if supported need it previously returning false
<dael> florian: Add new feature and query together, yes. Support syntax for things that predeated abaility to detect then no.
<dael> TabAtkins: I think consider future longer then past. A supports query moving forward that you don't understand is for a new feature you don't understand
<dael> astearns: A bit concerned we haven't run across this lack of interop. Are people not using not was supports?
<dael> miriam: Ran into this with selector
<dael> florian: With selectors, do we not want opposite behavior?
<dael> astearns: In this case opposite as @supports nad @supports not eval to unknown
<dael> florian: An unknown stays unknown until top at which point it becomes false
<dael> miriam: Why would we want that?
<astearns> +1 to miriam
<dael> TabAtkins: Same as a feature. If you don't understand enough to evaluate you don't understand to use.
<dael> florian: Okay. Maybe I'm not thinking correctly. Defer to TabAtkins
<dael> astearns: Prop: Have unknown @supports expressions evaliate to false for all @support rules
<dael> RESOLVED: Have unknown @supports expressions evaluate to false for all @support rules
<dael> astearns: Do we also need to resolve for the @supports for specific features
<dael> miriam: Looking for a container function in @supports that accepts container query query conditionals
<dael> astearns: Is it the full syntax? Or a subset?
<dael> miriam: I think it should accept any...hmmm
<dael> miriam: Maybe it should be one query at a time and you can string together multiples of the function
<dael> miriam: Accepts single conditional
<dael> astearns: Had not thought threw this. Possibel we'll have new things you can add to funct over time such that an instance may or not eval based on state of impl?
<dael> miriam: I expect we will add additional feature queries over time
<dael> astearns: That seems to me argument to string together multiples. Maybe. maybe not
<dael> miriam: Makes sense and makes simpliest case simplier. @container and a singe query. Makes sense to me
<dael> astearns: Other opinions?
<dael> astearns: Prop: Create a container function that can test if @supports checks for a particular container query
<dael> astearns: Objections?
<dael> RESOLVED: Create a container function that can test if @supports checks for a particular container query
<dael> astearns: I expect once this is specced we'll have more questions

LibWeb: Remove `unknown` value in `@supports` query logic

@lilles

Not sure why I marked this as not needing edits. The current status seems to be:

The first resolution here was updated in the spec: https://www.w3.org/TR/css-conditional-3/#changes
The second part (a container() function) was not added, but...
We did also approve a more generic at-rule() function [in may]([css-contain] What is the migration path for Container Queries? #6175 (comment)

@lilles noted recently that we might want a way to test for style() queries specifically, before launching that feature. In order to do that, we either need to flesh out the details of a container() function, or a more powerful variant of the at-rule() function that allows testing entire rule blocks. My instinct is that we likely want the latter, but maybe that needs more discussion?

This was less necessary for the initial draft of container queries, which can be tested by checking for support of the new properties/values, eg:

@supports (container-type: inline-size) { ... }

Since style queries don't involve any new properties, a more general solution is required.

Navigation Menu

Repository navigation

[css-contain] What is the migration path for Container Queries? #6175

12 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

📋 Server Request & Proxy Logs

⚙️ Pengaturan Proxy Target

[css-contain] What is the migration path for Container Queries? #6175

Description

Activity

tabatkins commented on Apr 2, 2021

mirisuzanne commented on Apr 2, 2021

tabatkins commented on Apr 2, 2021

mirisuzanne commented on Apr 2, 2021

SebastianZ commented on Apr 4, 2021

mirisuzanne commented on Apr 6, 2021

SebastianZ commented on Apr 6, 2021

mirisuzanne commented on Apr 6, 2021

SebastianZ commented on Apr 6, 2021

una commented on Apr 7, 2021

css-meeting-bot commented on Apr 21, 2021

lilles commented on Apr 21, 2021

mirisuzanne commented on Apr 21, 2021

12 remaining items

css-meeting-bot commented on May 12, 2021

mirisuzanne commented on Aug 30, 2022

mirisuzanne commented on Aug 30, 2022

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions