- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Fri, 31 Jan 2025 19:16:47 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-flexbox][css-grid] Unifying grid-auto-flow and flex-flow`, and agreed to the following: * `RESOLVED: Continue to work on the item-* props as a set of switches for all items-in-container layout modes` * `RESOLVED: Put it in grid-3 for now, with intention to move` <details><summary>The full IRC log of that discussion</summary> <bramus> fantasai: one of the key feeedback points from tag was to see better unificiation between grid and flexbox and grid auto flow and flex flow<br> <bramus> … also grid auto flow aspect of the grid integrated proposal was pointed out by google to be awkard<br> <bramus> … want to unify in a reasonable way<br> <bramus> … some ideas in the issues<br> <bramus> … tab had some variations on that<br> <bramus> … jen created a presentation to walk us through all of it<br> <bramus> florian: are you presenting a synthesis or a propsal?<br> <bramus> jensimons: both<br> <bramus> … one of the areas that is difffern betwwn both proposal is grid auto flow vs masonry direction and such<br> <bramus> … tag reviewed that<br> <bramus> … need more general properties<br> <bramus> … flexbox: have direction, wrap and flow<br> <ntim> jensimmons: let's go down this rabbit role<br> <bramus> … grid; no directoin or wrap, but auto flow<br> <bramus> … unified: maybe some item-* props?<br> <bramus> … item-direction, item-wrap, item-pack, item-slack, item-flow, …<br> <bramus> … leading to new ideas for grid and flex<br> <bramus> … intersting things<br> <bramus> … new homes for long standing feature requests<br> <bramus> … things click together suddenly<br> <bramus> … grid could gain nowrap<br> <bramus> … to not define expcliit tracks and have all implicit tracks and have grid autocreate rows or cols<br> <bramus> … flexbox gains dense packing<br> <bramus> … it can backfill if items fit on a previous line that was already filled<br> <bramus> … flexbox could get balance<br> <bramus> … thanks to item-pack<br> <bramus> … we could have something to balance the rows out a bit more<br> <bramus> … few ideas<br> <astearns> q?<br> <bramus> … and there is item-pack: collapse<br> <bramus> … (names TBD BTW)<br> <bramus> … and item-flow as a shorthand<br> <bramus> … with collapse we get into masonry<br> <bramus> … had the "just use grid" idea<br> <bramus> … or a new display value – masonry<br> <bramus> … with item-pack we can unify that: item-pack: row collapse<br> <lea> q?<br> <lea> q+<br> <bramus> … high level questions<br> <TabAtkins> q+<br> <bramus> … 1. do we want to pursue item flow and longhands, unifying grid-auto-flow?<br> <bramus> … 2. do we want to use item-pack as the trigger for masonry style?<br> <bramus> 3. (bikeshedding)<br> <bramus> … 4. decide what row and column mean for item-direction<br> <bramus> … does it mean flow of items or shape of layout?<br> <bramus> … ** shows example with named area columsns **<br> <bramus> … in grid it flows back in rows with grid-auto=flow: row;<br> <bramus> … with just use grid consistency is contained, but masonry-flow; coljunn describes the columns<br> <bramus> … (example with named area rows)<br> <bramus> … in the unified world … been discussing in context of masonry alone, but should be consistent for grid and flexbox too<br> <bramus> … flex-flow: row wrap vs item-flow: row wrap;<br> <bramus> … with grid its a bit different<br> <bramus> … grid-auto-flow: row wrap;<br> <bramus> … item-flow: row wrap; is a bit different<br> <bramus> … (missed)<br> <lea> `flow-direction` perhaps?<br> <bramus> … adding one more paper cut adding to the syntax<br> <bramus> … shape of the layout would be the<br> <bramus> … in masonry style layout it becomes clearer<br> <bramus> … is it item-flow: row collapse wrap;<br> <bramus> … but I know there are people who dont like that<br> <bramus> … so yeah, we have 4 questions<br> <bramus> … question about shape vs flow is ??? might help to write out examples<br> <iank_> q+<br> <oriol> q+<br> <astearns> ack lea<br> <bramus> lea: was one of th epeople on tag. this is great.<br> <bramus> … really like this<br> <bramus> … obvs things to bikeshed, but right direction<br> <bramus> … getting towards a simpler thing eventually<br> <bramus> … and seems more powerful than what was previously proposed<br> <ntim> q+<br> <bramus> … like how it leaves the template open – both rows and cols<br> <bramus> … can still have masonry layou tand efine a specific row height and that still has an effect<br> <bramus> … quite like that as well<br> <bramus> … did suggest flow-direction instead of item-flow<br> <bramus> … a bit weir dbut no strong opinion<br> <bramus> … details can always be fleshed out<br> <astearns> ack TabAtkins<br> <bramus> … this is fantastic<br> <bramus> TabAtkins: overall pretty happy with to move this functionality to item-* props<br> <bramus> … am very happy with it<br> <bramus> … one bit of objection which is item-pack property (after talking with ian)<br> <bramus> … conflict between new behaviors needing to be defined for all things<br> <bramus> … comes up here too<br> <astearns> qq+<br> <bramus> … side bits of behavior needed<br> <bramus> … item pack is more of a grab back of functinality<br> <bramus> … triggers betwen normal and dens in grid<br> <bramus> … swtich between grid and masonry<br> <ntim> s/grab back/grabbag<br> <bramus> ¬… and possibly turn flex in a ???<br> <bramus> … new piece of fn that needs to predefine things for deverything<br> <bramus> … inclined to not do item-pack<br> <bramus> … but accept all the rest<br> <florian> q+<br> <bramus> astearns: i like the discipline of needing to consider all layouts that a new thing might need to adapt to<br> <astearns> ack astearns<br> <Zakim> astearns, you wanted to react to TabAtkins<br> <bramus> … would still need to have an escape hatch where we could define values like flex-balance for item-pack that only work on flex until we figure out how to make balance work with the rest<br> <bramus> TabAtkins: definitily possible<br> <bramus> iank_: what tab said<br> <bramus> … item pack is problematic for reasons that tab outlined<br> <fantasai> +1 astearns<br> <bramus> … historically done a poor job as implementers<br> <bramus> … impltd these in block step (>)<br> <bramus> … this hurts devs bc they cant feature detect<br> <bramus> … stuff in alignment that was hard to ship<br> <astearns> s/would still need to have/would still have/<br> <bramus> … and things like align-content: baseline<br> <bramus> … historically done a bad job at these sort of complex things<br> <bramus> … would be a bit happy with this (i am working on balance in flex). for grid its very complex<br> <bramus> … dont want to see that we cant ship balancing for flexbox bc we have to figure out what it does for grid<br> <bramus> … layout specific keywords<br> <astearns> ack iank_<br> <bramus> … implementation cost would be huge otherwise<br> <astearns> ack oriol<br> <bramus> oriol: concern this seems to add fn that may add duplication or sth that may not really make sense in some layouts<br> <bramus> … in grid you can assign expl positions for the items and nowrap does not make sense in that case<br> <jensimmons_phone> q?<br> <bramus> … idea about nowrap adding new cols<br> <bramus> … with grid auto flow col you get that<br> <jensimmons_phone> q+<br> <bramus> … is duplication<br> <bramus> … will create more confusion<br> <bramus> … for authors<br> <bramus> … thing of item-pack to refer to the direction or shape of layout<br> <iank_> q+<br> <bramus> … not using shape of layout would be confusing<br> <bramus> … in grid auto flow that would a conflict was presented<br> <bramus> … though inc ase of non masonry grid you get both rows and cols<br> <bramus> … it does not apply well<br> <bramus> … some of these may make sense, but would prefer to add them explcity for each layout<br> <bramus> … not fond of defining everything in gereral because of duplication or conflicts<br> <astearns> ack ntim<br> <bramus> ntim: comment on item-flow<br> <bramus> … flow representes how things are ordered, not shape<br> <bramus> … so using shape would be confusing<br> <astearns> ack fantasai<br> <Zakim> fantasai, you wanted to comment on flow-direction, maybe<br> <bramus> fantasai: agree 100% with what alan said<br> <bramus> … i thinkk that idea of prefixing as we introduce new fn is an nice compromise to getting full allignment across layouts<br> <bramus> … idea iof flow-direction<br> <bramus> … (missed)<br> <bramus> … use flow in 2 places now<br> <bramus> … 1 is in various flow-???. its a suffix<br> <bramus> … 2 is why this could not be a shorthand<br> <bramus> …æ still have display: flow<br> <bramus> … these props dont apply to that type of layout<br> <bramus> … have 2 types of layout in CSS: flow layout <details missed> and a different kind of layout where you go down from parent to childrena and child is a chunk and gets manipulated as an item<br> <bramus> … flex and grid are in one type of those<br> <astearns> flow layout versus item layout<br> <bramus> … dont want to get too deep into wraping this set of props with the flow word<br> <bramus> … other that we use it as a shorthand to ???<br> <bramus> ; thought about prefixed<br> <bramus> … item was 1<br> <astearns> (or item-in-a-container layout)<br> <bramus> … thought about placement too<br> <bramus> … went with item bc we use item in align-items<br> <bramus> ; already have the concept of items<br> <bramus> … and syntax for it<br> <bramus> … open to naming of course<br> <astearns> ack florian<br> <bramus> florian: i like this<br> <bramus> … and generally agree with alans comment<br> <bramus> … re: ian<br> <bramus> … not everyting is the same<br> <bramus> … a bunhc o fthings need to work across layout modes<br> <bramus> … like margin and gap and rows and align and ;<br> <bramus> … if we dont do that its bad<br> <bramus> … not sure its all of it though<br> <bramus> … possibly around item-pack<br> <bramus> … squeeze mode of flex<br> <bramus> ; 2 proposals for what dense might mean for flex<br> <bramus> … looks like grid, but there are some flexbox-specific traits to it<br> <bramus> … when some of them are not diff appls of the same thing but related but diff concepts, then we get into the “you have to define all across all 3 modes”<br> <astearns> ack fantasai<br> <Zakim> fantasai, you wanted to react to florian<br> <bramus> … theres at least a part tha tmakes sense across all layou tmodes but not all<br> <bramus> fantasai: there was a proposal for dens epacking in flexbox (unrelated to this proposal)<br> <bramus> … idea was to instead of fill line and wrap when it overflows, cram in last items and shrink it<br> <bramus> … first edition of that tagged that behavior to the dense keyword<br> <bramus> florian: that is the dens keyword?<br> <bramus> fantasai: no<br> <bramus> … the thing on the slide is different<br> <bramus> TabAtkins: oh, the slide is not up to date I see<br> <bramus> fantasai: so, dense packing for flex should be same concept as grid to fill in the gaps<br> <bramus> … slack is cram things in<br> <astearns> q+<br> <bramus> … for masonry its which col is the shortest<br> <astearns> ack fantasai<br> <Zakim> fantasai, you wanted to clarify this<br> <dholbert> +1 to florian's concern, particularly for cases where the relative utility and/or implementation-complexity of the the same keyword is substantially different between different layout modes (which risks implementors shipping the feature for one layout mode but not others, as Ian noted)<br> <bramus> …for flex its close enough to fitting and ifts close to 10px cram it in<br> <bramus> … fudge distance<br> <bramus> … say how much you want to cram in<br> <bramus> florian: and in grid?<br> <bramus> TabAtkins: nothing, not possible there<br> <bramus> fantasai: the only keywords tied to 1 layout in this set are collapse for grid and balance only for flexbox<br> <bramus> florian: makes sense<br> <bramus> … lets try not to overfit this<br> <bramus> … would be a mistake<br> <bramus> … forcing that would be bad<br> <bramus> TabAtkins: strong agree<br> <bramus> … that is why i am happy with the current form<br> <astearns> ack jeroen<br> <astearns> ack jensimmons_phone<br> <bramus> jensimmons: an early reaction was to not do pack<br> <bramus> … and folks were sort of bummed out about doing balance<br> <bramus> … think that creating balance – doing balance keyword at all … can be a later version<br> <bramus> … exciting to present the propposed thing where it paints the future<br> <bramus> … dense already have for grid, can figure out what it does for flex<br> <bramus> … dont have to ship right away<br> <bramus> … ipml detail<br> <florian> s/lets try not to overfit this/lets try not to overfit this, by forcing the creation of different-but-analogus options in other layout modes just because we now have a keyword that could trigger them<br> <bramus> … collapse though is the toggle for masonry<br> <fantasai> s/detail; let's think about what's good for the Web/<br> <bramus> … skipping all of item pack<br> <bramus> TabAtkins: there’d be a diff switch<br> <florian> s/would be a mistake/would be a mistake, because it would force synchronous shipping of essentially unrelated (even if similar) functionality<br> <bramus> jensimmons: exciting things to add pack and slack here<br> <bramus> … (missed)<br> <astearns> ack iank_<br> <bramus> iank_: one thing, handling balance<br> <ntim> jensimmons: what's exciting is the unified way to control the flow for authors<br> <bramus> … imminently would be good<br> <bramus> … in the next month or so i’ll prolly do some research<br> <bramus> … would like to solve soon<br> <TabAtkins> concretely, instead of item-pack, we could keep the existing `grid-auto-flow`, add `flex-pack: normal | dense`, add balance to `flex-pack`, and trigger masonry layout via `display: masonry` or another new property.<br> <bramus> jensimmons: it is cool<br> <bramus> iank_: yep!<br> <astearns> ack astearns<br> <bramus> astearns: response to florian but i think jen covered it already<br> <bramus> … this new stuff is not the new item in containers property set to rule them all<br> <fantasai> I think having the unified properties is cooler than introducing more one-offs<br> <bramus> … this is a support mechanism that we use when appropriate to put them together where it makes sense<br> <bramus> … still lmost likely to have values with layout prefixes<br> <bramus> … spefific to those modes<br> <bramus> … that dont make sense into this other thing<br> <fantasai> s/values/values and properties/<br> <bramus> … but q is how do the existing or future layout props with these new item things?<br> <bramus> fantasai: this propopsal is meant to be replacing the existing grid-auto-flow and flex-flow props<br> <bramus> … is it an alias or how does it interact? thinking about making it a shorthand<br> <bramus> … 3 diff directions<br> <bramus> … alias, keyword magic, or shorthand<br> <bramus> … its not gonna rule all of layout controls, its this set of stuff to represent common concepts for all layout modes<br> <bramus> … gives them a unified home to live in<br> <bramus> … like flex property is not gonna be ported to grid or stuff<br> <bramus> jensimmons: think of things like alignment<br> <bramus> … does 1 thing<br> <bramus> … do they wrap or pack<br> <bramus> … its not about the layout at all, its about the item behavior<br> <astearns> s/likely to have values/likely to have values and properties/<br> <bramus> … when brendan and I came up with this, these props could alias other props<br> <TabAtkins> q+<br> <bramus> … but proplem with that we could end up with strange behavior where a strey prop starts to have effect<br> <bramus> … would expect that the flex props dont escape that<br> <bramus> … (missed)<br> <bramus> … authors can still grab to the flex and grid props<br> <astearns> +1 to not aliasing, that seems too constraining (and dangerous)<br> <bramus> … if we wnated in the future to define balance only for flex, then we can stick to that<br> <astearns> ack TabAtkins<br> <bramus> TabAtkins: this set of fn (with or without item pack) is sufficiently generic or useful dfns that they will be usable for prolly all future layout modes<br> <bramus> … knowing where it flows is always gonna be present<br> <bramus> … this is a good design set of pieces that will work for future layout modes<br> <bramus> … there should be direct analoging behavior between everything<br> <bramus> iank_: item-pack is arguably the one that violates that the most<br> <bramus> … bheaviors are diff between the modes<br> <bramus> … thats the one<br> <bramus> fantasai: dont think this is the case<br> <bramus> … normal is normal<br> <bramus> … dense is analogus between flex and grid<br> <bramus> TabAtkins: but not masonry<br> <bramus> fantasai: but it also has dense<br> <TabAtkins> nm, masonry does have dense<br> <bramus> … collapse gonna set out next separtely<br> <dholbert> q+<br> <bramus> … leftover one is balance. masonry is inhernetly that<br> <bramus> … only 1 keyword<br> <bramus> iank_: there is also nowrap<br> <bramus> fantasai: there is a dfn for nowrap that makes sens for grid<br> <bramus> … (grid)<br> <TabAtkins> The set of property names/values from mine and fantasai's compromise, btw, are:<br> <TabAtkins> item-track: auto | row | column | row-reverse | column-reverse<br> <TabAtkins> item-cross: [ [ nowrap | wrap ] || [ normal | reverse ] ] | wrap-reverse<br> <TabAtkins> /* wrap-reverse is a combination of wrap and reverse, for convenience */<br> <TabAtkins> item-pack: normal | dense || [ collapse | balance ]<br> <TabAtkins> item-slack: normal | <length-percentage> | infinite<br> <TabAtkins> item-flow: <'item-track'> || <'item-cross'> || <'item-pack'> || <'item-slack'><br> <bramus> … this lets you set it at a higher level on the container<br> <bramus> … and that gets you similar to a nonwrapped flex box where you cerate tracks and apply certain track sizing mutations on it<br> <bramus> … and its a very obvs straigth way to get that<br> <bramus> … in grid you use grid-row: 1<br> <bramus> … but now you can add it at a higher level<br> <bramus> … not critical to add now, but i think it makes sens<br> <astearns> ack dholbert<br> <bramus> … not higghly reqd feature but straightforward to describe and implement<br> <bramus> dholbert: share ian’s concerns<br> <bramus> … in particular feels dense is well defined for grid but not sure i like the behavior for flex<br> <bramus> … seems like that behavior would be unpredicatable as space grows or shrinks<br> <bramus> … with rows and small items snapping down to a later row<br> <bramus> … you would get sth that looks like masonry with a lot of tiny items attached to the end of each line<br> <iank_> i also wonder a subset of requests for `flex-wrap: dense` was people really wanting `flex-wrap: balance`<br> <bramus> … would do the job to fill a line densely, bu tskeptiacal if that is what authors want<br> <bramus> … feels like dense is agrid thing that gets backfilled into flexbox<br> <bramus> … on the flip side it seems like balance might needed to be backfilled to grid<br> <bramus> … worried about being forced to implement both in order to ship 1<br> <TabAtkins> note: we can defer the item-pack property for discussion in another issue or later meeting. it would just remove one possible "masonry" switch<br> <bramus> astearns: see tab’s note in irc: can defer dense<br> <bramus> TabAtkins: if we end up to not put dense into item-pack and only had collapse then it would not be a good name for it<br> <bramus> … but does not prevent us from doing a diff switch from now and later have item pack take on those duties<br> <bramus> astearns: aside from some details, i hear general enthusiasm?<br> <bramus> … shall we resolve to continue to work on this general item-* prefix proposal?<br> <bramus> … seeing thumbs up<br> <bramus> … concerns?<br> <bramus> TabAtkins: and ideally resolve in upcoming telecons soon<br> <TabAtkins> items-in-container layout modes<br> <bramus> astearns: not hearing stuff, prop resolution is to continue to work on the item-* props as a set of switches for all items-in-container layout modes<br> <florian> +1<br> <kbabbitt> 👍<br> <bramus> RESOLVED: Continue to work on the item-* props as a set of switches for all items-in-container layout modes<br> <bramus> fantasai: curerntly to be shoved in the grid-3 spec<br> <bramus> jensimmons: could end up using its own<br> <bramus> florian: can move eventually<br> <ntim> ntim: could use css-display<br> <bramus> PROPOSED RESOLUTION: Put it in grid-3 for now, with intention to move<br> <bramus> RESOLVED: Put it in grid-3 for now, with intention to move<br> <ntim> <3<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/11480#issuecomment-2628118101 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Friday, 31 January 2025 19:16:48 UTC