- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 04 May 2022 23:36:46 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-flexbox] Multi-line column flexbox fragmentation`, and agreed to the following: * `RESOLVED: not required to re-wrap from column flexboxes in order to avoid overflow` <details><summary>The full IRC log of that discussion</summary> <dael> Topic: [css-flexbox] Multi-line column flexbox fragmentation<br> <dael> github: https://github.com/w3c/csswg-drafts/issues/6855<br> <dael> alisonmaher: I think fantasai put this on the agenda so could do a better job summerizing<br> <dael> fantasai: We were gonna spec the behavior but had questions about exactly what to spec in terms of frag influencing sizes of boxes<br> <Rossen_> example being described - https://github.com/w3c/csswg-drafts/issues/6855#issuecomment-1102928864<br> <dael> fantasai: Let's say you have 4 boxes inside container and splits across pages. Point it frag can cause flex items to get taller which changes alignment and space distribution<br> <dael> fantasai: ideally no overflow. Author doesn't expect overflow b/c said to wrap<br> <dael> fantasai: Question is do we want to put and algo that requires passing info and poss re-wraping or do we want to have overflow? What are the consiquences of frag that we'll accept<br> <Rossen_> q?<br> <dael> iank_: I can touch on this for grid since has similar problems<br> <dael> iank_: Grid will run the full layout algo, get where everything is and size. Then it will perform fragmentation step<br> <dael> iank_: There's just small adjustments when it makes sense. If a grid item is auto-height then we will grow out that item and shift things below it down. Try not to cause overlap. Similarly will stretch other grid items<br> <dael> iank_: When looking atflex wanted to follow similar. When you try and rerun is a problem.Similar where you run algo once and do fragmentation fixups seems good solution<br> <dael> fantasai: Diff between grid and flexbox, grid you placed the items in the rows. If the author has overconstrainded then you overflow, but if it will fit there is no problem. Flexbox you run for a column, see what fits, and then wrap. if you grow b/c the stacking you will overflow the box<br> <dael> iank_: Unless box is auto height<br> <dael> fantasai: IN which case you wouldn't wrap<br> <dael> iank_: Right. I think this is relatively rare for flexbox columns. Fundamentally issue with frag is in order to frag you need to place in fragmentainer. Codependency on position and size<br> <dael> iank_: I don't think it's bad...most of the time if opt for new column there may be space under. Most of the time expansion is small. Don't know if it's much of a problem in practical<br> <dael> fantasai: Could be an image. Point is are we going to overflow when frag and is that acceptable<br> <dael> iank_: I think cases would be rare and it's acceptable<br> <dael> iank_: alisonmaher did you want to add anything?<br> <dael> alisonmaher: Not much to add. Agree. note for out of flow frag we'd overflow or go past the end if end aligned. Doing similar is not too big a problem<br> <dael> fantasai: I don't think overflow bottom aligned stuff is great idea. Authors bottom align a lot and don't expect overflow when print. case with columns and wrapping you don't have a choice, but for alignment there's all that space you could have used to fit the item. Overflow doesn't make sense<br> <dael> iank_: Alignment topic has same problem in grid. If you center or bottom align have potential to overflow. if you don't do that algo becomes impossible to impl<br> <dael> iank_: In order to know how large something is you have to place, if you change placement need to resize<br> <dael> fantasai: Not impossible, but really unpleasent if layout from top to bottom. Could do from bottom to top, but I don't expect that<br> <dael> fantasai: More important to align correctly or not have overflow when print? Or a way to not have either problem<br> <dael> Rossen_: It's important to make sure we have a stable algo so we don't run into performance clips that would be terrible when not printing<br> <dael> Rossen_: With infinate time we can compute beuatiful layouts, but want to make sure this is close to linear<br> <dael> fantasai: I don't think linearity is problem there. I can accept fxied height column wrapped fragmenting is rare. I don't think that is true for alignment in general. I don't think we should overflow content when printing things bottom aligned. More complicated and simplier ways to avoid, but shouldn't cause overflow on layouts that should never be overflowing in the common cases<br> <dael> fantasai: But that is sep issue<br> <dael> iank_: Yeah. Happy to discuss more<br> <dael> iank_: When I experimented with grid only happens when item itself fragments. mitegation is something like break inside a void<br> <dael> fantasai: People do entire page layouts in grid, though. A lot of grid layout where you don't want to break, but a bunch other with float that expects to break across multiple pages<br> <dael> Rossen_: How do we want to move forward?<br> <fantasai> s/float/flow content/<br> <dael> florian: Seems to me we have multiple similar but distinct situations here<br> <dael> florian: fantasai argument makes sense, but there is question of implcomplexity. Are there subcases in here where we can decide or do we need it all in one go?<br> <dael> iank_: Fragmentation has codependency on position. For block and table always know position before layout. When introduce alignment in grid and flex sometimes have this not typically<br> <dael> iank_: When you position it effects size, sometimes in large and unpredictable ways. Moving one px might be drastic b/c have a 100px monolyth in it. Without testing every px can't know size at a position<br> <dael> iank_: I'd be against saying test every position, but that's the impl complexity<br> <dael> fantasai: You don't have to do that to prevent overflow. You could say that if it frag such that it will overflow, you don't align but instead start-align so it fits.<br> <dael> fantasai: If you want lots of work but great you can frag bottom-aligned containers separately, but wouldn't recommend<br> <dael> iank_: Can't do if content has overflowing content inside<br> <dael> iank_: I think this is slightly separate from the issue<br> <dael> fantasai: Yeah. For case of column wrapping stuff I think it is rare enough that if it overflows and looks like a mess the user will be unhappy but it's rare. If we want to cause overflow I'm willing to accept for this one. not willing to accept for normal alignment and common things<br> <florian> +1<br> <dael> Rossen_: So, iank_ or alisonmaher what's your position? Continue thinking more?<br> <dael> iank_: For alignment should open separate issue. This is complicated stuff. We should discuss separately<br> <dael> Rossen_: If we open the alignment issue, what can we resolve for this issue?<br> <fantasai> s/common things/common things. It's more important to avoid overflow than to honor alignment/<br> <dael> iank_: I don't think we need to resolve on anything. Maybe wrong<br> <dael> Rossen_: fantasai anything to keep this issue open?<br> <dael> fantasai: Need to resolve that fragmentation algo for column-wrap flex containers can cause items to overflow even if would not have overflowed otherwise<br> <dael> Rossen_: I think that's an easy resolution to take<br> <dael> fantasai: Specifically to avoid re-wrapping the columns<br> <dael> fantasai: Not required to re-wrap the columns<br> <dael> fantasai: to avoid overflow<br> <dael> plinss: Can live with that. but I don't want spec lang to say you must overflow. if you can do better want to make sure you can<br> <fantasai> plinss++<br> <dael> Rossen_: Sure. Can resolve as may overflow<br> <dael> plinss: Generally reluctant to have attitiude that fragmentation is hard so let's do what's easy. Have been doing that for 25 years and frag has been broken. Rare is not justification to do wrong<br> <dael> Rossen_: Agree, but think you're overstretching. Everyone is trying to make frag as good as possible. Edge cases we'll do in performant way<br> <dael> plinss: Saying people can do simple because rare. Not happy with that<br> <dael> iank_: Yeah. We're focusing a lot of time to have a high quality baseline engine. Number of bug reports for fragmentation is very high so we see it's important use case<br> <dael> plinss: I accept that and accept that impl is hard and bugs need to be prioritize. Impl won't always get it right. Want to be careful not to spec bad behavior<br> <dael> Rossen_: Fair. I think prop resolution here for the described case it should be may overflow<br> <dael> florian: We've had other cases where spec may where noone felt they could do good thing at the time and then we could eventually remove it. Let's keep the door open<br> <dael> Rossen_: And I think great work happening across the board on fragmentation so hopeful we'll get there<br> <dael> fantasai: Prop: not required to re-wrap from column flexboxes in order to avoid overflow<br> <dael> Rossen_: Additional comments?<br> <dael> Rossen_: Objections?<br> <dael> RESOLVED: not required to re-wrap from column flexboxes in order to avoid overflow<br> <dael> Rossen_: Let's open new issue for alignment case<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/6855#issuecomment-1118027688 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 4 May 2022 23:36:47 UTC