[css-multicol] Improve column-fill and make it backward-compatible

[mstensho]

Chromium, Edge and WebKit all seem to implement column-fill:auto as specified in the CR: https://www.w3.org/TR/2011/CR-css3-multicol-20110412/#cf

In particular, when block size is unconstrained, balancing is forced.

Example:

<div style="columns:3; column-fill:auto;">
  column-fill is auto.<br>
  Height is unconstrained<br>
  The old spec says to force balancing in such situations.<br>
  The new spec does not say anything about to that effect.<br>
</div>

Gecko doesn't force balancing in this case, while all the other do it. Gecko appears to follow the new spec: https://drafts.csswg.org/css-multicol/#cf for column-fill:auto. It does have issues with column-fill:balance if height is non-auto, though:

<div style="columns:3; height:20em; column-fill:balance;">
  column-fill is balance.<br>
  Height is non-auto, and large.<br>
  This should still be balanced<br>
  although everything *could* fit in the first column<br>
</div>

All spec versions require the above to be balanced, but Gecko doesn't do it. But note that if you shrink the height from 20em to e.g. 10em it gets balanced - so this looks like a bug and not deliberate behavior.

The spec was changed in 2012 by Håkon Wium Lie:
e0a990c

Given that Gecko has bugs in its implementation, and given that all the others still follow the old spec, I think we have an opportunity to fix the new spec. Most importantly, I'd like the spec to be backward-compatible, so that column-fill:auto forces balancing if block size is unconstrained (and before each spanner).

If we really want a mode that never forces balancing, how about introducing column-fill:fill for that? That mode could even refrain from balancing before spanners (and only break if there are explicit breaks).

[fantasai]

@mstensho Makes sense to me. I think you meant s/constrained/unconstrained/ in the 2nd to last paragraph though?

[mstensho]

@fantasai That's indeed what I meant. :) Edited. Thanks a lot!

[css-meeting-bot]

The CSS Working Group just discussed Improve column-fill and make it backward-compatible.

The full IRC log of that discussion

