- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 26 Jun 2019 16:27:42 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `column-fill should behave more similarly in paginated and continuous contexts`. <details><summary>The full IRC log of that discussion</summary> <dael> Topic: column-fill should behave more similarly in paginated and continuous contexts<br> <dael> github: https://github.com/w3c/csswg-drafts/issues/4036<br> <dael> Rossen_: Opened by dbaron . Is he on?<br> <dael> [silence]<br> <dael> Rossen_: Can anyone take or should we wait?<br> <dael> florian: I can<br> <dael> florian: There is currently a difference between what happens to columns in fragmeneted and non-frag context and there's no contraint on height<br> <dael> florian: dbaron proposed to align frag context to non-frag<br> <dael> florian: My reason why not is that the behavior spec in frag context is the one pdf and print formatters impl interop. multicol in frag documents is used a lot.<br> <dael> florian: If there wasn't a compat concern we could align but in print we do have a dependency. I don't think they'll change and I don't want to fork language. Based on that I suggest don't<br> <dael> dbaron: Important diff is in browsers people care about print being similar to on screen. If we leave this we end up with for multicols that happen to be in frag context and don't frag or for the last frag of a multicol in frag context you get different balancing then on screen. Problematic. Most for when you print and it's not frag and balancing on paper is different.<br> <fantasai> So basically we have two different, conflicting compat constraints. :/<br> <dael> Rossen_: dbaron to visualize I'm assuming talking about multicol that has auto balance and in the continuous space you have plenty of height so no balance<br> <dael> dbaron: yeah<br> <dael> Rossen_: In print when we reach the last frag where the column would otherwise frag to one per page we're not balancing per frag we'll have 1 column per frag<br> <dael> dbaron: Not sure what you mean. Confused me with last bit<br> <florian> this table has the summary: https://github.com/w3c/csswg-drafts/issues/4036#issuecomment-503648397<br> <dael> Rossen_: When we go to print and we have fragment now they have a constrained height which triggers balancing<br> <dael> Rossen_: Or did I mis-read?<br> <AmeliaBR> Is “make browsers match print behavior” (for the last fragment OR for no fragments) still an option?<br> <dael> Rossen_: What is different between continuous medium and fragmented<br> <dael> florian: 2 tables in GH, 2nd is correct. unconstrained frag with auto the columns don't balance.<br> <dael> florian: Would switch to balance columns when column fill is auto in an unconstrained context. Can't have unbalanced column on last page<br> <dael> Rossen_: Balancing on last page in my case, it's only on last page with current prop?<br> <dael> florian: All pages including last.<br> <dael> florian: Currently it's all except last (I think)<br> <fantasai> I think the mistake in multicol was that continuous media balances in cases where print does not, but I guess that's not fixable...<br> <dael> dbaron: With column-fill:auto and unconstrained height you do not balance on any page in frag context. In continuous you balance<br> <dael> florian: Okay. I missed a step. I think print formatters balance on every page but the last.<br> <dael> Rossen_: That's...interesting. Almost opposite of proposal<br> <dael> florian: Proposal assumes spec says on non-last pages don't balance. That's not what print impl do. They don't balance on last page but do on others. Let me check spec<br> <dael> Rossen_: Reason I looked at table as misleading you said for auto balancing unconstrained if you're in frag and not last you won't balance. If you're in frag context and last you will balance. Continuous you always balance. Right dbaron ?<br> <dael> dbaron: In continuous you don't balance with auto and constrained.<br> <dael> Rossen_: Unconstrained case. When you're in frag context but not last frag you don't balance<br> <dael> florian: That's dbaron table but spec says when value is auto you fill sequentially<br> <dael> dbaron: Let me open spec. I think there's words. Not in value def.<br> <dael> Rossen_: Sounds like in this cae we print 4 pages with one column and on last page we have 3 col and that's weird. We either always or never balance. Half and half is weird.<br> <dael> dbaron: I think the previous resolution was also somewhat odd. Reverting previous resolution gets us consistent state<br> <dael> Rossen_: [missed]<br> <dael> florian: Which dbaron ?<br> <dael> Rossen_: 3224?<br> <dael> dbaron: Yes<br> <Rossen_> https://github.com/w3c/csswg-drafts/issues/3224<br> <dael> Rossen_: This one ^<br> <dael> [everyone reads]<br> <dael> dbaron: Regarding florian question on auto, I agree it's not clear for unblanaced. Clear for balance they are not. Balance says [reads]<br> <dael> florian: What that means is not single col is filled, all filled. but if you honor force break they have different heights. Means you fill sequentially<br> <dael> dbaron: That's what I mean by not balanced in my table<br> <dael> florian: Except for last frag where not balance means fill first column and stop<br> <dael> dbaron: With auto height?<br> <dael> florian: Yes<br> <dael> dbaron: Messy with auto height where have to define auto height calc which can vary<br> <dael> florian: There's two behaviors for the no. Fill multiple and no balance or fill a single column<br> <dael> dbaron: At a high level you might see those, but it's a result of what auto-height calculation does<br> <dael> florian: What we'd lose with your prop is ability on last page to only fill first column. Or do you not lose that?<br> <dael> florian: If you have mutli page and last has only enough to fill 2/3 of one column printers have 1 column and your prop there is 3<br> <dael> dbaron: Correct. Changed for continuous already in previous resolution.<br> <dael> dbaron: There are cases where mutlicol is relatively small. You may well print and it fits on one page<br> <dael> dbaron: So if you're in this case where previous resolution effects and it fits on one page previous resolution only applies before you print. Afte ryou print we do completely the opposite. That's a major inconsistancy<br> <dael> florian: True. Two problems. browser printing vs printing and pdf printing vs printing<br> <dael> florian: What will save us if you called for auto it's okay and [missed]<br> <dael> dbaron: Reality of printing in browsers users care about results even if authors didn't<br> <dael> fantasai: I think florian says we've got conflicting compat constraints<br> <dael> dbaron: 3<br> <dael> fantasai: Ones I"m aware of is printing through pdf formatter and printing through abrowser should have same result. Other is printing through a browser should have same result as looking at page without printing.<br> <dael> dbaron: 2 web compat. One is PDF. Other is what led to 3224 which is Chromium and Webkit did one thing and Gecko the other.<br> <dael> fantasai: So that's a 3rd<br> <dael> fantasai: What florian pointed out is because auto is not initial it's possible 3rd between Chromium and others is not incompat and we can revert<br> <dael> florian: THat's possible. What I was saying is because balance is initial most browsers will be on balance and when you print it gets you the same thing. Don't change balance. For auto behavior changes only if you haven't cosntrained. If you constrained auto and balance do the same. If they do both or neither we're safe.<br> <dael> dbaron: People leave things in code that didn't work<br> <dael> florian: True. I agree revert prevoius if we can. That's only sane way. Would require WK and Chromium to change<br> <dael> Rossen_: Opinions from WebKit or Chromium impl?<br> <dael> [silence]<br> <dael> dbaron: I think we could cycle back. I don't know if Morten is on but he seems to know about Chromium limitation. There was new information an hour before the call<br> <dael> florian: Sorry, jsut finished compat testing<br> <dael> dbaron: There's a new proposal, should let it cycle on the issue and come back.<br> <dael> fantasai: Anyone else on the call with a concern or are we proposing what florian and dbaron say?<br> <dael> Rossen_: Proposal is revert resolution on issue #3224. With that we leave discussion open for a week. When others can catch up we can re-open the issue and try to resolve.<br> <dael> florian: sgtm<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/4036#issuecomment-505948861 using your GitHub account
Received on Wednesday, 26 June 2019 16:27:46 UTC