Re: [csswg-drafts] [css-contain-3] Inconsistent handling of known and unknown features jeopardizes backward compatibility (#7551)

> A comma-separated list doesn't get us out of the forward-compat. You still have the exact same "might match different containers in old vs new browsers"; all you're doing is providing a different way to spell or.

The difference (as I understood it) between the comma vs the `or` is that the comma-separated queries could resolve on different containers – which is why I proposed allowing different `container-names`. Maybe that understanding was wrong?

But if I understood that right, I don't think your comment is accurate at all. In the proposed `or` logic, both of these fail to match an `inline-size` container, and give the same result:

```css
@container (inline-size > 30em) or (block-size > 40em) { ... }
@container (inline-size > 30em) or invalid() { ... }
```

If `invalid()` later becomes a valid feature for the container, then we might start matching the container. We _expect_ invalid features to sometimes become valid features, and that will always change the query result from consistently-`false`/`unknown` to conditionally-`true`. New features will always have that effect. But we don't want queries that currently work (returning `true` in some situations) to suddenly stop working because an invalid query becomes a valid-but-wrong-container-type query. To avoid that, we only have to ensure that eg `(block-size)` on an `inline-size` container behaves the same as `invalid()` on the same container. 

If the comma-separated syntax relies on `or` logic _while also explicitly allowing multiple containers to be queried_, then these have the exact same compat implications as above, with invalid and wrong-type continuing to match in behavior:

```css
@container (inline-size > 30em), (block-size > 40em) { ... }
@container (inline-size > 30em), invalid() { ... }
```

Both queries can resolve as long as there is an `inline-size` container – and since the query list items can resolve on different containers, the two container-not-found queries don't interfere with the `inline-size` result. If the unknown query becomes known, it can also resolve on a new container. That's an expected new-feature behavior. However, if the new query returns `false` or `unknown`, the comma-or different-container logic allows our existing `inline-size` query to remain `true` on the alternate container. The new feature doesn't interfere with the old - only combines with it.


-- 
GitHub Notification of comment by mirisuzanne
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/7551#issuecomment-1399292766 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Saturday, 21 January 2023 17:21:17 UTC