- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 02 Apr 2025 20:23:19 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-grid-3][masonry] Initial value of track listing for masonry grid axis`. <details><summary>The full IRC log of that discussion</summary> <kbabbitt> fantasai: we just talked a bunch about this<br> <kbabbitt> ... 2 options we have contemplated for masonry layout<br> <kbabbitt> ... a: be consistent with grid and leave as none which yields single track<br> <kbabbitt> ... b: do auto sizing auto fill thing that we were just talking about<br> <kbabbitt> ... jensimmons and I suggest current initial value<br> <kbabbitt> ... which we see use cases for auto fill auto behavior<br> <kbabbitt> ... we don't think it would make a good initial value<br> <miriam> q+<br> <kbabbitt> astearns: for my clarification, initial value of grid-tempalte-columns is none<br> <kbabbitt> ... whatever we decide masontry trigger to be, computed value for g-t-c could become this new value?<br> <jensimmons> q+<br> <kbabbitt> TabAtkins: there's back compat constraints we need to worry about but nothing we can't do<br> <astearns> ack miriam<br> <kbabbitt> miriam: currently the default in grid, initial value is none<br> <kbabbitt> ... which falls back to grid-auto-columns and areas<br> <kbabbitt> ... assuming those aren't set<br> <kbabbitt> ...we end up with similar issues<br> <kbabbitt> ... where default for g-a-c is auto<br> <kbabbitt> ... and we end up 1 column<br> <kbabbitt> ... not an ideal default<br> <kbabbitt> ...wish again we had some smarter auto in grid<br> <kbabbitt> ... probably too late to change that<br> <kbabbitt> ... but that makes me base my answer on how good this other option is<br> <kbabbitt> astearns: your answer is?<br> <kbabbitt> miriam: we've been talking about variants on this alternative<br> <kbabbitt> ... I need to know details of it to know if it can be better than what I consider current broken behavior of grid<br> <astearns> ack jensimmons<br> <kbabbitt> jensimmons: feel storngly that chanigng default for masonry use cases would be a mistake<br> <kbabbitt> ... not going to be an incredibly great default that will give people good looking stuff right away<br> <kbabbitt> ... will often be chaos already and people need to figure out why<br> <kbabbitt> ... also think people get started, write some code, switch to masonry, now code you wrote is doing something and you don't know hwy<br> <kbabbitt> ... eg. meaning of g-t-c changed<br> <kbabbitt> ... though that might be less strong an argument if default auto is great, it just isn't now<br> <astearns> q+<br> <kbabbitt> ... while what miriam is true that if you set auto your layout is half done, that'd be great<br> <kbabbitt> ... but reality is you have to write more<br> <miriam> (or at least not broken in the single column)<br> <TabAtkins> yeah definitely agree that Grid was right to not try and guess<br> <TabAtkins> as much as it kinda sucks in practice sometimes<br> <kbabbitt> ... with masonry it would be very confusing... one thing to say, you don't have a layout because you haven't made one<br> <kbabbitt> ... vs why do I have this layout that looks chaotic, now what do I do with it<br> <kbabbitt> ... I have to size all my items?<br> <kbabbitt> ... not a route people should have to go down<br> <kbabbitt> ... I think what fantasai said is true, better to leave people with no layout<br> <miriam> I wasn't asking for grid to guess at tracks, I just want an auto that doesn't blow things out<br> <kbabbitt> ... rather than make them get rid of bad layout they have to get to layout they want<br> <kbabbitt> ... if it's not hard to implement repeat auto I don't have a problem with it<br> <kbabbitt> ... meanwhile I don't know about making it the default<br> <astearns> ack astearns<br> <kbabbitt> astearns: one of the things jensimmons said made me think about ...<br> <fantasai> s/I don't know about/no on<br> <kbabbitt> ... I've set up a 3 column grid<br> <kbabbitt> ... and it looks sort of what I want but what I really want is masonry<br> <kbabbitt> ... if the auto is the default, does it override my 3 columns?<br> <kbabbitt> fantasai: no<br> <kbabbitt> astearns: ok then never mind<br> <kbabbitt> jensimmons: the only way people would get this auto default is if they enter right formatting context and *do not* create columns or rows, and trigger masonry and then go to tackle columns<br> <kbabbitt> ... which some people will do, but I think authors will do what astearns said, start by defning columns, then trigger masonry, then continue<br> <kbabbitt> astearns: I think there might be some value in having as little change as possible on that grid to masonry switch<br> <TabAtkins> note: that depends on the not-yet-decided "masonry switch". if it's `display:masonry`, then it's trivial to get this situation<br> <kbabbitt> .. switch to masonry thing might change, but if you set columns ... being able to switch back and forth without having it do something for you would be more intuitive<br> <TabAtkins> (i also continue to push back on the idea that Grid is a meaningful/useful *fallback* for Masonry.)<br> <TabAtkins> (it requires a somewaht careful hand to make that work well, actually)<br> <kbabbitt> iank_: push back a little on that specific point, the switch between grid and masonryu in my mind is big<br> <kbabbitt> ... changing how things pack, size, etc<br> <kbabbitt> ... so still a big switch between modes<br> <TabAtkins> (so it *can* be used, in an @supports kinda way, but it's not really suitable as a general "automatic" fallback)<br> <kbabbitt> ... so this is still a sueful default for a lot of people<br> <kbabbitt> ... degenerate case you still get columns<br> <kbabbitt> ... we can work on how useful this will be for web developers<br> <kbabbitt> fantasai: 2 things we can do here are<br> <kbabbitt> ... straw poll or leave it until we close other issue<br> <kbabbitt> astearns: c) leave until we decide on other issue and masonry switch<br> <kbabbitt> TabAtkins: leave for now is fine<br> <miriam> +1<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10869#issuecomment-2773641820 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 2 April 2025 20:23:20 UTC