Re: [csswg-drafts] [css-contain-1] do we need size containment in a single dimension to enable container queries? (#1031)

I've been working on this with @andruud, and we have a few ideas for how we might work around the issues. I don't think these two solutions would necessarily be exclusive, but the first certainly feels "simpler" -- and might help us avoid solving the second in more detail.

## The "pinky promise" (no containment)

Our favorite option is to avoid the need for size containment altogether, if we can. What if:

- We evaluate the CQ against the size the container _would have_ if `contain:size` was specified.
  - A CQ then implies a _promise_ of containment from the author, at least for the axes present in the CQ expression.
  - Layout proceeds without size containment. The actual result of the layout has no effect on CQ evaluation.
  - In other words, if the author breaks their promise, the CQ will still evaluate as if they hadn't. (The CQs won't be evaluated again).
- For the problematic "ancestral scrollbar" case, we'll automatically evaluate the CQ twice (since we're doing layout twice), so the second pass would have the CQ evaluate against the scrollbar-aware size.
  - However, if that second pass changes CQ evaluation such that the scrollbar wouldn’t be needed after all (e.g. by setting things to display:none when the container is below a certain width), then the scrollbar remains.

There is some danger that this makes it too easy for authors to stumble into "promise-breaking" behavior, where the container query reports a size significantly different from the final layout dimensions. But the advantages might be enough to offset that concern. It might be worth testing in a prototype.

## Making 1D containment work

If 1D containment is needed, it looks to me like that would require making some hard decisions about how the cases above _fail consistently_ while maintaining containment. This isn't ideal, but may also be a worthwhile tradeoff for authors. It would take some more discussion, but something like: 

1. For the sake of determining auto scrollbars on ancestors, the container contributes an infinite cross-axis size (always trigger the scrollbar). This is probably the more common edge-case, but I also think auto-scrollbars _might often_ imply an element has containable size on the cross-axis – so authors could avoid this by using 2D size containment in those cases?
2. For the sake of resolving percentage-padding on the contained axis, always resolve to `auto`. Maybe there's a better solution here, but I think this is the existing first-pass behavior in many cases where an element has unknown size, so it's a starting-point.

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


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

Received on Tuesday, 1 December 2020 19:38:42 UTC