- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Tue, 13 Feb 2024 00:13:04 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-multicol] What is the max-content width of a muticol container with only column-width:<length>`, and agreed to the following: * `RESOLVED: Define the behavior we want with forced breaks (column-width * (forced-break-count + 1)), with the forced-break situation at risk, in multicol L2` <details><summary>The full IRC log of that discussion</summary> <emilio> rachelandrew: so there's this interop issue if you have a fixed column-width, column-count: auto, and max-content on the container<br> <emilio> ... FF uses one column with everything else<br> <emilio> ... WebKit / Blink uses the max-content size of the inner thing<br> <florian> q+<br> <emilio> ... this used to get spec'd to say what FF did, but got removed<br> <emilio> ... none of the behaviors seems particularly useful<br> <emilio> ... Q: should this be part of multicol or sizing?<br> <emilio> ... Also: what behavior do we want?<br> <emilio> ... the ff behavior is probably more useful<br> <emilio> ... I put a codepen in the issue with an example of a huge<br> <emilio> florian: I suspect ff behavior is better<br> <astearns> ack florian<br> <emilio> ... yeah it's a single column but it's a single size<br> <emilio> ... chrome will size it as it was a block but due to gaps and such then it would create columns<br> <emilio> ... ff behavior is simple and non-dangerous<br> <emilio> rachelandrew: my guess is that this were to happen this would be a mistake<br> <astearns> ack dbaron<br> <emilio> ... so really I think we should just get interop on it<br> <emilio> dbaron: I can think of two other somewhat-reasonable possibilities for what this might mean<br> <emilio> ... one is to count all the column-breaks and you have that number of columns<br> <emilio> ... the other find the longest required height between column breaks, and compute the number of breaks that you'd have if you were breaking at that height<br> <emilio> astearns: there's nothing about height<br> <emilio> iank_: you could be height-constrained<br> <emilio> dbaron: in that sense multicol is conceptually like a writing-mode switch<br> <emilio> ... in that you can be using a height as input and a width as output rather than the other way around<br> <emilio> ... not sure if people actually want these things<br> <emilio> ... if you want a multicol that could be as short as possible then this could be what you want?<br> <emilio> ... not sure if worth the complexity<br> <emilio> rachelandrew: I couldn't come up with any use case that justifies making anything more complicated<br> <emilio> ... not sure that that value would infer what you're suggesting this could do<br> <astearns> ack fantasai<br> <Zakim> fantasai, you wanted to bring up the fixed height question<br> <emilio> fantasai: so a long time ago tab and I tried to map what are the intrinsic sizes for multicol<br> <emilio> ... we dropped that because nobody was interested in it<br> <emilio> ... the idea was that it should go in multicol, but it ended up in sizing<br> <emilio> ... the questions you need to ask is:<br> <emilio> ... what is the goal of max-content? Lay out assuming you have infinite spaceew<br> <emilio> s/spaceew/space<br> <emilio> ... then you choose the size that is doesn't use more space than you can usefully use<br> <emilio> ... so you wouldn't layout a max-content size of 100x the column width if you have 5x the column-width<br> <emilio> ... if you have an unrestricted block size then you are not going to break and you have only 1 column<br> <emilio> ... if you have a forced column break you could have a bigger max-content<br> <emilio> ... so you could use (n+1)*forced-column-break-count<br> <emilio> ... then you also need to know what to do if you have a constrained height<br> <emilio> ... but then you need to do layout and it gets complex / cyclic with spanners / etc.<br> <emilio> ... we defined something that was getting the right answer in most cases<br> <emilio> ... so that's a bit of the history and thought process<br> <emilio> ... so for unconstrained height I think we could do (n + 1)*forced-column-breaks<br> <emilio> ... the constrained case is more complicated<br> <dbaron> (N-forced-column-breaks + 1) * width, I think<br> <emilio> rachelandrew: that's reasonable but not sure what ff does with force column breaks<br> <emilio> err, yes<br> <emilio> dholbert: I don't think we look at forced breaks<br> <emilio> rachelandrew: so you think it should go to multicol instead of sizing?<br> <emilio> fantasai: yeah, probably<br> <dholbert> https://bugzilla.mozilla.org/show_bug.cgi?id=1840944 (open) is filed on break-before:column in Firefox<br> <dbaron> dbaron: I had forgotten we'd changed multicol so auto heights didn't lead to non-forced column breaks.<br> <emilio> iank_: we'd need to do layout to know how many forced column breaks you need<br> <emilio> ... because some forced column breaks might collapse into each other<br> <emilio> q+<br> <emilio> astearns: would you be fine with that?<br> <astearns> ack emilio<br> <emilio> iank_: I think so, need to check with mstensho but I think it'd be fine to run layout inside the max-content computation<br> <TabAtkins> emilio: i have a slight pref to avoid doing layout during intrinsic sizing<br> <TabAtkins> emilio: I think it's just - it's an easy way to create perf bottlenecks<br> <fantasai> [archived slides for the scoped transitions discussion: https://lists.w3.org/Archives/Public/www-archive/2024Feb/att-0000/scoped-transitions.pdf ]<br> <TabAtkins> iank_: welcome to my life<br> <TabAtkins> iank_: was this issue from a webdev?<br> <TabAtkins> emilio: from xxx<br> <TabAtkins> iank_: we could resolve on the firefox model for now and fix it later if we actually need it<br> <TabAtkins> emilio: yeah i'd prefer that. doing layout for intrinsic size creates funky problems<br> <TabAtkins> TabAtkins: don't we already have that for column flexboxes?<br> <TabAtkins> iank_: Yup. Grid too. But we're the only one that's shipped the flexbox behavior.<br> <emilio> s/xxx/Ting-Yu, who works with us<br> <TabAtkins> astearns: so two options. (1) spec the firefox behavior, whcih isn't useful but is less weird, or (2) do the thing with forced breaks, which is less simple but more useful<br> <emilio> astearns: so two options, spec FF behavior, or do the actual thing with forced breaks that is useful that nobody asked for<br> <emilio> fantasai: I propose to spec the forced-break behavior and mark the behavior as at-risk<br> <emilio> florian: the behavior with force breaks is somewhat complicated<br> <fantasai> s/at-risk/at-risk for handling forced-breaks/<br> <emilio> florian: so the complication for unconstrained size is counting the forced breaks, right<br> <emilio> fantasai: the constrained case is harder but this should be relatively straight-forward<br> <emilio> astearns: so resolve on accommodating force breaks, put it at risk in L2?<br> <florian> s/counting the forced breaks/figuring out which forced breaks coincide<br> <emilio> RESOLVED: Define the behavior we want with forced breaks (column-width * (forced-break-count + 1)), with the forced-break situation at risk, in multicol L2<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9103#issuecomment-1939833852 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 13 February 2024 00:13:07 UTC