- From: CSS Meeting Bot via GitHub <noreply@w3.org>
- Date: Wed, 24 Sep 2025 16:21:21 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css2][css-flow][css-sizing] How do min/max block sizes affect bottom margin collapse with last child?`. <details><summary>The full IRC log of that discussion</summary> <TabAtkins> oriol: a container can collapse its bottom margins with its contents bottom margins *if* the height property computes to auto (plus border/padding/etc)<br> <TabAtkins> oriol: but it's not clear how min-height and max-height should affect that<br> <TabAtkins> oriol: beahvior in webkit and servo is they just check 'height'. if it's auto, they collapse. even if min-height is large enough that the margins dont' overlap<br> <TabAtkins> oriol: I dont' think this makes sense, want to change to match gecko and blink<br> <TabAtkins> oriol: they check that the final height is the intrinsic height, and only allow collapsing bottom margins in that case<br> <TabAtkins> oriol: some weird things. intrinsic height is 20px, max-height:0, min-height:20, the heights will match<br> <TabAtkins> oriol: but the height that actually wins is an extrinsic height. if specified in 'height', that would prevent collapsing<br> <TabAtkins> oriol: also not clear how this works with the intrinsic keywords in the *-height props<br> <TabAtkins> oriol: Ian has a proposal in the issue which sounds fine to me<br> <TabAtkins> oriol: we just stop checking that the height computes to auto<br> <TabAtkins> oriol: instead we first resolve intrinsic height, not including end margins of contents, then check the actual height, and if they're the same we allow collapse<br> <TabAtkins> oriol: I think this is fine, so long as it's web compatible<br> <TabAtkins> oriol: not sure if Ian's on the call, but I suppose he's willing to try it<br> <TabAtkins> iank_: yes, i'm willing. scariest thing I can think of is if you have a container with height:100px, and a direct child with height:100% and margins, that margin will start poking out.<br> <TabAtkins> iank_: it already pokes out the top, so there's at least symmetry. it's a relatively simple change for us so we're willing to try it out<br> <TabAtkins> oriol: so I guess we can resolve, and if it's not web-compat we can revisit<br> <TabAtkins> fantasai: checking understanding...<br> <TabAtkins> fantasai: you set height to 20px and intrinsic size happens to be 20px, you'd collapse margins<br> <TabAtkins> fantasai: but setting to 21px wouldn't allow collapse<br> <TabAtkins> oriol: yeah<br> <TabAtkins> fantasai: that seems like a problem if you're animating between values, just as you touch the intrinsic height<br> <emilio> q+<br> <TabAtkins> fantasai: so I think it's not great<br> <TabAtkins> fantasai: but sympathize with simplifying the logic<br> <TabAtkins> oriol: good point. maybe instead of completely dropping the height:auto condition... we could keep it but<br> <TabAtkins> oriol: for example, non-zero padding bottom. that prevents collapsing bottom margins. then you include the content margins into intrinsic height<br> <TabAtkins> oriol: I think if height also prevents collapsing bottom margins, we should also include bottom margins in intrinsic height<br> <TabAtkins> iank_: not wild about that<br> <TabAtkins> iank_: note we already have the problem Elika brings up with animating max-height<br> <TabAtkins> iank_: and animating max-height is quite common<br> <astearns> ack emilio<br> <TabAtkins> emilio: and you almost always clip due to it being a BFC anyway<br> <TabAtkins> fantasai: with max-height you don't have a single point, you have a flip point where you go from collapsing to not collapsing<br> <TabAtkins> fantasai: this behavior is weird because you collapse at only one single point<br> <TabAtkins> astearns: is that weirdness worse than the current, where things collapse or not only based on whether you have height:auto set?<br> <TabAtkins> fantasai: I think that's worse, yeah. happy to extend the height:auto stuff to include intrinsic sizes<br> <TabAtkins> fantasai: especially in block layout, all the intrinsics are equivalent<br> <TabAtkins> fantasai: and height:auto is interesting because it's.... your BFC won't collapse anyway<br> <TabAtkins> fantasai: I think if you have any kind of intrinsic size on height you can be allowed to collapse<br> <TabAtkins> q+<br> <TabAtkins> fantasai: but if your height value is a fixed size it shoudln't clamp<br> <TabAtkins> iank_: if we go down this route i'd like to do what blink does<br> <TabAtkins> iank_: we take the initial block size, and see if that's definite or not. that's subtlety different from checking the keywords<br> <TabAtkins> iank_: we try to resolve the b lock size with no intrinsic sizes, there's rules that fall out of that. calc-size() complicates, for example. and if that's indefinite we allow collapsing margins<br> <TabAtkins> fantasai: not sure I understand<br> <TabAtkins> iank_: it's close... the reason we've gotten into this situation is the rule was written with css2 in mind, where only 'auto' was intrinsic<br> <TabAtkins> iank_: we've added so much more, especially calc-size()<br> <TabAtkins> iank_: so the current thing we do in blink is in each layout, you always calculate an intrinsic block size<br> <TabAtkins> iank_: i'd like to use the same logic here for margins<br> <TabAtkins> fantasai: followed until the last<br> <TabAtkins> iank_: so we calculate the initial block size. if it's indefinite, we allow collapsing margins<br> <TabAtkins> fantasai: is "initial block size" - what is it?<br> <TabAtkins> iank_: at the start of every layout algo you compute this size...<br> <TabAtkins> fantasai: say a <p>, what's the initial<br> <TabAtkins> iank_: indefinite, since those are height:auto<br> <fantasai> scribe+<br> <astearns> ack TabAtkins<br> <fantasai> TabAtkins: Ian's brought up calc-size() a few times. I want to make sure calc-size( auto, 20px) is not meaningfully different from 20px<br> <fantasai> TabAtkins: that should act, for all purposes, the same of having an actual intrinsic size of 20px<br> <fantasai> TabAtkins: but because directly specifying 20px, would be nice if it matched 20px directly<br> <fantasai> TabAtkins: but those should be the same, I think<br> <astearns> ack fantasai<br> <TabAtkins> fantasai: I was gonna say opposite. it might make sense to have calc-size() always allow margin to collapse<br> <TabAtkins> fantasai: the same as if it was just "auto"<br> <TabAtkins> fantasai: margin collapse is just real weird with min/max etc. you can have margins collapse that aren'ta actually lined up, if you imagine margins as a transparent boundary around the element, because partial collapse doesn't exist. they either collapse or don't.<br> <TabAtkins> fantasai: so having calc-size() behave as always collapse probably makes sense to me<br> <TabAtkins> astearns: we're finding more ways to disagree, let's take this back to the issue<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/12218#issuecomment-3329753738 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 24 September 2025 16:21:22 UTC