- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Thu, 23 Jan 2020 09:33:33 +0000
- To: public-css-archive@w3.org
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> <TabAtkins> Topic: column-fill in unconstrained containers<br> <TabAtkins> github: https://github.com/w3c/csswg-drafts/issues/4689<br> <TabAtkins> rachelandrew: New issue, but refers back to a previous issue; trying to wrap up.<br> <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> <TabAtkins> rachelandrew: Was commented out in 2012.<br> <TabAtkins> rachelandrew: Chrome and WK implemented column-fill as if that line was there; Firefox implemented without.<br> <TabAtkins> rachelandrew: We put the line back in in #3224, to match Chrome, but in #4036 we reverted based on dbaron's issue.<br> <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> <TabAtkins> rachelandrew: So we need to figur eout what to do when column-fill:auto and unconstrained height<br> <TabAtkins> rachelandrew: If we honor it, that means all the content goes into the first column.<br> <TabAtkins> rachelandrew: This is only outstanding issue in multicol.<br> <TabAtkins> florian: In addition to Firefox vs WK, there was browser vs print aspect<br> <TabAtkins> florian: Wanted consistency between multiple things.<br> <TabAtkins> florian: "browser when screen" and "browser when printing" should act the same<br> <TabAtkins> florian: Shouldn't ranodmly become different, people don't test<br> <TabAtkins> florian: And also didn't want browsers and print formatters to do different things<br> <TabAtkins> florian: It seemd to me there was only one behavior we could use that satisfies those<br> <TabAtkins> rachelandrew: We resolved to revert the change and put an issue in the spec in Fukuoka<br> <TabAtkins> florian: dbaron, do you remember what the "one harmonious approach" was?<br> <TabAtkins> dbaron: I think our conclusion was...<br> <TabAtkins> dbaron: There were two constraints.<br> <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> <TabAtkins> dbaron: Second is making the behavior of print formatters, and browsers when printing, consistent.<br> <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> <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> <TabAtkins> timeless: Prince matches Firefox<br> <heycam> s/timeless/faceless/<br> <TabAtkins> florian: remaining open question is, are Blink and WK willing to do it?<br> <TabAtkins> rachelandrew: Morten says yes, but we'd have to clarify what colum-fill:auto and height:auto means<br> <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> <TabAtkins> dbaron: I'm reading Fukuoka minutes, but I think we already decided to do this.<br> <TabAtkins> dbaron: Morten was concerned about, once we make that change, there's more that needs to be defined more clearly.<br> <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> <TabAtkins> dbaron: Resolution was "revert #3224, and add spec issues to define this"<br> <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> <TabAtkins> dbaron: I suspect Morten might be the best to remember what that undefined stuff was.<br> <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> <TabAtkins> florian: Was the question about min-height:auto, max-height, etc.<br> <TabAtkins> dbaron: [reads Morten's comment]<br> <dbaron> was reading https://github.com/w3c/csswg-drafts/issues/4036#issuecomment-508378790<br> <TabAtkins> rachelandrew: All riht, so I'll need to talk to Morten to see what he was really wanting to be defined<br> <TabAtkins> rachelandrew: Can we have a clear resolution confirming this position?<br> <TabAtkins> iank_: Yeah, could we have fully defined behavior before we make the change?<br> <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