[css-multicol] Defining what happens with column-fill in unconstrained containers for continuous and fragmented contexts #4689
Comments
|
The CSS Working Group just discussed
The full IRC log of that discussion<TabAtkins> Topic: column-fill in unconstrained containers<TabAtkins> github: https://github.com//issues/4689 <TabAtkins> rachelandrew: New issue, but refers back to a previous issue; trying to wrap up. <TabAtkins> rachelandrew: Previous Multicol said that in continuous media, column-fill is only used if height of columns is constrained; otherwise they're balanced. <TabAtkins> rachelandrew: Was commented out in 2012. <TabAtkins> rachelandrew: Chrome and WK implemented column-fill as if that line was there; Firefox implemented without. <TabAtkins> rachelandrew: We put the line back in in #3224, to match Chrome, but in #4036 we reverted based on dbaron's issue. <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 <TabAtkins> rachelandrew: So we need to figur eout what to do when column-fill:auto and unconstrained height <TabAtkins> rachelandrew: If we honor it, that means all the content goes into the first column. <TabAtkins> rachelandrew: This is only outstanding issue in multicol. <TabAtkins> florian: In addition to Firefox vs WK, there was browser vs print aspect <TabAtkins> florian: Wanted consistency between multiple things. <TabAtkins> florian: "browser when screen" and "browser when printing" should act the same <TabAtkins> florian: Shouldn't ranodmly become different, people don't test <TabAtkins> florian: And also didn't want browsers and print formatters to do different things <TabAtkins> florian: It seemd to me there was only one behavior we could use that satisfies those <TabAtkins> rachelandrew: We resolved to revert the change and put an issue in the spec in Fukuoka <TabAtkins> florian: dbaron, do you remember what the "one harmonious approach" was? <TabAtkins> dbaron: I think our conclusion was... <TabAtkins> dbaron: There were two constraints. <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. <TabAtkins> dbaron: Second is making the behavior of print formatters, and browsers when printing, consistent. <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. <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 <TabAtkins> timeless: Prince matches Firefox <heycam> s/timeless/faceless/ <TabAtkins> florian: remaining open question is, are Blink and WK willing to do it? <TabAtkins> rachelandrew: Morten says yes, but we'd have to clarify what colum-fill:auto and height:auto means <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. <TabAtkins> dbaron: I'm reading Fukuoka minutes, but I think we already decided to do this. <TabAtkins> dbaron: Morten was concerned about, once we make that change, there's more that needs to be defined more clearly. <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. <TabAtkins> dbaron: Resolution was "revert #3224, and add spec issues to define this" <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. <TabAtkins> dbaron: I suspect Morten might be the best to remember what that undefined stuff was. <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. <TabAtkins> florian: Was the question about min-height:auto, max-height, etc. <TabAtkins> dbaron: [reads Morten's comment] <dbaron> was reading https://github.com//issues/4036#issuecomment-508378790 <TabAtkins> rachelandrew: All riht, so I'll need to talk to Morten to see what he was really wanting to be defined <TabAtkins> rachelandrew: Can we have a clear resolution confirming this position? <TabAtkins> iank_: Yeah, could we have fully defined behavior before we make the change? <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. |
|
@mstensho in #4036 (comment) you said:
We have resolved that the spec will match Firefox's behavior. Could you raise issues if there is anything you think needs extra definition? I'll also be raising the browser bugs for this. If you don't think there is anything else, then that would be helpful too as it's the final piece before going to CR. |
|
Per my testing, Firefox doesn't balance content before spanners if column-fill is auto (and height isn't sufficiently constrained, if at all), effectively putting everything into one column (unless there are forced breaks). Isn't this a bit weird / useless? |
|
I think we should always balance before spanners. As far as I can tell that's what the spec says to do:
|
|
Yes the column-fill stuff we were debating didn't mention anything about the situation when there is a spanner I don't think. So the Firefox behavior (of putting everything into one column if height isn't constrained) is what we agreed on, however do we need to clarify whether that does or does not happen before a spanner. Does the specced spanner behavior trump the column-fill instruction? |
I believe it should. I don't know of any use case for a spanner without balancing the part of the fragment above it. |
|
The CSS Working Group just discussed
The full IRC log of that discussion<Rossen_> Topic: Defining what happens with column-fill in unconstrained containers for continuous and fragmented contexts<Rossen_> github https://github.com//issues/4689 <Rossen_> github: https://github.com//issues/4689 <fantasai> rachelandrew: Last F2F resolved we want to go with behavior that Firefox has wrt column-fill <fantasai> rachelandrew: and falling out of that, spec text doesn't say anything about spanners, should we always balance before spanners <fantasai> rachelandrew: clarification was that where firefox is putting everything in one column, need to clarify if that happens before spanner or not <fantasai> rachelandrew: does that trump column-fill ? <Rossen_> q? <Rossen_> ack florian <Zakim> florian, you wanted to say I am still confused as how the switch proposal solves the circularity problem <florian> q- <florian> q+ <Rossen_> fantasai: we should be balancing between spanners... pretty sure that was our original intention <fantasai> rachelandrew: Can't think of a use case for not balancing before a spanner <Rossen_> ack fantasai <fantasai> florian: Further clarification, should balance from start of current fragmentainer <Rossen_> ack florian <fantasai> florian: previous fragmentainers are independentof that <Rossen_> ack dbaron <fantasai> dbaron: I think I agree that balancing before spanner is the right thing <fantasai> dbaron: Brings up question of whether current balancing control is the right thing <fantasai> dbaron: do you balance at end, before fragment break, before spanner ... three things <fantasai> dbaron: do we need more controls? or do people don't really care so much about the others <Rossen_> q? <fantasai> dbaron: Balance before spanner seems fine <florian> q- <fantasai> Rossen_: +1 I think that's what we did in our EdgeHTML implementation of multicol <fantasai> Rossen_: Any objectins? <fantasai> s/tins/tions/ <fantasai> RESOLVED: Balance before spanners always <myles> ScribeNick: myles |
…mmediately preceding a spanner per WG resolution. #4689 <https://lists.w3.org/Archives/Public/www-style/2020May/0002.html>
A previous version of the multicol specification contained the paragraph:
This was commented out in the spec in 2012.
Chrome and Webkit implemented column-fill as per this line in the spec. Therefore the value of
column-fillis only consulted if (in horizontal-tb) aheighthas been given.The initial value for
column-fillisbalanceso content is balanced across columns. If we usecolumn-fill: autothe browser should fill columns sequentially.See this CodePen.
In example 1 we have an unconstrained container and
column-fill: auto. Chrome is ignoringcolumn-filland continues to do the default of balancing. Firefox is consulting thecolumn-fillproperty and because the container is unconstrained fills the first column with all content.In example 2 we do have a height on the container and so both browsers do the same thing - filling the columns sequentially.
We resolved in #3224 (comment) to return the spec to match the Chrome implementation, and also to add min and max-height as a constraint that would trigger this behavior.
Then in #4036 we reverted this change, leaving the behavior undefined.
In #4036 @dbaron suggested changing the text to say:
and also provided a table of what the different values would mean. The Yes/No column is whether we balance (yes) or not (no) and the asterisk the values that would change.
So we need to decide what happens when a multicol container is not constrained and
column-fillisauto. Do we return to the previous spec behavior (like Chrome and Webkit) or do what Firefox does and always honorauto?If we do return to the previous behavior, do we make the addition that @dbaron suggested and in fragmented contexts also consult the property when we are in the last fragment?
The text was updated successfully, but these errors were encountered: