I'm a bit confused what you mean by conditions being 'filtered out'. Is this related to the way known conditions impact the container to be queried? In the spec, it is containers, not conditions, that are filtered. So querying height will filter out an inline-size container, and look further up the tree for a new container to resolve against.

Maybe "which is filtering what" is a distinction without a difference in this case? I imagine it's true that unknown queries don't impact the container-selection in the same way as known queries. But I'm not sure I understand how the proposed solution would work in the container-filtering model. If we simply resolve them, we lose the container-type auto-selection feature, and would need to revisit #6644

Right -- I think the underlying concern is just that known-but-invalid values are given special treatment (compared to unknown values). This means that it's more likely that some use case might break if something is ever promoted from unknown to known-but-invalid in a future spec revision.

I think the underlying suggestion is just that they should fundamentally have the same behavior. One way to achieve that would be to make known-but-invalid values evaluate to unknown. Another way (which I think would address your concern about the auto-selection feature) would be for conditions that evaluate to unknown to look further up the tree for a new container until it resolves to a non-unknown value or runs out of containers to test (i.e. treat a condition that evaluates to unknown as invalid to the container being tested).

But yeah, this probably doesn't matter too much if we don't expect any new valid feature names to be added in future revisions, only e.g. <general-enclosed>

Got it. Thanks for catching and reporting this - sorry I didn't see it earlier. I think we do expect new features over time, and I see how this could be an issue. I made a test case on codepen, which shows the problem:

https://codepen.io/miriamsuzanne/pen/mdKEeby?editors=1100

(the result is a green background in both Blink and WebKit)

The language clarification that I'm trying to make here is that height is not known-but-invalid in a general sense - but the fact that it's known means that it can be used to influence container-selection. And, as per spec:

If no ancestor is an eligible query container, then the container query is unknown for that element.

Lack of a valid container causes the entire query to resolve unknown, where <general-unknown> only causes a single condition to resolve unknown. The issue here is caused by the container selection process, which doesn't currently account for <general-unknown> in validating containers. So the solution likely requires a change to that process. I see two potential solutions:

1. Account for or logic in the container-selection process. An inline-size container could be considered valid for a query of (height) or (width), since it's a valid container for one of the conditions. That may have strange implications I haven't considered, and I don't know if it's even viable from an implementation perspective.
2. Account for <general-enclosed> in the container-selection process. As you suggest above, unknown features could invalidate container-selection, and cause the entire query to be unknown.

I'd be interested in thoughts from the co-authors (@frivoal & @tabatkins) or @fantasai who proposed the auto-selection feature. Also adding Agenda+ to see if we can get a resolution on one of these from the group.

The CSS Working Group just discussed [css-contain-3] Inconsistent handling of known and unknown features jeopardizes backward compatibility, and agreed to the following:

• RESOLVED: Go with option 1 and get implementor feedback

Not sure I understand what is being proposed here. Can someone clarify what value in 3-value logic each of (unknown), (known-but-invalid), <general-enclosed> is supposed to have?

Also please make sure the behavior is consistent with media queries.

@anttijk The change we're making is only to the container-selecting logic. We're not changing how any of those situations resolve once a container is selected - so there's no parallel in media queries. Here's the text that needs to be changed:

For each element, the query container to be queried is selected from among the element’s ancestor query containers that are established as a valid query container for all the container features in the .

I'll need to look up some terms to get the final language right, but roughly we want:

• If the <container-query> includes or logic, a selected container only needs to be established as a valid query container for the features on either side of the or, but not both sides. So a query like:

@container (height) or (width) { … }

Does not require an ancestor container that is established for both height and width queries, but can select and query a container that is established for either height or width queries. We may also want to clarify that:

• If a container is selected that does not support all the features in a query, then the unsupported conditions resolve as unknown.

By making those changes, we ensure that unsupported-features-on-a-container and general-enclosed provide similar results in a query.

Anything that references logical operators amounts to a new way of evaluating the query (remember there can be or on any level) or creates inconsistencies in nested queries.

