Csswg-drafts: [css-contain] containment vs baseline alignement

[frivoal]

I think the spec is a little bit unclear, and probably partially wrong, when it comes to the interaction of containment and baseline alignment.

• If a non-empty inline-block has size containment, how should it be aligned in the line box that contains it? The way I understand size containment, it is only supposed to affect the size of the element with containment, causing it to be sized as if it was empty. This would mean that unlike an empty inline-block where we align the bottom margin edge with the parent's baseline (see CSS2 10.8), we would align the baseline of the box with the parent's baseline as we would do if the element had an explicit width and height of 0 instead of size containment.

  I am unsure about the meaning of what the spec currently says:

  When laying out the containing element, it must be treated as having no contents.

  After layout of the element is complete, its contents must then be laid out into the containing element’s resolved size.

  I think it only implies what I said above, but I am not sure. I suggest clarifying by changing to:

  When calculating the size of the containing element, it must be treated as having no contents.

  Then, its contents must then be laid out into the containing element’s resolved size.

• On the other hand, it seems to me that layout containment should negate the ability to do baseline alignment, otherwise, internal changes in the layout of the element would be able to affect it's surroundings. Therefore, I suggest we add this to the list of effects of layout containment:

  For the purpose of the 'vertical-align' property, or any other property whose effects need to relate the position of the containing element's baseline to something other than its descendants, the containing element is treated as having no baseline.

  The "any other property" part is meant to catch things like box-snap.

This is not what the Blink implementation does: it turns off baseline alignment on size containment, not on layout containment (see test case).

[tabatkins]

I agree that layout containment should treat it as having no baseline.

I think the intent of size containment is best served by also censoring its contents for baseline purposes; baseline alignment can affect the size of an element, and it's really weird for an element to collapse to zero height but still be baseline-aligned against a baseline that is now outside its bounds.

[frivoal]

I agree that layout containment should treat it as having no baseline.

Cool.

it's really weird for an element to collapse to zero height but still be baseline-aligned against a baseline that is now outside its bounds.

Is it? If you manually size an element with content to 0 height, it still baseline aligns, even though the baseline is outside of the bounds. Plus, I would not expect most element with size containment to collapse to 0, but rather to have a set height an use that. Then you have a non-zero sized inline block with visible content, but you can't baseline-align it. That seems weird.

From a use case point of view, as the spec says, the main reason to use size containment without layout containment is js-based container queries. I don't see anything about this use case that suggest that baseline alignment is any less desirable than in normal circumstances.

Oh, and I just realized that in my proposed text, I forgot to mention it applies to align-self/justify-self in addition to vertical-align, which actually makes it relevant not just to inline blocks, but also about grid and flex items

[tabatkins]

Yeah, you're right, there really isn't anything wrong with size containment combining with baseline alignment. So then I agree with your original argument; layout containment should censor baselines, size containment shouldn't.

[css-meeting-bot]

The Working Group just discussed containment vs baseline alignment, and agreed to the following:

• RESOLVED: layout containment censors baselines and size containment does not

The full IRC log of that discussion

<dael> Topic: containment vs baseline alignment

<dael> github: https://github.com/w3c/csswg-drafts/issues/2995

<dael> Rossen: TabAtkins can you do without florian ? Or do we punt?

<dael> TabAtkins: We concluded and wanted to see if obj.

<dael> TabAtkins: Spec wasn't clear what effect containments have on baseline. florian convinced me. Layout containment should censor the baseline b/c i t acts like there's nothing going on inside

<dael> TabAtkins: Don't have to do layout on contents to layout parent. Baseline requires you to know what's i nside

<dael> TabAtkins: Size containment does not censor. baseline doesn't effect that size in any way. Sizing works fine and you can baseline align

<dael> TabAtkins: Only potential weird is an overflow:visible element it can shrink to 0 but still have a baseline. That can happen today, though.

<dael> TabAtkins: Conclusion: layout containment censors baselines and size containment no change. Other containments don't matter here.

<dael> TabAtkins: Sound good?

<dael> Rossen: So this proposal only changes layout containment?

<dael> TabAtkins: Yes.

<dael> TabAtkins: urns out in chrome we don't pay attention to size but do for layout. We should be able to change. Per spec this only changes layout containment.

<dael> Rossen: Okay. Rest is clarification

<fantasai> +1

<fantasai> I think this is the correct resolution

<dael> Rossen: Reasonable. Seems florian agrees. Other comments?

<dael> Rossen: Objections to layout containment censors baselines and size containment does not

<dael> RESOLVED: layout containment censors baselines and size containment does not

[frivoal]

tests here: https://github.com/web-platform-tests/wpt/pull/12868