Repository navigation
[css-sizing] "behaves as auto" needs clarifications #13652
Description
https://drafts.csswg.org/css-sizing-3/#behave-as-auto
This section needs some wording tweaks to make it clearer that we're not equating this with computing to auto, and also the note should probably clarify that these uses are largely around sizing and don't affect margin collapsing (which should continue to check the computed style, testcase).
Activity
CSS: stretch and margin collapsing
annevk commentedon Mar 14, 2026
I created a PR for the web-platform-tests I encountered that mismatch with this: web-platform-tests/wpt#58496
cc @Loirooriol @dholbert
Loirooriol commentedon Mar 14, 2026
Firefox, Blink and Servo follow the spec. Please fix WebKit instead of changing the spec to something weird.
Loirooriol commentedon Apr 1, 2026
I misremembered the spec, as fantasai pointed in #8919 (comment) the spec actually says "some of these cases", not "all of the cases".
Still, it seems unnecessary to check the computed value here.
fantasai commentedon Apr 16, 2026
The reason to check the computed value here is that margin-collapsing behavior between a parent and child shouldn't change based on whether the parent's container is definite.
Loirooriol commentedon Apr 16, 2026
Why?
bfgeek commentedon Jun 17, 2026
A concrete proposal here would be helpful, with various examples. This is a quite complex area with various web compat concerns.
fantasai commentedon Jul 1, 2026
@Loirooriol Because that kind of action-at-a-distance is unpredictable and confusing. It's one thing to have an indefinite size change whether percentages resolve (this can be reasonably expected), but a different thing to have it also change the margin collapsing behavior. IMHO.
css-meeting-bot commentedon Jul 1, 2026
The CSS Working Group just discussed
[css-sizing] "behaves as auto" needs clarifications.The full IRC log of that discussion
<JoshT> fantasai: when we drafted the auto stuff, we were handy wavy about it<JoshT> ... it behaves as auto in most but not all cases
<JoshT> ... interesting case brought up is margin collapsing
<TabAtkins> q+
<JoshT> ... box with margin height, its last child can collapse with its own margin and the following sibling
<JoshT> ... but if it's not auto, like length or %, then margin collapsing does not happen
<JoshT> ... so the auto behaviour gets set if % is resolvavle because the container has a definite height
<JoshT> ... spec says that when the % can't resolve like in block layout, the height is calc in a way that behaves as auto
<JoshT> ... but spec checks computed value which is %, not auto
<JoshT> ... so the spec says you are not supposed to collapse the margins
<JoshT> ... but since written, there are new keywords so what is the right thing to do in various cases
<JoshT> ... brings up question that some impl include margin collapsing and some check the computed value specifically
<JoshT> ... so on one side, people says it should behave as auto in all aspects. on the other side, should it also unpack margin collapsing
<oriol> q+
<astearns> ack TabAtkins
<JoshT> TabAtkins: comment in issue asks for concrete proposal
<JoshT> ... right now it doesn't actually propose what is changing
<JoshT> ... and asks for some examples
<JoshT> ... i do not support a change now before more concrete pros, suggestions and what this means for pages
<JoshT> fantasai: I filed this originally to flesh this out a bit more
<JoshT> ... oriol and ??? got into this case of margin collapsing
<JoshT> TabAtkins: in that case, I don't know what you want to edit
<JoshT> ... if that's only one aspect
<JoshT> fantasai: they're all probably independently editable
<kbabbitt> s/???/anne/
<JoshT> ... i can't remember what other side effects there are for auto
<dholbert> present+]
<astearns> ack oriol
<JoshT> oriol: I think that if we say something behaves as auto, then behaviour should be ??
<JoshT> ... we could add dependencies on computed values, but I do not see agreement on that here
<astearns> s/??/as close to auto as we can/
<JoshT> ... we should only add the auto behaviour when there's a good reason
<CameronPsychpsyo> fwiw, I got confused by the spec wording on this while working on Ladybird once.
<JoshT> ... this allows margins to collapse as auto. it's only webkit that checks the computed value
<oriol> https://github.com//issues/12218
<JoshT> ... several impl seem to collapse margins like webkit but there are some cases quite non-sensical
<JoshT> ... explained in linked issue
<JoshT> ... I think Blink's model is better
<astearns> ack fantasai
<Zakim> fantasai, you wanted to distinguish what's obvious from spec terminology != what's obvious for authoring
<JoshT> ... even then it's only webkit behaving in this way. I think it should allow collapsing margins as auto
<astearns> q+
<JoshT> fantasai: so I want to make a distinction for what makes sense based on what's in the spec
<JoshT> ... the original reason for this behavuiur is that % are not resolvable
<JoshT> ... we just needed some term to hook onto this idea
<JoshT> ... would like to ask what will the author most likely expect to happen
<JoshT> ... if most obvious is to collapse margins with % heights, then we should align on that
<oriol> q+
<JoshT> ... if it's not, then we should do the other thing
<TabAtkins> I think my point is still just that this issue doesn't actually contain any proposals (but there's an *implied* proposal about margin collapsing, which has a proposed WPT change to match)
<JoshT> astearns: web compat is likely a good reason not to follow auto if impl are not following spec
<JoshT> ... but also, does anyone know what is the test case that anna added is checking
<ydaniv> s/anna/anne
<JoshT> oriol: i think originally came from a test cases I added
<JoshT> fantasai: test case about stretch keyword
<JoshT> ... in most cases, it's treated as implicit size and margins will not collapser
<JoshT> ... if it has a child, the margin will not collapse as it's not expected to match
<TabAtkins> Currently all browsers pass the test in its current form https://wpt.fyi/results/css/css-sizing/margin-collapse-with-indefinite-block-size-005.html?label=master&label=experimental&aligned
<JoshT> ... if the container that the stretched item is in has a height, we run into this issue of whether to collapse
<JoshT> ... for stretch, the size of the container could be resolved
<JoshT> ... but when you have explicit height, the margins collpse, and when you don't, the margins don't collapse
<JoshT> ... that's confusing
<astearns> ack oriol
<astearns> ack astearns
<JoshT> oriol: for author expectations, when the spec is checking this, it's making sure margins only collapse when they align
<TabAtkins> *Is* this issue specifically about the margin-collapse issue? Elika stated it was about several things.
<JoshT> ... so you can make the bottom margin of last item and parent collapse
<JoshT> ... if parent has explicit size, you can't guarantee that you can do that
<fantasai> It was an issue about "we have some wording that needs tightening up here". And the margin collapsing issue is the main one that we have identified.
<JoshT> ... if this case, a % behaves as auto for sizing purposes, then margin collapsing purposes is the same
<JoshT> ... I think it makes sense to allow margin collapsing in all cases
<JoshT> fantasai: if you pick 40px as the size of your box, we still don't collapse the content
<JoshT> oriol: true. earlier linked to issue about it.
<JoshT> ... but point is whether you guarantee it adapts to content
<JoshT> ... % behaves as auto always, so size will always ???? contents
<JoshT> fantasai: depends on where you use the box
<JoshT> ... if someone sizes margins and padding with some assumption about whether margins collapse and then put it in container with auto height, it may or may not collapse, it's confusing
<JoshT> ... could cause unexpected breakage
<JoshT> ... if you set it to stretch or 100%, you're expecting something different to happen
<JoshT> ... for behaviour to change depending on what you put it into, it's confusing. if you want the other bhaviour,. you can just ask for it
<JoshT> ... if you are expecting margins to collapse sometimes and not other times, that's not a winning thing
<JoshT> ... depending on the spacing you want, you'd have to compensate for the collapsing or not collapsing
<JoshT> astearns: as Ian and TabAtkins suggested, we can take this back to the issue with concrete examples
<JoshT> ... we can have an idea of what we want to resolve on before this comes back onto the agenda