You could reasonably do

established as a valid query container for all any the container features

without creating unnecessary complexity. Not sure that matches what you are after.

In any case this feature has shipped and what is being proposed here is a potentially breaking behavior change. I'm not sure it has been justified sufficiently, or explained why it is safe to do.

Matching any container feature does not match what we would need here. The other proposed solution above doesn't require reference to logic operators. Would this be a more acceptable change from that perspective?

• Account for in the container-selection process. As you suggest above, unknown features could invalidate container-selection, and cause the entire query to be unknown.

In any case this feature has shipped and what is being proposed here is a potentially breaking behavior change. I'm not sure it has been justified sufficiently, or explained why it is safe to do.

The problem is if we ever want to add new dimension features in the future, they would ideally use a syntax that currently falls under 'general enclosed'. That would cause exactly the same potentially backwards-breaking behavior that we are discussing right now, except that it would happen after container queries have gained much higher production use. We could ask for a use-counter here, to prove that it is a 'safe' change now -- but more concerning to me is that the safety of this only gets worse the longer we wait.

It sounds like, either way, the current resolution needs to be revisited. Adding back to the agenda.

Another option could be allowing queries to evaluate each feature against different containers, just like if you use width: calc(1cqw + 1cqh) the units may evaluate against different containers.

The problem that I see with option 1 is that not ((width > 100px) and (height > 100px)) will not be the same as (width <= 100px) or (height <= 100px), right?

The CSS Working Group just discussed [css-contain-3] Inconsistent handling of known and unknown features jeopardizes backward compatibility.

As expressed in the minutes today, I completely misunderstood what "Option 1" was, and take back my support of it from the earlier meeting. ^_^

What I assumed it was saying, is:

1. If a query is capable of matching against a given container (for example, container-type: inline-size versus a (width) query, on an English element), then it resolves to true or false.
2. If the query is not capable of matching (for example, container-type: inline-size versus a (height) query, on an English element), then it resolves to unknown.
3. If the query itself is unknown, it resolves to unknown.
4. Resolve true/false/unknown as normal, and if the top-level result is true/false, stop and either match or don't match the query. If the top-level result is unknown, move to the next possible container and try again.

In simple cases, this matches the current "pre-filter containers based on queries" behavior - a plain (width > 100px) query will skip past elements that don't have the right container-type (because the query will resolve to "unknown") and then stop and either match or not when it hits an element with the container-type.

In multi-query scenarios we should look at "or" and "and" separately, and "all queries known" and "some queries unknown" separately.

(As a reminder, the Kleene-boolean logic is that an expression containing an unknown resolves to true if replacing the unknown with true and false both result in true; false if they both result in false; and unknown if they result in different answers. So "unknown and true" is unknown, "unknown and false" is false, "unknown or true" is true, "unknown or false" is unknown.)

In all these examples, assume the element is in a horizontal ttb writing mode, like English, and has a container-type: inline-size on it.

(width > 100px) or (unknown)

• If the (width) query is true, result is true; stop and consider the query matched.
• If it's false, result is unknown, keep looking.

(width > 100px) and (unknown)

• If the (width) query is true, result is unknown, keep looking.
• If it's false, result is false; stop and consider the query not matched.

(width > 100px) or (height > 100px)

• If the (width) query is true, result is true; stop and consider the query matched.
• If it's false, result is unknown, keep looking.

(width > 100px) and (height > 100px)

• If the (width) query is true, result is unknown, keep looking.
• If it's false, result is false; stop and consider the query not matched.

My conclusion here is that the "or" behavior is good in both scenarios. It exactly matches my intuition of how this should work - it stops when one of the conditions can be satisfied, and the fact that one of them is unknowable doesn't matter.

The "and" behavior is more arguable. It might be right in the "unknown" scenario, but seems more clearly wrong in the "height" scenario. It seems wrong to stop when one of the conditions is false, since we know that we're asking for an element that can satisfy both conditions.

