[css-contain-3] Inconsistent handling of known and unknown features jeopardizes backward compatibility

[devknoll]

Currently, a condition like ((<unknown>) or (width)) will evaluate to true on a container with inline-size (assuming horizontal writing mode) or size, because the <unknown> is irrelevant to the final result. However, this is not the case with a known but invalid feature. For example, ((height) or (width)) and not ((height) or (width)) will simply be filtered out and never evaluated on an inline-size container, and so those styles will never be applied.

The issue is that a future version of the specification could make some value of <unknown> a known feature that happens to be invalid in the context an author used it. If a browser follows the existing behavior of filtering out conditions with such features, the author's styles will likely begin to stop applying for users on that browser, which is unexpected behavior.

Instead of being filtered out when they have known but invalid features, it seems like invalid features should just evaluate to unknown for consistency. That way, a condition like ((<unknown>) or (width)) will continue to apply (via the semantics of the or), even if <unknown> eventually has a semantic meaning in a future browser.

[mirisuzanne]

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

[devknoll]

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>

[mirisuzanne]

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.

[css-meeting-bot]

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

The full IRC log of that discussion

<dael> miriam: The issue is that currently when we're looking for a container to resolve queries against we look for nearest ancestor of appropriate type
<dael> miriam: if containers we find don't have type, don't find anything, we return false
<dael> miriam: however if you use a general enclosed unrecognized type resolve as unknown
<dael> miriam: At some point unrecognized becomes recognized and instead of resolving unknown we keep looking for more containers or resolve false
<dael> miriam: Discrepency between feature we don't understand and features that are not supported on that type is different. Could be a problem down the road
<dael> miriam: Two approaches we could take. One is complex about OR logic where when there is an or we resolve 2 sides separately or only need one match. That's getting a bit clever
<dael> miriam: Other is encount for general enclosed in the selection processes for account for it in container selection
<dael> TabAtkins: not super clear on precise behavior. If you have query height or width today and evaluate on inline-size it doesn't evaluate to true?
<dael> TabAtkins: b/c width would be correct?
<dael> miriam: Doesn't evaluate at all. Looks at two types and says this container can't answer question and it looks for a different container
<dael> TabAtkins: Yeaaah. I suspect that's what we want to fix b/c makes ORs not an OR
<dael> miriam: That would be option 1 to account for it in OR logic
<dael> TabAtkins: Only implication is right now can scan container query and know what will be required for it to be valid so you can filter more agressively. Is that intention?
<dael> miriam: Intention is selection process is automated. Before it was manual
<dael> miriam: I don't know if there's problems from impl side on splitting the container selection logic on OR
<dael> fantasai: I don't think there would be
<dael> TabAtkins: Not being an impl expert, I'm going to say probably not
<dael> TabAtkins: Go with that pending obj from implementations?
<fantasai> +1
<dael> astearns: Yep unless there are other opinions?
<dael> astearns: Prop: Go with option 1 and get implementor feedback
<dael> astearns: Obj?
<dael> RESOLVED: Go with option 1 and get implementor feedback

[anttijk]

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.

[mirisuzanne]

@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.

[anttijk]

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.

[mirisuzanne]

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.

[Loirooriol]

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.

[Loirooriol]

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?

[css-meeting-bot]

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

The full IRC log of that discussion