<heycam> Topic: Improve column-fill and make it backward-compatible
<heycam> github: https://github.com//issues/3224
<gregwhitworth> fantasai: we should chat during a break
<fantasai> kk :)
<heycam> rachelandrew: this was recently raised by Morten Stenshorn, basically saying that we seem toh ave interop with chrome/edge/webkit column-fill:auto about balancing
<heycam> ... when block-size is unconstrained, balancing is forced
<heycam> ... it says Gecko doesn't force balancing in this case
<heycam> ... and Gecko appears to follow what's now in the spec
<heycam> ... I did some digging, the spec was changed in 2012 by Hakon, commented out some text, which led to this interop issue
<heycam> ... Morten is suggesting that we should fix the new spec and make it backwards compat, so column-fill:auto forces balancing if the block size is unconstrained
<heycam> florian: another consideration here is I don't know whether we only do this for compat reasons, or if it's use case driven
<heycam> ... the issue was discovered by trying to fix one of the problems of what the interop impls do
<heycam> ... column-fill auto is supposed to say don't balance
<heycam> ... fill the first column as much as you can
<heycam> ... except it doesn't do that unless you contrain the height
<heycam> ... if you're in a grid, or if you have a min-height, maybe you do want to start not balancing and take the min-height into consideration
<heycam> ... height was not fixed to a number, but it is contrained is size
<heycam> ... so we're trying to patch our way out of that
<heycam> ... if we start with the Gecko behavior, filling as much as you can, then wrap, that solves that problem
<heycam> ... the fact that we have mostly interop, not full interop, we can decide
<heycam> rachelandrew: I've run into the issue of wanting to have a min-height
<heycam> ... if you have a small amount of text, andi t's going to fragment into 3 columns, weithout being able to do the min-height thing, you get short bits of text
<heycam> ... but if you want to say make it at least this height
<heycam> ... that behavior is useful
<heycam> florian: if you have the Gecko behavior as a starting point, you would use max-height instead
<heycam> ... when it reaches that it starts wrapping
<heycam> rachelandrew: certainly a use case for that
<heycam> dbaron: the issue you raised about grid reminds me of an issue we talked on last week's telcon
<heycam> ... seems like the same thing
<heycam> fantasai: I think morten was suggesting it balances only when it's uncontrained
<heycam> ... if you have a min/max height that's a type of contraint
<heycam> florian: it's not what they currently do
<heycam> ... if min/max/height are all auto, but you are contrained by being a grid item...?
<heycam> fantasai: that's contrained
<heycam> florian: that would work for me
<heycam> fantasai: you could say if height is max-content or equivalent in behavior, then we consider that unconstrained
<heycam> ... and it balances
<heycam> rachelandrew: that makes sense
<heycam> florian: seems to me that would work, and not be too disruptive, I'm not convinced it's more useful
<heycam> ... are we trying to minimize the cost of changing impls?
<heycam> florian: that plus web compat plus the idea that when you give something an auto height, it's supposed to fit it to content
<heycam> ... balancing as part of that kind of makes sense
<heycam> ... Morten is also suggesting "don't ever balance" should get its own value
<heycam> s/... Morten/fantasai: /
<heycam> fantasai: the proposal is to accept Morten's suggestion that column-fill:auto does balance only when the height is uncosntrained, which emanse the beahviour is equivalent to min-content
<heycam> florian: I think I agree, just confused about min vs max-content
<heycam> fantasai: I think they're defined to be the same thing?
<heycam> florian: this is one of hte cases where they might want to mean a different thing
<heycam> ... the min would reasonably be the wrapped size, and the max be the unwrapped size
<heycam> ... and it's the unwrapped size that makes sense here
<heycam> dbaron: I think this is probably going in a direction that would be too vague
<heycam> ... so not worth getting to that detail
<heycam> ... if you want a proposal for switching, it needs to be clear about figuring out which case you're in
<heycam> ... the way you just defined it there are still ambiguous cases
<heycam> ... if you ahve a min/max height that probably isn't going to apply in your situation but might in another ?
<heycam> ... if you're in a block where you have this much content, and you have a max-height that's way down there, ...
<heycam> fantasai: ??
<heycam> dbaron: there are a pile of situations like this
<heycam> rachelandrew: I'd be happy to have a go at writing these situations down
<heycam> florian: just to be clear the reason we're going after the Gecko behavior is to minimize the cost of changing?
<heycam> ... or any other reason?
<heycam> fantasai: it's called auto...
<heycam> rachelandrew: I'll bring these back to the group after writing it up
<heycam> fantasai: current proposal, if there's no min/max constraint, and the height is specified to be an automatic size, it's equivalent to min-content
<fantasai> s/size, it's/size that's/

[jensimmons]

To try and understand this issue, I just dropped the examples into a CodePen: https://codepen.io/jensimmons/pen/XxBVLz?editors=1000

[astearns]

I'm assuming this needs writing up before being brought back to the agenda

[rachelandrew]

yes it does - I've not had chance yet

[rachelandrew]

There are some examples to go with this writeup.

The issue as raised is that currently Blink, WebKit and Edge all have implemented column-fill: auto as in an older version of the multicol spec (the one which was at CR before we went back to a WD), the implementations follow text which said:

"In continuous media, this property [column-fill] will only be consulted if the length of columns has been constrained. Otherwise, columns will automatically be balanced."

If you look at the examples in any of those browsers you can see that example 1, with no height has balanced and example 2, with a height has filled columns in turn to the specified height.

This text was commented out in 2012. Firefox has implemented to not balance an unconstrained multicol container.

I haven't looked a lot at non-browser UAs but Prince is doing the same thing as Firefox (so not balancing an unconstrained container, giving us one column of text).

The proposal is to update the spec to match what Blink/WebKit/Edge are doing.

Additional suggestions are to include min- and max- constraints as also being a reason to consult column-fill and not balance when it is auto. My examples 3 and 4 show a multicol container with a min-height of 200 pixels with a larger and smaller amount of content.