This suggests we do want to use a different boolean logic than what MQs use, where "and"-ing with an unknown is always unknown. That is:

Compared with the Kleene bools, which are:

This'll ensure that if you're asking for two conditions to both be true, we'll skip anything that can't answer both questions, but if you're asking for either condition to be true, we'll stop and match if one of them ends up being true, but skip and continue if one is false and the other is unknown.

This is different from MQs only insofar as MQs don't have a "skip and continue checking" option - a top-level unknown is identical to a top-level false in MQs, but they're distinct in CQs. And this algebra change just converts some falses into unknowns.

(Heck, I think we could make this change in MQs as well, actually. I'll want to double-check, but I'm pretty sure I'm right, and all this does is change some scenarios that would evaluate to "false" in Kleene logic to become "unknown" instead, but any scenario that would evaluate to "true" stays true. But I don't think it's necessary for them to match - we craft the logic to the use-cases, which is why @supports no longer uses unknown, for example.)

@tabatkins But let's consider

<style>
@container (width > 50px) or something() {
  #c { /* ... */ }
}
</style>
<div id="a" style="container-type: size; width: 100px">
  <div id="b" style="container-type: size; width: 10px">
    <div id="c"></div>
  </div>
</div>

First, we try to match #b, we get false or unknown, which is unknown, so we keep searching.
Then we try to match #a, we get true or unknown, which is true, so we stop.
The condition matches and #c gets the styles.

But let's say that, in the future, we define something() as valid. Let's say it evaluates to false on #b.
So first we try to match #b, we get false or false, which is false, so we stop.
The condition doesn't match and #c does not get the styles.

I think this is the same forwards compatibility problem that this issue was trying to address?

Hm, you're right. On further consideration, I don't think we can actually have forward-compat here, so long as we're doing a search for the container element. An older browser will always be unable to faithfully execute the search query, while a newer one will be able to, and that will always result in different answers.

In that case maybe this should just be closed no change. :/

I think it's inconsistent, though, that if you use (width > 50px) or (height > 50px), the query container will be the nearest that supports queries for both width and height. But if you use (width > 50px) or invalid(), the container will be the nearest ancestor that supports queries for width, ignoring invalid().

Or well, that's the interpretation that all the implementations did, but the spec says

the query container to be queried is selected from among the element’s ancestor query containers that are established as a valid query container for all the container features in the <container-query>

It's not completely clear, but I would rather consider that no ancestor can be a valid container for unrecognized features.

I think I agree with @Loirooriol that the most forwards-compatible thing would be to basically invalidate the query if it contains an unknown. If we want to allow some or logic, we might consider introducing top-level commas as we have in Media Queries, and letting each comma-separated query be evaluated independently.

I agree with @Loirooriol and @fantasai as well. This is option 2 in the original proposal - with the addition of a comma syntax, which would allow the following to match on an inline-size container:

@container (width > 30em), (height > 40em), unknown() { ... }

While these fail to match:

@container (width > 30em) or (height > 40em) { ... }
@container (width > 30em) or unknown() { ... }

Since those comma-separated queries are allowed to resolve on different containers, I would expect a container-name to be allowed in each query:

@container my-card (width > 30em), my-layout (height > 40em), my-component unknown() { ... }

The follow-on question here: do we need a use-counter in order to make this breaking change? And if so, how soon can we get those results? I expect general CQ usage is currently fairly low without support in all engines, but that will be changing pretty soon.

I think so. The consequence of that is that we no longer need the kleene logic for container queries, right?

Nothing changes there since queries may still evaluate to unknown dynamically, right?

If the query container does not have a principal box, or the principal box is not a layout containment box, or the query container does not support container size queries on the relevant axes, then the result of evaluating the size feature is unknown.

Nit: the definition of CSSContainerRule.containerQuery should return a list.

The containerQuery attribute, on getting, must return the <container-query> that was specified [...]

But I am not sure about CSSContainerRule.name. Should @container be able to have more than one name? Maybe it should still accept a single <container-condition> defined with [<container-name>]? <container-query>#?