Does the updated contain proposal prevent one axis from affecting the other?

[jonathantneal]

Thank you so much for putting your mind to this issue.

After reviewing Dependence on containment, I saw that in w3c/csswg-drafts#4741 you wished clarify that the computation of the intrinsic sizes of the box must also be done as though the box has no contents. (emphasis added)

Do I understand correctly that this successfully resolves a scenario where one axis size may depend on another, as described in w3c/csswg-drafts#1031 (comment) ? (example with the suggested addition of box-sizing: border-box).

[dbaron]

Sorry for letting this sit for so long.

The issue in w3c/csswg-drafts#4741 is somewhat related to what I'm trying to propose here, but not that related.

In particular, the current definition of containment uses a convenient shorthand: define contain: size to behave as though the element has no contents. This works in both dimensions. It might be not quite so trivial for implementations -- the implementations probably need some custom code in the implementation of each display type, and maybe in more than one place for some of them, to act as though the element has no contents. But it is, nonetheless, a clear and simple definition that implementers can apply, although it might require a bit of work for implementers to find all the places in the code that they need to apply it.

The aspect of containment that I think is needed for container queries is to have containment in a single axis. Doing this is harder from a specification perspective, since the specification can no longer use the shortcut of saying to assume that the element has no contents -- it instead requires that we make that sort of assumption in some places but not others. So the approach I'm proposing here is that we're going to have to redefine containment in each axis by having the spec define each effect that containment has. However, the combination of the effects that you'd get from contain: width combined with contain: height (or contain: block-size combined with contain: inline-size) should add up to being equivalent to the current definition of containment: act as though the box has no contents. However, the spec will need to give the necessary details so that (a) the combination of containment in both axes adds up to the existing definition of contain: size and (b) containment in a single axis does mean that the contents don't affect the size in that dimension.

Or, to put it another way, this approach means that the specification needs to take the approach that I believe implementations already take (at least Gecko's implementation does), which is adding a test in various places in the layout code to have some specific change in behavior when containment is present.

[dbaron]

Oh, and yes, what I'm proposing to do here is exactly fixing w3c/csswg-drafts#1031.

[dbaron]

(And I should work through the examples in that issue in a bit more detail at some point.)

[dbaron]

I'm planning to archive this repository shortly. If this issue is still relevant, it should be raised in the CSS Working Group's repository.