- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Fri, 31 Jan 2025 18:02:36 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-grid-3][masonry] Masonry Syntax Debate`, and agreed to the following: * `RESOLVED: Re-use grid templating and placement properties for masonry layout` <details><summary>The full IRC log of that discussion</summary> <bramus> fantasai: the 1st topic is should masonry use its own template props or should we reuse existing grid-template props?<br> <bramus> … (for placement)<br> <bramus> … we have gone of this before a bunch of times<br> <bramus> … the q is separate from the rest we believe<br> <bramus> … the q is to go for grid-template props or masonry-template props for defining tracks and for placement<br> <bramus> jensimmons: so there is lots of complexity<br> <bramus> … idea with just use grid is to stick to grid-template-* props<br> <bramus> … ide with masonry is to use separte tsyntax<br> <bramus> … since last meeting tab proposed to maybe the new masornry layout position we woul dneed to duliate a bunch of props<br> <bramus> … not a final decision but it is an idea that could get isolated from the rest<br> <bramus> … do we want to put to bed the masonry-template-* props and masonry-autuo-tracks and use the grid props where we can in order to not have duplication?<br> <bramus> fantasai: we are not talking about grid-=auto-flow or masonry-…flow – is only about grid tpl properties<br> <bramus> … versus their masonry equivalent<br> <bramus> … and then grid-row vs ?? for placement<br> <TabAtkins> Just the "template" and "placement" properties.<br> <kbabbitt> s/vs ??/vs masonry-track/<br> <lea> Could someone summarize what the actual proposal is?<br> <bramus> jensimmons: do we want to resolve that no matter what we end up doing to not create 19 new props that are very similar<br> <alisonmaher> q+<br> <bramus> … and try to use grid props as much as possible<br> <fantasai> s/and then/grid-template-* and grid-auto-* for track definition/<br> <bramus> astearns: so basic idea is masonry has some things that are identical to grid (or very close).<br> <TabAtkins> q+<br> <bramus> … grid tpl things, and so … just use grid props for that<br> <bramus> florian: separately from the rest<br> <astearns> ack alisonmaher<br> <bramus> alisonmaher: why for pos items having separate pros is useful for ergonomics<br> <bramus> ; if we use it for grid- props, authors could sset the wrong one int he wrong direction<br> <bramus> … would still parse but not give them the wanted result<br> <bramus> … separate tracks poisition would only apply in the direrctiont the author intended<br> <astearns> ack TabAtkins<br> <bramus> TabAtkins: this is not “hey, we are going to replace this with grid”. q is “whcih one should we go with“<br> <bramus> … reasons for either one<br> <bramus> … reusing grid props has benefit that confcepts are shared<br> <bramus> … layout algo talks in grid in many ways<br> <bramus> … few things to still deal with<br> <bramus> … initial value is a wrinkle<br> <bramus> … and auto filled tracks with intrinsic size<br> <bramus> … but its theoretically doable<br> <bramus> … potential to declare both rows and cols for grid<br> <bramus> … need to ignore one of the sets<br> <astearns> q+<br> <bramus> … masonry set of things mean that while these are a close duplicate in grammar, they are a single well designed thing that fits masonry perfectly\<br> <bramus> … some duplicate but better fit<br> <bramus> ; ntohnig needs tobe ignore in dweird cases<br> <bramus> … grid-tpl-areas is the one i am most uncomfortable with<br> <bramus> … dont like using<br> <bramus> … designed to do ascii art in grid<br> <bramus> … clever design<br> <bramus> … works perfectly there (in grid)<br> <bramus> … in masonry you dont have 2d grid<br> <bramus> … 1 set of tracks in 1 direction<br> <bramus> … ???<br> <bramus> … masonry cols is 1 string which ontains all cojum anmes<br> <bramus> … if you have rows you ahve mutliple strings with 1 row name in each string<br> <TabAtkins> "foo bar baz" vs "foo" "bar" "baz"<br> <bramus> … bc how oyou declare a sginel rolw multi col grid<br> <bramus> … that sort of grid is rare<br> <bramus> … ppl dont generally do that<br> <bramus> … if they do, the may or may not name their areas<br> <ntim> grid-template-areas: "r1c1 r1c2" "r2c1 r2c2"<br> <bramus> ; asklward that when depending on masorny direction you need a different syntax<br> <bramus> … could live iwth it, bu tnot great<br> <bramus> … leaning towards masonry props, but ok with either way.<br> <bramus> astearns: 1 more distinction<br> <bramus> … reusing grid props gives us that nice fallback fn thats been talked about in the grid proposal<br> <bramus> … that you dont have to redeclare a bunch of things<br> <TabAtkins> q+<br> <bramus> … and if we find that there is some problem with dev ergonomics in using the grid props for masonry<br> <bramus> … we coud prop by prop add a masonr equivalent when justfied by author usage<br> <astearns> ack astearns<br> <astearns> ack TabAtkins<br> <bramus> TabAtkins: it was imlplicit when i talked abou tsome masonry values that dont work well in grid<br> <bramus> … that means if we reuse same set of grid-tpl props, we need to define what that means for grid<br> <bramus> … can make it valid<br> <bramus> … ??<br> <bramus> … will continue to be a potential issue that any new prop needs to be defined for both at the same time<br> <fantasai> s/??/can define it as some fallback e.g. repeat resolves to 1/<br> <bramus> … if they are separte that does not need to happen<br> <bramus> … reuse on 1 side and independent definition on the other are two discussion topics<br> <florian> q+<br> <astearns> ack florian<br> <bramus> florian: for the wrinkle you talked about mastony tpl area<br> <bramus> … possibly we could add an optional keyword int he grid syntax that if you only have 1d it applies tot he primary direction<br> <bramus> … and in grid/masrony they have different meanings<br> <bramus> ; if you only use 1d, it uses the syntax<br> <bramus> … no need to deep dive, but its an option that might ease things<br> <astearns> ack fantasai<br> <bramus> TabAtkins: sounds fair<br> <bramus> fantasai: about authors to now knowing when to use grid-tpl-rows or cols<br> <bramus> ; dont think that will happen<br> <bramus> … if they get confused its about a prop that switches axies<br> <bramus> TabAtkins: agree that its a bit confusing there<br> <bramus> fantasai: about tpl syntax: arugment that tab is making is that its confusing that the syntax is differne between two differnt axis<br> <bramus> … but if we made it the same<br> <bramus> ; for both axis in masonry then in the masonry layout for in the row axis the tpl syntax would be diff from a grid layout<br> <bramus> … would be introducing that as an inconsistency<br> <bramus> … tpl syntax was designed for ascii art<br> <bramus> … still works for masonry<br> <bramus> … if you create cols you write your foo bar baz in a single string and then write track sizes<br> <bramus> … if you creata bunch of rows you put the names in a stack<br> <bramus> … as separate strings<br> <bramus> … and next to the name of the area you put the size<br> <bramus> … that lets ytou diagram your layout<br> <bramus> … was designed for that<br> <bramus> … its a feature of the tpl syntax carrying through into masonry<br> <TabAtkins> (we're pushing the `grid-template` shorthand to later, I have a much stronger objection to `grid-template`)<br> <bramus> … in the example you see two layouts. one is masonry and other is creating a strecthed alignmetn because its a grid<br> <bramus> … the grid tpl syntax supports both<br> <bramus> … much easier<br> <bramus> TabAtkins: tihe grid template shorthand and the grid shorthand is discussed later<br> <bramus> … much strong objection to the shorthand, dont want to discuss now<br> <bramus> fantasai: (missed)<br> <bramus> TabAtkins: no, the longhands<br> <bramus> … pseically the area one<br> <bramus> fantasai: when we look at diffs between grid tpl props and masrony tpl props there is very little difference<br> <bramus> … no need to introduce a lot of new props<br> <bramus> … bc authors could reuse the existing ones<br> <bramus> jensimmons: issue here is intended to shoot any of the other debats into silence<br> <bramus> … its a higher level question<br> <bramus> … can we make some progress around this 1 idea<br> <bramus> astearns: and the current high level idea is can we resolve on using grid-* props for masorny layout in general where it makes sense with case by case basis about when we actually need a new prop<br> <fantasai> grid-template-*/grid-auto-*/grid-row/grid-column vs masonry-template-*/masonry-auto*/masonry-track<br> <fantasai> Currently *only* about templating and placement properties<br> <bramus> … before we go to straw poll, anyone has concerns to this general principle of reusing grid props where appropriate?<br> <bramus> iank_: find it still more funky than masonry props<br> <bramus> TabAtkins: I think I outlined those objections before<br> <bramus> astearns: straw poll<br> <ntim> astearns: re-use the grid-template-areas properties or something else<br> <bramus> … 1. Reuse the grid template emplacement properties for masonry layout<br> <bramus> fantasai: this is about the longhands<br> <kbabbitt> s/emplacement/and placement/<br> <bramus> … 2. Have separate masonry versions for all of these<br> <fantasai> POLL: 1) Re-use grid template and placement properties for masonry layout VS 2. introduce dedicated templating and placement properties for masonry layout<br> <jensimmons> s/issue here is intended to shoot any of the other debats into silence/the issue is NOT to silence any further debates about details, but to<br> <florian> 1<br> <ntim> 1<br> <iank_> 2<br> <miriam> 1<br> <jfkthame> 1<br> <kizu> 1<br> <TabAtkins> 2<br> <alisonmaher> 2<br> <kschmi> 2<br> <schenney> 1<br> <fantasai> 1<br> <smfr> 1<br> <astearns> 1<br> <bts> 1<br> <emilio> 1<br> <jensimmons> 1<br> <lea> 1<br> <hober> 1<br> <oriol> 2<br> <rachelandrew> 2<br> <bkardell_> 1<br> <ethanjv> 2<br> <romain> 2<br> <dholbert> 1 but weak dependency on later decision about display value<br> <ChrisL> 1<br> <bramus> 2<br> <emilio> (+1 dholbert)<br> <emeyer> abstain<br> <ethanjv> (+1 dholbert)<br> <bramus> astearns: seeing slight but not overwheleming preference for 1<br> <bramus> emilio: e.g. i voted for 1 but could live with 2<br> <jfkthame> looks like 17 vs 9, or nearly 2:1<br> <ydaniv> abstain<br> <bramus> TabAtkins: this seems like a weak resolution for 1 and if people’s opinions shift we can adjust<br> <nicole> abstain<br> <bramus> astearns: proposal to take resolution for option 1 for now<br> <bramus> … objections?<br> <ntim> i don't think 2:1 ratio is a weak preference :)<br> <lea> 🎉<br> <fantasai> RESOLVED: Re-use grid templating and placement properties for masonry layout<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/11243#issuecomment-2627998471 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 18:02:37 UTC