There is a use case for including min- as a constraint which is the one where you have a multicol container and sometimes the amount of content added leaves you with one or two lines of text in each column. In that scenario it would be much better to have a single column than spread the content out across multiple columns. Adding a max- constraint might be problematic if sometimes there was a lot more content than expected. As an author I'd find it useful behaviour to be able to set a min-height constraint and column-fill: auto and the columns fill sequentially with no balancing until that min-height is reached. At that point start balancing.

We also have issue #3064 asking for this behaviour.

There is also a suggestion to introduce column-fill: fill as a never balance mode:

"If we really want a mode that never forces balancing, how about introducing column-fill:fill for that? That mode could even refrain from balancing before spanners (and only break if there are explicit breaks)."

There was also discussion in terms of defining what min and max content mean, with @fantasai suggesting that:

"current proposal, if there's no min/max constraint, and the height is specified to be an automatic size, it's equivalent to min-content".

I think the things we need to decide upon are:

1. Should we update the spec to return to the behaviour as implemented in Blink/WebKit/Edge that column-fill: auto balances an unconstrained container, and does not balance a constrained container?
2. Should we include min and max as constraints as requested in [css-multicol] Shouldn't column-fill: auto take min-height into account? #3064
3. Do we want to introduce a never balance mode as suggested by Morten with column-fill: fill?

[frivoal]

My take on this:

1. yes, especially if we also do 2
2. yes
3. possibly, but not in level 1. I'd put that in level 2

[css-meeting-bot]

The CSS Working Group just discussed Improve column-fill and make it backward-compatible,, and agreed to the following:

• RESOLVED: 1. update the spec to return to the behaviour as implemented in Blink/WebKit/Edge that `column-fill: auto` balances an unconstrained container, and does not balance a constrained container
• RESOLVED: include min and max as constraints

The full IRC log of that discussion

<emilio_> topic: Improve column-fill and make it backward-compatible,
<emilio_> github: https://github.com//issues/3224
<emilio_> rachelandrew_: turns out that a commented out sentence in the spec which Blink / WebKit and Edge implement
<emilio_> rachelandrew_: <reads from issue>
<emilio_> rachelandrew_: Firefox does not balance, given that text was commented out in 2012
<emilio_> rachelandrew_: I put together a couple examples
<emilio_> rachelandrew_: Proposal is to update the spec to the behavior WebKit / Blink / Edge
<emilio_> rachelandrew_: Another issue is to include min and max constrains
<emilio_> rachelandrew_: And whether we should introduce a "never-balance" mode
<emilio_> florian[m]: I think we almost concluded last time
<emilio_> florian[m]: we should generally follow the behavior of everybody but firefox, except with the nuance that if it's not min- and max- we never go into the fill mode
<emilio_> florian[m]: as for adding a new fill behavior, not opposed but probably level 3
<emilio_> *2
<emilio_> If we didn't include the min- thing I'd be more reluctant to follow Chrome / Edge / webKit
<emilio_> rachelandrew_: have looked at prince and they match FF
<emilio_> florian[m]: I think web compat is the dominant thing here
<emilio_> florian[m]: 1 and 2 solve the problem sufficiently well that you can do what you want in more cases
<emilio_> rachelandrew_: unless people have objections I think that'd be a good resolution
<emilio_> emilio_: Has FF had compat issues because of that?
<emilio_> florian[m]: no, but others have shipped that behavior for a long time
<emilio_> florian[m]: and if we put 2 together it's not a bad behavior
<emilio_> rachelandrew_: Without being able to do the min-size thing it does get annoying, we use server-side stuff to measure content and not get the weird columns
<emilio_> florian[m]: right, without the 2 part I'd prefer FF, but not otherwise
<emilio_> RESOLVED: 1. update the spec to return to the behaviour as implemented in Blink/WebKit/Edge that `column-fill: auto` balances an unconstrained container, and does not balance a constrained container
<emilio_> RESOLVED: include min and max as constraints