- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Thu, 06 Jan 2022 00:19:30 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-flexbox] Flexbox alignment and fragmentation`, and agreed to the following: * `RESOLVED: We will spec that grid, flex, and table fragmentation align globally before fragments are created` * `RESOLVED: we will not truncate margins at any break when aligning globally for fragmentation` <details><summary>The full IRC log of that discussion</summary> <dael> Topic: [css-flexbox] Flexbox alignment and fragmentation<br> <dael> github: https://github.com/w3c/csswg-drafts/issues/6812<br> <dael> alisonmaher: This is about handling alignment when fragmeneting. Issue also applies to grid and tables<br> <dael> alisonmaher: According to spec it suggest align per fragment. Flexbox is only that makes this suggestion. Can confuse impl and may imply flexbox is unique.<br> <dael> alisonmaher: Would it make sesne to change to suggest align prior and can ignore<br> <dael> alisonmaher: Advantage of ahead of time is it layout more similar to non-fragment. Consiquence is how to handle margins. Spec says truncate at soft break and they can affect alignments so may not want to truncate<br> <dael> alisonmaher: FF does not truncate<br> <dael> alisonmaher: prop: update to match FF for margins during fragmentation and add similar language in grid and tables<br> <dael> iank_: broadly supportive<br> <dael> iank_: When fragmenting, doing it globaly somewhat makes most sense when you look. Otherwise you can get things in unexpected columns and not aligning at the end<br> <dael> astearns: I'm not entirely convinced of the preference for stitching back together in way that looks more like unfragmented, but not against the change<br> <florian> q+<br> <dael> astearns: If there is a use case for align per fragment is that a switch we can add, maybe like how we do box decoration breaks where an author can choose?<br> <dael> iank_: Potentially. I think for that case what we might do is treat everything as start aligned and do alignment then<br> <dael> iank_: one thing that should be said is this would match what impl do in reality. Blink at the moment b/c we're adding proper fragmentation and fixing bugs<br> <dael> iank_: Theoretically possible to haev a switch. Place where per fragment makes sense is content-alignment. But that's different<br> <dael> dholbert: Justify content?<br> <dael> iank_: No, talking about...what's the keyword...we don't have it, I think only FF does. Let me look it up<br> <dael> dholbert: first-basline and last-baseline?<br> <dael> iank_: Ignore my last comment. I'm confused.<br> <astearns> ack florian<br> <dael> florian: Usually when it comes to things that relate to fragmentation print formatters have spent more time on this. prince at least supports both fragmentation and flexbox. Might be worth looking at what they do. If it's not what we're proposing we should think about it more<br> <dael> iank_: This is slightly larger than flexbox since it applies to grid and table<br> <dael> florian: I don't remember if they do grid. Might<br> <dael> iank_: For grid doesn't make a lot of sense to do by fragment<br> <dael> florian: I don't have an objection, but given it applies to things important to print formatters it's worth looking at what they do. We can make a revision and put a to do to look and revisit if needed<br> <dael> astearns: Is there a good person to tag? I would go to Dave Cramer but I'm not sure how much time he has for CSS<br> <dael> florian: That was my answer as well<br> <GameMaker> present_<br> <dael> astearns: Maybe we can tag Dave and see if he can give us an idea of what Prince is doing. Somewhat convinced we should take the proposal since it's what FF is doing. If there is a difference we can think again<br> <dael> dholbert: FF supports the change. It feels like most coherent thing to do<br> <dael> iank_: That's what I came to as well. It falls out to make most sense<br> <dael> astearns: Prop 1: We will spec that grid, flex, and table fragmentation align globally before fragments are created<br> <dael> alisonmaher: Correct<br> <dael> astearns: Do we need anything about margins in that resolution?<br> <dael> alisonmaher: Sep<br> <dael> astearns: Concerns about that resolution?<br> <dael> astearns: Obj?<br> <dael> RESOLVED: We will spec that grid, flex, and table fragmentation align globally before fragments are created<br> <dael> alisonmaher: Margins want when handling alignment globally shouldn't truncate margins at soft breaks<br> <dael> astearns: Can we do that without causing any cycles in determining if a soft break<br> <dael> alisonmaher: I think FF already doesn't truncate margins in flexbox case so I think there's a prior for it<br> <dael> astearns: Okay. Interested in seeing test cases we can apply for this. Seems to me lots of weird edge cases for particular kinds of margins. I suspect not well tested<br> <dael> alisonmaher: Yeah<br> <dael> astearns: Anything more to discuss about margins?<br> <dael> dholbert: Additional point, when doing global alignment the thing aligned is the margin box which is why it makes sense to preserve the margins<br> <dael> astearns: when we are aligning globally we will not truncate margins at any break<br> <dael> alisonmaher: We could say it generally<br> <dael> astearns: Prop: we will not truncate margins at any break when aligning globally for fragmentation<br> <dael> RESOLVED: we will not truncate margins at any break when aligning globally for fragmentation<br> <dael> astearns: Blink is going through this and will be adding new fragmentation code. Test cases as you go?<br> <dael> alisonmaher: Yeah<br> <dael> astearns: alisonmaher would you ping Dave Cramer?<br> <dael> alisonmaher: Sure<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/6812#issuecomment-1006181635 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 6 January 2022 00:19:36 UTC