[css2] min/max-height and margin collapse is not interoperable

[Loirooriol]

https://drafts.csswg.org/css2/#collapsing-margins

bottom margin of a last in-flow child and bottom margin of its parent if the parent has auto computed height

Note the above rules imply that:

• The bottom margin of an in-flow block box with a height of auto and a min-height of zero collapses with its last in-flow block-level child’s bottom margin if the box has no bottom padding and no bottom border and the child’s bottom margin does not collapse with a top margin that has clearance.

The note mentions a requirement for min-height: 0, where does this come from? The normative text only mentions min-height for a different case.

Testcase: https://software.hixie.ch/utilities/js/live-dom-viewer/saved/11745

• Gecko and Blink collapse as long as min-height doesn't increase the height.
• WebKit collapses regardless of min-height.

What about max-height? https://software.hixie.ch/utilities/js/live-dom-viewer/saved/11746

• Gecko and Blink collapse as long as max-height doesn't decrease the height.
• WebKit collapses regardless of max-height.

Worth noting that there is also this other case:

top and bottom margins of a box that does not establish a new block formatting context and that has zero computed min-height, zero or auto computed height, and no in-flow children

Testcase: https://software.hixie.ch/utilities/js/live-dom-viewer/?saved=11751

Collapses	Spec	Gecko	Blink	WebKit
height: 1px; max-height: 0px	❌	❌	✔️	❌
height: 100% (indefinite)	❌	❌	✔️	✔️
min-height: 100% (indefinite)	❌	❌	✔️	❌

Should the spec change to align with some browser? At least remove the spurious min-height: 0 from the note, or enforce it in the normative text.

[fantasai]

Some relevant archaeology: https://lists.w3.org/Archives/Public/www-style/2012Mar/0052.html

[Loirooriol]

For collapsing through, when the spec requires a computed value of zero, what kinds of zero are included, exactly? Just 0px? What about 0% or calc(0px + 0%)?

Value	Gecko	Blink	WebKit (height)	WebKit (min-height)
0px	✅	✅	✅	✅
1px	❌	❌	❌	❌
0% against auto	✅	✅	✅	✅
0% against 0px	✅	✅	✅	✅
0% against 100px	✅	✅	✅	✅
1% against auto	❌	✅	✅	❌
1% against 0px	❌	✅	❌	❌
1% against 100px	❌	❌	❌	❌
calc(0px + 0%) against auto	✅	✅	✅	❌
calc(0px + 0%) against 0px	✅	✅	❌	❌
calc(0px + 0%) against 100px	✅	✅	❌	❌
calc(0px + 1%) against auto	❌	✅	✅	❌
calc(0px + 1%) against 0px	❌	✅	❌	❌
calc(0px + 1%) against 100px	❌	❌	❌	❌
calc(1px + 0%) against auto	❌	✅	✅	❌
calc(1px + 0%) against 0px	❌	❌	❌	❌
calc(1px + 0%) against 100px	❌	❌	❌	❌
calc(1px + 1%) against auto	❌	✅	✅	❌
calc(1px + 1%) against 0px	❌	❌	❌	❌
calc(1px + 1%) against 100px	❌	❌	❌	❌

I guess this may be affected by https://drafts.csswg.org/css-sizing-3/#behave-auto

Legacy spec prose defining layout behavior, particularly in [CSS2], might explicitly refer to width/height having a computed value of auto as a condition; some of these cases should be interpreted as meaning behaves as auto

[Loirooriol]

@mstensho created the WPT /css/CSS2/normal-flow/margin-collapse-through-percentage-height-block.html that checks that an element with an indefinite height: 30% can collapse through, interpreting that "zero or auto computed height" holds when behaving as auto.

[bfgeek]

I think Blink would like to move to a world where if the final (used?) block-size of the element is zero we consider it collapsing-through. Otherwise not. This would simplify the rule substantially - and be much more explainable. That said - I understand other implementations have limitations from how they perform margin-collapsing (however this may lead to bugs, e.g. clearance on an element within a collapsing-through element, can only determine if clearance applied - and the final status after performing layout).

[Loirooriol]

In Servo I'm appreciating that (except for clearance), margin collapsing can be determined without layout. But to be fair, I guess it's nonsensical for this to collapse through, even if it has height: auto:

<div style="margin: 50px 0; width: 100px; aspect-ratio: 1"></div>

So I guess that with the current situation, whenever we add a new feature that can cause the height to become greater than zero, browsers have to guess what to do. And for this other example, Blink and WebKit collapse but Gecko doesn't:

<div style="margin: 50px 0; width: 0; aspect-ratio: 1"></div>