[csswg-drafts] [css-sizing-4] How does height: stretch interact with margin collapsing with parent (#11044)

dbaron has just created a new issue for https://github.com/w3c/csswg-drafts:

== [css-sizing-4] How does height: stretch interact with margin collapsing with parent ==
There were some possibly-related previous discussions in #923 and #1614.

The [definition of stretch-fit sizing](https://drafts.csswg.org/css-sizing-4/#stretch-fit-sizing) says:

> Additionally, in [formatting contexts](https://drafts.csswg.org/css-display-4/#formatting-context) and axes in which the relevant [self-alignment property](https://drafts.csswg.org/css-align-3/#self-alignment-properties) does not apply (such as the block axis in Block Layout, or the main axis in Flex Layout), in cases where a percentage size in that axis would resolve to a definite value, a [stretch-fit size](https://drafts.csswg.org/css-sizing-3/#stretch-fit-size) causes the box to attempt to fill its containing block—​behaving as 100% but applying the resulting size to its margin box instead of the box indicated by [box-sizing](https://drafts.csswg.org/css-sizing-3/#propdef-box-sizing). For this purpose, auto margins are treated as zero, and furthermore, for [block-level boxes](https://drafts.csswg.org/css-display-4/#block-level-box) in particular, if its block-start/block-end [margin](https://drafts.csswg.org/css-box-4/#margin) would be adjoining to its parent’s block-start/block-end margin if its parent’s [sizing properties](https://drafts.csswg.org/css-sizing-3/#sizing-property) all had their [initial values](https://drafts.csswg.org/css-cascade-5/#initial-value), then its block-start/block-end margin is treated as zero.

It's not clear to me if this last sentence that says the margin is treated as zero is also intended to imply that there are revisions to the margin collapsing rules that make the margin show up on the parent.  (I don't know of any version of the margin collapsing rules other than [the one in CSS 2.1](https://www.w3.org/TR/CSS21/box.html#collapsing-margins).)  At first glance it seems like this might make sense.  However, it doesn't make much sense in the case where this element has siblings.  In particular:
* The sizing rule given here sizes the element as though it has no siblings.  But it might, in fact, have siblings.  (But making `stretch` behave "correctly" when there are siblings might be something we don't really want to do -- it's certainly difficult, particularly when more than one element has `stretch`.)
* The current spec definition of margin-collapsing is intentionally asymmetric:  blocks with a non-`auto` height do not collapse their end margin with their last child.  If this is intended to change that in some cases, it should probably be more explicit about it.  This spec text introduces a hypothetical "if its parent's sizing properties all had their initial values" to explicitly avoid that rule, but as a result it makes a margin disappear that doesn't end up anywhere else.
* If the goal were to have margins collapse if the `stretch` sizes the children to exactly fit the parent, it seems like the special collapsing rules should only apply when there aren't siblings to mess up the sizing, or something like that.

It's not clear to me why it's desirable to make these margins disappear given the current rules for handling siblings and margin collapsing.  It seems like a straightforward fix would be to remove the special rule about zeroing margins for block-level boxes.  Why don't we want to just allow the normal rules to run and size the element using its margins?

Or was there an intention that siblings and/or margin collapsing be handled differently?

Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/11044 using your GitHub account


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

Received on Thursday, 17 October 2024 13:28:47 UTC