[css-contain-2] do we need size containment in a single dimension to enable container queries?

[dbaron]

One thing that came up at the extensible Web summit in Boston on Friday was a discussion of container queries.

While I'd previously suggested tying container queries to CSS containment, one thing I realized is that there will be cases where developers want to fix the width from the outside but still allow an auto height, and then do media queries on the container's width.

I haven't thought this through very much, but it seems to me that this may require a concept of layout containment in a single dimension to be exposed from containment.

[frivoal]

Specifically, what would be needed is 1d size containment.
https://drafts.csswg.org/css-containment/#containment-size

[dbaron]

I think container queries require both size containment and layout containment.

[frivoal]

I agree. What I meant is that you should be able to apply regular layout containment (which we already have) together with 1d size containment (which we don't) to get the effect you described.

So authors need both, but the WG only needs to add 1d size containment, since we already have the rest.

[css-meeting-bot]

The CSS Working Group just discussed , and agreed to the following resolutions:

RESOLVED: Level 2

The full IRC log of that discussion

<fantasai> Topic:
<Florian> github topic: https://github.com/w3c/csswg-drafts/issues/1031
<fantasai> github topic: https://github.com/w3c/csswg-drafts/issues/1031
<fantasai> Florian: Next one from dbaron...
<fantasai> dbaron: This one is a big issue
<fantasai> dbaron: One of the things that a bunch of web devs really want is what they call "container queries"
<fantasai> dbaron: which basically addresses the sue case of teams that develop widgets or modules that are part of a bigger page
<fantasai> dbaron: Their developing some markup and script and whatever that gets included within a bigger page, and it will have some size
<fantasai> dbaron: The bigger page might use meida queries to e.g. switch from 3 columns to 2 colums, and widgte gets bigger though viewport got smaller
<fantasai> dbaron: If you're implementing the widget, you want to respond to the size that the widget is, not the size of the viewport
<fantasai> dbaron: Bunch of ppl want container queries that actually work, rather than do what ppl do right now which is do layout, flush, and set styles based on that
<fantasai> dbaron: Seems to me it should have some relation to containment
<fantasai> dbaron: that is, ability to do container queries should depend on some kind of ocntainment so that your insides dont depend on your outsides which depend on your insidees
<fantasai> dbaron: The next point is that sometime sppl want to do container query on their width, but have an autho height
<fantasai> dbaron: So, was thinking we want to have layout containment in only one dimension
<fantasai> dbaron: Beyond that haven't thought about it, so this is a "please design me a feature" issue
<fantasai> dbaron: This seems like a relatively high priority feature because ppl do this a lot, and do it by doing flush-restyle loops
<fantasai> Florian: If theyr'e willing to go that far, using 2D size containment is good, set it and then reset your height after you do layout
<fantasai> dbaron: Get ppl doing it for multiple parts of the page, so cycles multiple times
<fantasai> fantasai: why not just have -x -y keywords?
<fantasai> TabAtkins: Hard to define what htat means
<fantasai> eae: Maybe sets wrong expectations, that you wouldn't get same perf benefits
<fantasai> TabAtkins: True, but you do get the benefit that when your'e using resize observer you get predictable behavior and not loops
<fantasai> Florian: Seems like level 2, esp we don't have proposal yet
<fantasai> TabAtkins: This plus resize observer plus custom at-rules, I'm hoping will allow solving this use case
<fantasai> TabAtkins: Been my plan for like 10 years
<fantasai> s/10/2/
<fantasai> RESOLVED: Level 2

[ausi]

I would really like this feature to help container query scripts to solve the recursion issue. But is size/layout containment in one dimension even possible?

Take, for example, the following structure (assuming that size-x would be the value for containment across the X axis):

<style>
	.wrapper { height: 100px; overflow-y: auto }
	.component { contain: size-x }
</style>
<div class="wrapper">
	<div class="component">
		Content that grows in height via a container query script
		when the width gets wider.
	</div>
</div>

In an edge case this could still lead to an endless loop I think: The width of .component depends on the content-with of .wrapper and the content-width of .wrapper depends on the height of .component (because of the scrollbar). This means that the width of .component would still depend on its contents even though contain: size-x is set.

[gregwhitworth]

@ausi containment only works on the box that it is applied to; so, in your scenario, you're only containing size-x for .component. Thus whatever size-x is defined to do will occur for its content and will then propagate the resulting geometry to .wrapper. Regarding scrolling, it this geometry results in the height being over 100px then you re-layout .wrapper with the scrollbar in place (this is how scrollbars work today)

[ausi]

Regarding scrolling, if this geometry results in the height being over 100px then you re-layout .wrapper with the scrollbar in place

But wouldn’t this re-layout update the width of .component?