Re: [csswg-drafts] [css-grid][css-contain] Clarify that `contain:size` affects track sizing (#4931)

Hmm. I accidentally let this sleep for a little too long.

In summary, at this point, I think we have narrowed it down to two possible approaches:

α) Clarification of the current spec, to stay true to its initial intent, which would have you size the element as if it was empty, including explicit grid tracks sized as if they had no element placed in them, and not including any implicit track since they wouldn't be created in the absence of content; then in a second phase, perform layout of the content within the now fixed-size box normally. Specific wording to be tweaked, but it's in the spirit of ["solution C"](https://github.com/w3c/csswg-drafts/issues/4931#issuecomment-615144446).

β) Make contain:size more aggressive, and actually suppress *explicit* grid tracks as well during the sizing step (but still lay everything normally in phase 2).
This isn't really necessary for the purposes of contain:size itself, but if we want to use it as a building block for some kind of container queries thing, that could be useful. Exactly how container queries is going to work (if it ever does) is unclear, but logically, in order to avoid circular definitions, you would not be able to set conditionally by query any properties that can affect the size of the object you're querying. Which means that grid-template can't be something you could change in response to a query about the size of the grid container, unless we made sure that contain:size suppresses its effect on the container’s size.

If we apply the same principles to multicol:
* the result under α would be that if both column-count and column-width are set, you size as having that many columns of that size (with colum-gaps inbetween); if only column-width is set, you size for 1 column of that size; and if only column-count is set, you size as n-1 times the size of the column gap.. 
* the result under β would be that you always size a multicol as an ordinary block.

Typically, size containment isn't used without manually providing a size: For out-of-flow elements, size containment isn't useful, and for in-flow elements, size containment without providing a size results in jumbled / overlapping layouts. So for most uses, the difference doesn't actually matter.

The one case where it would matter is 1D size containment. Having the inline dimension of a block level element be size-contained, without specifying a size manually, would be useful, and could very well serve as a basis for container queries. This is discussed in https://github.com/w3c/csswg-drafts/issues/1031 

That said, as discussed in that issue, it's not clear yet whether whether 1D size-containment + container queries is going to be possible at all.

Unless I am missing something about the usefulness of β with 2D size-containment, I think this leaves us with a few paths forward:
1. Decide now to do β anyway. It might not be useful if 1D size-containment + container queries turns out to be impossible, but the downside (other than spec and implementation churn) is relatively minor: size-containment without manual size becomes even worse at sizing things, but it was bad in the first place anyway.
2. Decide now to do α for 2D containment, but keep the question open for 1D containment, if we ever get it to work.
3. Punt until https://github.com/w3c/csswg-drafts/issues/1031 is resolved one way or another.

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


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

Received on Wednesday, 7 October 2020 04:00:13 UTC