- From: CSS Meeting Bot via GitHub <noreply@w3.org>
- Date: Fri, 14 Nov 2025 03:19:09 +0000
- To: public-css-archive@w3.org
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` <details><summary>The full IRC log of that discussion</summary> <TabAtkins> rachelandrew: Noam asked if column-height:0 is allowed.<br> <TabAtkins> rachelandrew: not really a reason. Grid floors at 1px<br> <TabAtkins> rachelandrew: so probably what we want to do too<br> <florian> q+<br> <TabAtkins> florian: agree.<br> <astearns> ack kush<br> <astearns> ack florian<br> <TabAtkins> florian: so there's no restriction at syntax level, but floor at layout time<br> <dholbert> q+<br> <ntim> q+<br> <fantasai> TabAtkins: We do syntax restrictions all the time, could do 1px+ range which would still be closed range<br> <astearns> ack dholbert<br> <dbaron> There's a precedent for this with the perspective property and perspective() function.<br> <TabAtkins> dholbert: I weakly like having column-ehight:0 available for testing, useful for test printing<br> <TabAtkins> dholbert: can end up with printing with zero content area<br> <TabAtkins> dholbert: we make progress by putting *something* on the page<br> <fantasai> https://www.w3.org/TR/css-break-4/#breaking-rules<br> <fantasai> "To guarantee progress, fragmentainers are assumed to have a minimum block size of 1px regardless of their used size."<br> <TabAtkins> dholbert: so like *supporting* height:0<br> <astearns> ack ntim<br> <TabAtkins> ntim: if the restriction is at syntax level, what about calc()?<br> <fantasai> TabAtkins: Same as we handle 0px today<br> <emilio> q+<br> <fantasai> TabAtkins: clamp at used value tie<br> <astearns> ack fantasai<br> <TabAtkins> fantasai: we already have a rule that says fragmentatiners are assumed to have a min block size of 0px, regardless of used height<br> <TabAtkins> fantasai: we already have this case if the Multicol container itself has height:0px<br> <TabAtkins> fantasai: but each column will assume it's 1px high<br> <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<br> <dholbert> s/fragmentatiners are assumed to have a min block size of 0px/fragmentatiners are assumed to have a min block size of 1px/<br> <TabAtkins> astearns: I have concerns with relying on fragmentation module, there are layout concerns that aren't necessarily fragmentation concerns<br> <TabAtkins> astearns: i'd rather have things clamped before we start layout<br> <astearns> q?<br> <plinss> q+<br> <astearns> ack emilio<br> <TabAtkins> emilio: we'll have to clamp at used-value anyway, is there any benefit to restricting at syntax time?<br> <TabAtkins> emilio: if not i'd prefer to handle it at layout time<br> <TabAtkins> fantasai: I think key question is just whether the layout height is 1px, or just the fragmentation height?<br> <TabAtkins> florian: I think layout height.<br> <TabAtkins> s/min block size of 0px/min block size of 1px/<br> <TabAtkins> florian: even if there's overlap, you can at least see progress<br> <TabAtkins> plinss: want to agree with Elika/Emilio, handle it at layout time rather than syntax time<br> <fantasai> TabAtkins: We have lots of 0px restrictions, it's well-defined<br> <florian> q?<br> <TabAtkins> astearns: so clamping to 1px at used-value time?<br> <astearns> ack plinss<br> <TabAtkins> fantasai: yes<br> <dholbert> +1 to what plinss said<br> <TabAtkins> plinss: I think used-value time is even too early. let it be zero, require progress<br> <ntim> +1 to what plinss said<br> <ntim> +1 to what dholbert said about what plinss said<br> <TabAtkins> fantasai: proposed resolution: allow to be zero, let fragmentation spec ensure progress<br> <TabAtkins> astearns: I disagree but won't object<br> <TabAtkins> florian: same<br> <TabAtkins> plinss: I think that's the right concept<br> <TabAtkins> florian: can we poll? we agree it's not syntax time, want to see what our actual pref is<br> <TabAtkins> RESOLVED: allow to be zero, let fragmentation spec ensure progress<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/12787#issuecomment-3530646130 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Friday, 14 November 2025 03:19:10 UTC