[css-multicol-1] Margin collapse of first-child element is unintuitive

[alystair]

Hi gang, in my 17+ years of using CSS I never needed to research 'margin collapse', today was different.

I came across an annoyance with the current implementation of the column spec. This may be related to #2203 however the supplied demonstrations were confusing - so I created an intuitive demonstration of the issue here:

https://codepen.io/alystair/pen/poRRpXZ

Ideally, there shouldn't be a difference in the margin (or collapse of margin) of the first-child element when a multi-column layout is applied.

After reviewing the spec (mostly searching for instances of 'collapse' and 'first child') the only relevant content I found was Example 9.

What are the next steps?

[alystair]

Pinging @fantasai for triage, as they seem pretty active re: this spec - I'd love to contribute where I can and learn more about the process :)

[rachelandrew]

Hi @alystair I'm a spec editor on multicol. A lot of multicol issues are in reality fragmentation issues, hence that spec not always containing the answer you are looking for.

This use case is I believe solved by margin-break https://drafts.csswg.org/css-break-4/#propdef-margin-break

[alystair]

Thanks for the blazingly fast reply Rachel, seems my triage ping was unnecessary!

The solution you linked seems like a fantastic cure-all for all margin related woes that I look forward to using it in the far future once it's both implemented, and passes the ~95% 'CanIUse' threshold that most of the projects I'm involved in utilize.

I'm aware of the general convention of letting 'old dogs lie' and that changing the way an existing implementation handles things outside the scope of security/privacy/depreciation is considered 'a bad thing'.

However IMHO, even though it may break a few pixel-perfect layouts that rely on this exact behaviour - it is a trivial enough case, esp. since it only influences the positioning of the first child, to warrant a revision for 'the greater good' due to its non-intuitiveness.

The amount of time saved in aggregate for developers and designers that experience the behaviour and try to remedy it without a 'hack' is enough of a justification for me. Browser DevTools simply don't provide insight into whether an element is experiencing margin collapse at the moment (as seen in demo) - and even then a developer would have to know what to look for to change the behaviour.

[SelenIT]

@alystair it seems that this issue is not specific to CSS multicolumn, but common for all cases where some property implicitly converts the container into Block Formatting Context root, doesn't it? Wouldn't the same non-intuitive behavior occur if the container is set to overflow: hidden or contain: layout? If so, there is a standard (non-hacky) way to prevent the margin collapsing between the container and its first/last child by default — give the container display: flow-root instead of display: block, to explicitly convert it into the new BFC without side effects.

[tabatkins]

Yes, this is a generic issue with BFCs - if a container is a BFC, margins can't collapse thru it; it it's not (as is the default for display:block with nothing else affecting it), margins can collapse thru. Columns are a "something else affecting it", and make the container into a BFC. You'll see the same behavior if the container is float: left, for example.

So yeah, depending on how you want to fix it, margin-break or display:flow-root are probably what you want.

• margin-break will cause the first margin to disappear in both cases (it doesn't actually collapse in the non-BFC case, so the container will still need a margin of its own)
• display: flow-root is identical to block except it forces a BFC, so it prevents collapse thru itself in all cases

margin-break isn't yet implemented anywhere iirc, tho.

Unfortunately, "fixing" this behavior would cause layout shifts on a large percentage of existing pages; it's about as guaranteed to not be web-compatible as we can get, I'd think.

[fantasai]

Fwiw, there's also this proposal, which is related: https://www.w3.org/TR/css-box-4/#margin-trim

One of the open interesting questions is how that and margin-break should interact.

[fantasai]

@alystair So I guess the question is, what behavior are you wanting, and is it possible to achieve by using either display: flow-root or margin-break? :)

[alystair]

All I'm saying is in combination with default user agent styles, the way margins/padding interact with columns is unintuitive and confusing.

Here is a simple example of a columned section containing paragraphs, lists, and some headers dividing them spanning across all columns: https://codepen.io/alystair/pen/ExZQxaw

Without awareness of BFC (which I'm assuming is the majority of designers) one would expect all columns to begin at the same vertical height, which doesn't happen because the top margin/padding only influences the first column, not any of the consecutive ones.

[alystair]

Unfortunately, "fixing" this behavior would cause layout shifts on a large percentage of existing pages; it's about as guaranteed to not be web-compatible as we can get, I'd think.

Unsure if it's readily available data but I'd be interested to know what % of websites actually utilize column CSS properties (and then which subset manually set margin/padding of child elements). Perhaps a change wouldn't be as bad one would initially think.