<bramus> miriam: discussed before but implementers have been pushing back
<bramus> miriam: issue that in CQ we are just looking to see if it resolve to true or false but that something to resolve against
<bramus> miriam: in that finding container step we look at question ask: if looking for width we are looking for container with inline size set
<bramus> miriam: height block size, both
<bramus> miriam: problem if when asking for width or height, it can resolve true even though half of it is recognized
<bramus> miriam: feels fine for now, as it could become recognized later
<bramus> miriam: as we add queries it not only changes if it resolve to true or false but also which container to look at
<bramus> miriam: causing possible backwards compat issue
<bramus> miriam: where something resolves differently whether its recognized as a query feature or not
<bramus> miriam:
<bramus> miriam: some vendors have shipped, so changing now is a breaking change
<bramus> miriam: would love to resolve sooner than later
<bramus> miriam:
<bramus> miriam: resolved previously was to split on the or [missed]
<bramus> miriam: browsers said that would be difficult and not logic to split on or
<bramus> miriam: other direciton sth with unknown query feature can match container
<bramus> astearns: there is no container that can asnwer all sides of the query
<bramus> miriam: yes
<bramus> miriam: width or height would then not resolve
<oriol> q+
<astearns> zakim, open queue
<Zakim> ok, astearns, the speaker queue is open
<astearns> q+ oriol
<astearns> ack JonathanNeal
<bramus> s/width or height/width or unkonwn/
<bramus> miriam: width or height would also not match
<astearns> ack oriol
<bramus> oriol: agree that there are problems with or. what if you have [missed] and? seems strange
<bramus> oriol: also want to consider third option to consider: could be possible that each queried feature could evaluate to different container
<astearns> s/[missed]/negated and/
<bramus> oriol: that is what we do with container units
<bramus> astearns: not sure I understand
<bramus> oriol: for example at container rule "width > 100px and height > 100px"
<bramus> oriol: parent that only has inline size witll be able to match height. other parent would match the width query
<bramus> oriol: might be confusing though.
<bramus> oriol: just wanted to list for completeness
<bramus> oriol: fine with 2nd option: if feature not recognize, just resolve as unknown
<bramus> miriam: in the or case it could resolve on one side of the query still
<florian> q+
<bramus> oriol: we would resolve each feature against the nearest container that supports it and if there is an unknown feature that we do not support by any ancesstor then it would resolve entirely to unknown
<bramus> bramus: a unknown is then false?
<bramus> oriol: it does not apply the rule
<TabAtkins> (I'm strong against resolving a single query against multiple elements.)
<bramus> oriol: it only becomes false at the top level
<bramus> astearns: option 3 would allow to keep prev resolution
<bramus> astearns: would get past implementer objection?
<TabAtkins> q+
<bramus> oriol: what are the objections? probably third option more complex than option 2. havent considered if easy to implement or not
<astearns> ack florian
<dbaron> I do feel that it's strange that @container (width > 100px) { @container (height > 100px) { ... } } is different from @container ((width > 100px) and (height > 100px)) { ...}, and I think oriol's option 3 fixes that... but it's also strange on itself, and maybe we should be thinking about use of container names as the "good practice" and these being sorts of error cases.
<bramus> florian: I understand optoin 3 and find it interesting. fairly hard time deciding whether that is confusing to authors or not
<bramus> florian: opens up extra possibility
<bramus> florian: would need examples to back up any reasoning
<astearns> ack TabAtkins
<bramus> TabAtkins: in the discussion with anti he was having a different view of optoin 1?
<bramus> TabAtkins: rahter than looking at query and using that as a prefilter for containers to look at, we instead will look at each possible container and if the query can be resolved against that we will do that, otherwise unknonwn
<florian> s/find it interesting/find it interesting in the abstract/
<bramus> TabAtkins: in the case "width or height" will work on inline-size container because container can handle a part of that
<bramus> TabAtkins: but if you do "width and height" this would fail because of the 1 unkown
<bramus> TabAtkins: that was optoin 1, right?
<bramus> miriam: no, dont think so but that could work
<florian> s/to authors or not/to authors or opens up a new and maybe convenient option/
<bramus> TabAtkins: dont really understand what antti’s understanding is so I can‘t comment on what it might mean
<bramus> TabAtkins: but what I said is what I voted for
<bramus> miriam: that would work, as does oriol’s proposal
<bramus> miriam: I dont see problems with oriols proposal and potentially does match author intent
<bramus> TabAtkins: disagree with that. you almost certainly want both conditions to match against same element, not a parent higher up
<astearns> agrees single container evaluation makes more sense
<bramus> TabAtkins: (mentions dbaron‘s note)
<astearns> ack dbaron
<bramus> TabAtkins: while you may want to target 1 element, you almost never want to target 2
<bradk> +1 to what Tab said
<TabAtkins> TabAtkins: While you might sometimes want to write nested queries and target the same element both times, you probably never want to write a single query and have it target two separate elements
<bramus> dbaron: trying to understand option 1. it seems very strange to me that you would take a query "height or width" and then evaluate against 1 part of that against 1 element and ignore the 2nd part of the query
<bramus> dbaron: seems strange. would expect to evaluate against a single element that answers to all parts
<bramus> TabAtkins: that’s the compat issue: unknown query
<bramus> florian: no element
<bramus> miriam: option 1 may have been poorly written
<bramus> miriam: i think tab’s and oriol’s could work
<bramus> miriam: 1 container or loosen that?
<bramus> dbaron: could tab clarify?
<astearns> ack fantasai
<TabAtkins> So then my proposal: attempt to match the queries against each possible container. If the container *can* match a given query, good; if not, it evaluates to unknown. (Unknown queries are always unknown.) Then if the top-levle result is unknown, move to the next possible container.
<bramus> fantasai: RE 1 container or 2: it does seem weird that combining […]. if you wanted to match against single container we have explicity type argument right?
<bramus> miriam: no, we don’t
<bramus> fantasai: ok, all implicit
<bramus> fantasai: if we had explicit type then author could define
<astearns> ack dbaron
<TabAtkins> So (true or unknown) will match, (true and unknown) will fail to match (and stop), (false or unknown) will continue looking.
<bramus> dbaron: auto-finding parent based on query might be bad idea. it should search using name or nearest
<bramus> miriam: that creates other probs such as style queries where we determined that you usually want direct parent so elements are style container by default so that you can query nearest but we dont want them getting in the way of size queries. going with nearest is going to be fragile.
<bramus> TabAtkins: my proposal is going to match nearest that can possibly match. in worst case its going to be […] right away.
<bramus> astearns: I see couple of ways forward
<oriol> q+
<bramus> astearns: resolve on tab’s reworking of option 1 or take back to issue
<dbaron> I'm OK with Tab's proposal.
<bramus> astearns: anyone need more time to review?
<astearns> ack oriol
<bramus> oriol: not sure if I understand proposal; what does it mean that container matches query?
<bramus> TabAtkins: it means that you satisfy the contditiions to potentially mathc. mainly that you have right container type.
<bramus> oriol: how do the binary operators work?
<bramus> TabAtkins: if you arent capable of matching, then evaluates to unkown. e.g. inline size vs width and height, one will be true/false and other unknown. if finale result at top level is unknown: skip and move up tree. if true/false: use that.
<bramus> TabAtkins: true + unknown = skip
<bramus> TabAtkins: true and false = false
<bramus> florian: i am going back to issue and throwing some examples in issue
<fantasai> s/am going/would like to go/
<astearns> ack dbaron
<fantasai> s/throwing/throw/
<bramus> dbaron: weird consequence of tabs proposal: nested containers: inner one has inline and outer one haas both containmenbts. there is going to be a point where you siwtch from using inner one to outer one. that jump seems pretty weird
<florian> s/examples in issue/examples in issue to compare Tab's option and Oriol's/
<bramus> dbaron: i guess we need to work through examples
<bramus> astearns: OK. let’s take back to issue
<dbaron> dbaron: ... to see if it does backwards jumping or not
<fantasai> I believe with Tab's logic you would choose different containers depending on whether you support 'unknown'
<bramus> miriam: other part of this: do we need use counters as this is breaking?
<fantasai> s/would/might/
<bramus> astearns: good idea. put it in issue.

[tabatkins]

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:

And	T	F	U
T	T	F	U
F	F	F	U
U	U	U	U

Or	T	F	U
T	T	T	T
F	T	F	U
U	T	U	U

Compared with the Kleene bools, which are:

And	T	F	U
T	T	F	U
F	F	F	F
U	U	F	U

Or	T	F	U
T	T	T	T
F	T	F	U
U	T	U	U

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.)

[Loirooriol]

@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?

[tabatkins]

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. :/

[Loirooriol]

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.

[fantasai]

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.

[mirisuzanne]

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() { ... }

[mirisuzanne]

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.

[anttijk]

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.

[cdoublev]

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>#?