-
Notifications
You must be signed in to change notification settings - Fork 757
Description
In § 5.2.2. Interaction With overflow: auto, example 6 is missing some code (#7867), but I think it implies that
div {
contain: size;
width: max-content;
height: 149px;
contain-intrinsic-size: 100px 100px;
overflow: auto;
}
div::before {
content: "foo";
display: block;
height: 150px;
}- Should get an outer width of
100px - Thus, with classic scrollbars, the width of the content area will be something smaller like
84px.
This is a big problem, because the width of the content area would be 100px if the contents were smaller, and https://w3c.github.io/csswg-drafts/css-contain-3/#width
The
widthcontainer feature queries the width of the query container’s content box.
So with CQ we would have a circularity.
Also, I don't get how this behavior described in example 6 follows from the normative text above.
In fact, the property is called contain-intrinsic-size, so just like normal intrinsic size I guess that this applies:
When the box is intrinsically sized, this reserved space is added to the size of its contents. It is otherwise subtracted from space alotted to the content area.
So actually the width of the content area should be 100px, and then if scrollbars are needed, the outer width will be something bigger like 116px.
In short: since container queries use the size of the content area, the presence of scrollbars shouldn't affect the content area of an element with size containment. They can affect the outer size, though.
Blink matches my expectations. Gecko does too for overflow: scroll, but for overflow: auto it seems it's not recalculating the sizes if a scrollbar is needed (regardless of size containment, bug 764076). WebKit is like Gecko (but it doesn't support contain-intrinsic-size). Testcase
