Re: [csswg-drafts] [css-multicol] Defining what happens with column-fill in unconstrained containers for continuous and fragmented contexts (#4689)

The CSS Working Group just discussed `column-fill in unconstrained containers`, and agreed to the following:

* `RESOLVED: Confirm that we do indeed want (at least generally) Firefox's behavior, and get Morten to confirm exactly what he wants clarified in further issues.`

<details><summary>The full IRC log of that discussion</summary>
&lt;TabAtkins> Topic: column-fill in unconstrained containers<br>
&lt;TabAtkins> github: https://github.com/w3c/csswg-drafts/issues/4689<br>
&lt;TabAtkins> rachelandrew: New issue, but refers back to a previous issue; trying to wrap up.<br>
&lt;TabAtkins> rachelandrew: Previous Multicol said that in continuous media, column-fill is only used if height of columns is constrained; otherwise they're balanced.<br>
&lt;TabAtkins> rachelandrew: Was commented out in 2012.<br>
&lt;TabAtkins> rachelandrew: Chrome and WK implemented column-fill as if that line was there; Firefox implemented without.<br>
&lt;TabAtkins> rachelandrew: We put the line back in in #3224, to match Chrome, but in #4036 we reverted based on dbaron's issue.<br>
&lt;TabAtkins> rachelandrew: dbaron suggested we change the line to say "in continous context, and last fragment in fragmented contexts...", and I updated the table accordingly<br>
&lt;TabAtkins> rachelandrew: So we need to figur eout what to do when column-fill:auto and unconstrained height<br>
&lt;TabAtkins> rachelandrew: If we honor it, that means all the content goes into the first column.<br>
&lt;TabAtkins> rachelandrew: This is only outstanding issue in multicol.<br>
&lt;TabAtkins> florian: In addition to Firefox vs WK, there was browser vs print aspect<br>
&lt;TabAtkins> florian: Wanted consistency between multiple things.<br>
&lt;TabAtkins> florian: "browser when screen" and "browser when printing" should act the same<br>
&lt;TabAtkins> florian: Shouldn't ranodmly become different, people don't test<br>
&lt;TabAtkins> florian: And also didn't want browsers and print formatters to do different things<br>
&lt;TabAtkins> florian: It seemd to me there was only one behavior we could use that satisfies those<br>
&lt;TabAtkins> rachelandrew: We resolved to revert the change and put an issue in the spec in Fukuoka<br>
&lt;TabAtkins> florian: dbaron, do you remember what the "one harmonious approach" was?<br>
&lt;TabAtkins> dbaron: I think our conclusion was...<br>
&lt;TabAtkins> dbaron: There were two constraints.<br>
&lt;TabAtkins> dbaron: One was we dont' want the rules between continuous and fragmented contexts to be different, such that you get different results if you ahve a small multicol in a fragmented context that is small enough to not fragment.<br>
&lt;TabAtkins> dbaron: Second is making the behavior of print formatters, and browsers when printing, consistent.<br>
&lt;TabAtkins> dbaron: I think shortest path to satisfy both and be sensible is Chrome and WK changing their behavior, I think to the Gecko one.<br>
&lt;TabAtkins> dbaron: I think if we look at continouous context behavior, it woudl involve Chrome and WK matching Gecko. I don't remember about fragment context<br>
&lt;TabAtkins> timeless: Prince matches Firefox<br>
&lt;heycam> s/timeless/faceless/<br>
&lt;TabAtkins> florian: remaining open question is, are Blink and WK willing to do it?<br>
&lt;TabAtkins> rachelandrew: Morten says yes, but we'd have to clarify what colum-fill:auto and height:auto means<br>
&lt;TabAtkins> iank_: Morten's fine, yes. Depending on how diffiuclt, we might not get to it immediately; it might wait for our new fragmenting impl.<br>
&lt;TabAtkins> dbaron: I'm reading Fukuoka minutes, but I think we already decided to do this.<br>
&lt;TabAtkins> dbaron: Morten was concerned about, once we make that change, there's more that needs to be defined more clearly.<br>
&lt;TabAtkins> dbaron: so I think we agreed on the behavior we wanted, but then needed to follow up with issues to make it more fully defined.<br>
&lt;TabAtkins> dbaron: Resolution was "revert #3224, and add spec issues to define this"<br>
&lt;TabAtkins> dbaron: So I think our resolution was reverting, and then there were other issues that aren't fullyd efined and need to be defined.<br>
&lt;TabAtkins> dbaron: I suspect Morten might be the best to remember what that undefined stuff was.<br>
&lt;TabAtkins> iank_: And I think Morten wanted it to all be done at once rather than a dripfeed of impl issues, so he'll want it all defined before he makes the change.<br>
&lt;TabAtkins> florian: Was the question about min-height:auto, max-height, etc.<br>
&lt;TabAtkins> dbaron: [reads Morten's comment]<br>
&lt;dbaron> was reading https://github.com/w3c/csswg-drafts/issues/4036#issuecomment-508378790<br>
&lt;TabAtkins> rachelandrew: All riht, so I'll need to talk to Morten to see what he was really wanting to be defined<br>
&lt;TabAtkins> rachelandrew: Can we have a clear resolution confirming this position?<br>
&lt;TabAtkins> iank_: Yeah, could we have fully defined behavior before we make the change?<br>
&lt;TabAtkins> RESOLVED: Confirm that we do indeed want (at least generally) Firefox's behavior, and get Morten to confirm exactly what he wants clarified in further issues.<br>
</details>


-- 
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/4689#issuecomment-577600255 using your GitHub account

Received on Thursday, 23 January 2020 09:33:35 UTC