[css-multicol-2] column-height:0

[mstensho]

Should column-height:0 really be allowed? If yes, then https://drafts.csswg.org/css-break/#breaking-rules at least makes the columns at least 1px tall, but not the lines. Maybe that's fine?

@rachelandrew

[rachelandrew]

I'm not sure column-height: 0 makes any sense, but making it at least 1px tall if that does happen seems reasonable.

[frivoal]

I don't think a column-height of 0 is of any use, but I don't know if there's precedent for using a ]0, +∞] open interval for lengths. Open intervals are annoying in that since we don't define the precision, the smallest valid value is implementation dependent, and that's not great. We can work around that by setting a 1px minimum, but then again, why 1px specifically? Why not 1pt, or 1ch, or 0.1ch… it's very arbitrary.

Unless there's precedent or a clever solution I cannot think of, I suspect we should just let it start at 0 at the syntax level, and use a minimum size in terms of actual layout computation (1px will do fine, it's arbitrary, but that bothers me a lot less in layout than in parsing).

[fantasai]

+1 to @frivoal's point about open intervals. Also we already have a precedent for forcing things to be 1px when we need a non-zero size: column-width floors at 1px, and repeat(auto-fit) in Grid floors the effective track size at 1px when trying to calculate how many tracks can fit.

[css-meeting-bot]

The CSS Working Group just discussed [css-multicol-2] column-height:0, and agreed to the following:

• RESOLVED: allow to be zero, let fragmentation spec ensure progress

The full IRC log of that discussion

<TabAtkins> rachelandrew: Noam asked if column-height:0 is allowed.
<TabAtkins> rachelandrew: not really a reason. Grid floors at 1px
<TabAtkins> rachelandrew: so probably what we want to do too
<florian> q+
<TabAtkins> florian: agree.
<astearns> ack kush
<astearns> ack florian
<TabAtkins> florian: so there's no restriction at syntax level, but floor at layout time
<dholbert> q+
<ntim> q+
<fantasai> TabAtkins: We do syntax restrictions all the time, could do 1px+ range which would still be closed range
<astearns> ack dholbert
<dbaron> There's a precedent for this with the perspective property and perspective() function.
<TabAtkins> dholbert: I weakly like having column-ehight:0 available for testing, useful for test printing
<TabAtkins> dholbert: can end up with printing with zero content area
<TabAtkins> dholbert: we make progress by putting *something* on the page
<fantasai> https://www.w3.org/TR/css-break-4/#breaking-rules
<fantasai> "To guarantee progress, fragmentainers are assumed to have a minimum block size of 1px regardless of their used size."
<TabAtkins> dholbert: so like *supporting* height:0
<astearns> ack ntim
<TabAtkins> ntim: if the restriction is at syntax level, what about calc()?
<fantasai> TabAtkins: Same as we handle 0px today
<emilio> q+
<fantasai> TabAtkins: clamp at used value tie
<astearns> ack fantasai
<TabAtkins> fantasai: we already have a rule that says fragmentatiners are assumed to have a min block size of 0px, regardless of used height
<TabAtkins> fantasai: we already have this case if the Multicol container itself has height:0px
<TabAtkins> fantasai: but each column will assume it's 1px high
<TabAtkins> fantasai: so we can do this clamp whenever. computed time, used time, or not at all and rely on the fragmentainer always laying out 1px of ontent
<dholbert> s/fragmentatiners are assumed to have a min block size of 0px/fragmentatiners are assumed to have a min block size of 1px/
<TabAtkins> astearns: I have concerns with relying on fragmentation module, there are layout concerns that aren't necessarily fragmentation concerns
<TabAtkins> astearns: i'd rather have things clamped before we start layout
<astearns> q?
<plinss> q+
<astearns> ack emilio
<TabAtkins> emilio: we'll have to clamp at used-value anyway, is there any benefit to restricting at syntax time?
<TabAtkins> emilio: if not i'd prefer to handle it at layout time
<TabAtkins> fantasai: I think key question is just whether the layout height is 1px, or just the fragmentation height?
<TabAtkins> florian: I think layout height.
<TabAtkins> s/min block size of 0px/min block size of 1px/
<TabAtkins> florian: even if there's overlap, you can at least see progress
<TabAtkins> plinss: want to agree with Elika/Emilio, handle it at layout time rather than syntax time
<fantasai> TabAtkins: We have lots of 0px restrictions, it's well-defined
<florian> q?
<TabAtkins> astearns: so clamping to 1px at used-value time?
<astearns> ack plinss
<TabAtkins> fantasai: yes
<dholbert> +1 to what plinss said
<TabAtkins> plinss: I think used-value time is even too early. let it be zero, require progress
<ntim> +1 to what plinss said
<ntim> +1 to what dholbert said about what plinss said
<TabAtkins> fantasai: proposed resolution: allow to be zero, let fragmentation spec ensure progress
<TabAtkins> astearns: I disagree but won't object
<TabAtkins> florian: same
<TabAtkins> plinss: I think that's the right concept
<TabAtkins> florian: can we poll? we agree it's not syntax time, want to see what our actual pref is
<TabAtkins> RESOLVED: allow to be zero, let fragmentation spec ensure progress