- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 24 Apr 2024 16:36:29 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `Alternate masonry path forward`. <details><summary>The full IRC log of that discussion</summary> <schenney> fantasai: topics: can masonry replace grid, track info, interaction of masonry-grid. For authors? For spec?<br> <fantasai> scribe+<br> <fantasai> scribe+ schenney<br> <fantasai> -> https://github.com/w3c/csswg-drafts/issues/9041#issuecomment-2071086963<br> <schenney> fantasai: Q? Use case for variable track sizes. It not neceaary, all sorts of objections due to complexity. Jen SImmons has demos to present and talk through.<br> <fantasai> -><br> <TabAtkins> q+ for after the demos<br> <fantasai> jensimmons: We're hoping to make real progress on this question, it's been 4 years since this question first came up<br> <bts> Link to demo: https://webkit.org/demos/grid3/photos/<br> <fantasai> jensimmons: the demos are online<br> <fantasai> -> https://webkit.org/demos/grid3/photos/<br> <fantasai> jensimmons: Photos demo is a good start. If we show numbers you can see multicol layout, where the images go down the first column, then second, etc.<br> <fantasai> jensimmons: for this content it's ok, other content it's not great; but also it doesn't allow loading additional content to the bottom<br> <fantasai> jensimmons: if you use grid L1, it lines up in both row and column. If aspect ratio isn't uniform, doesn't look great<br> <fantasai> jensimmons: masonry gives a chance to lay things out going across the top of the columns, and then keep going across filling the shortest colun<br> <fantasai> jensimmons: it builds into grid easily, can specify any set of columns you want and then set rows to 'masonry'<br> <fantasai> jensimmons: basically turns the rows off<br> <fantasai> jensimmons: There are other things you can do with grid, because full power of grid-template-columns<br> <fantasai> jensimmons: in this demo, first and last cols are fixed sizes, and the iddle columns 1fr, and number of columns scales with width of window<br> <fantasai> jensimmons: next demo, all columns are flexible but we have narrow and wide columns<br> <fantasai> jensimmons: and always starts and ends with a narrow column<br> <fantasai> jensimmons: the basic masonry layout is popular because JS can only do so much, but building into CSS can do a lot more<br> <fantasai> jensimmons: spanning in grid allows some interesting possibilities, e.g. every 5th item is wider here. Gives more graphic design interest.<br> <fantasai> jensimmons: in this version made the landscape photos wider<br> <fantasai> jensimmons: [shows horizontal masonry demo]<br> <fantasai> jensimmons: Mega menus are another use case<br> <fantasai> jensimmons: multicol would go down the columns, but masonry allows to lay out the first items across<br> <fantasai> jensimmons: Text becomes more interesting also.<br> <fantasai> jensimmons: a lot of websites lay out teaser content by fitting the content to the regular boxes<br> <fantasai> jensimmons: often by trucating it<br> <fantasai> jensimmons: keep everything the same aspect ratio, creates a very modernist grid<br> <fantasai> jensimmons: this is why graphic design can feel boring on the web<br> <fantasai> jensimmons: classic masonry allows more flow of content, but still somewhat rigid<br> <fantasai> jensimmons: start applying different widths and spans, create very interesting layouts<br> <fantasai> -> https://webkit.org/demos/grid3/photos/<br> <fantasai> jensimmons: this last demo is classic masonry, but grid allows some extra possibilities<br> <fantasai> jensimmons: the header/sidebar can be shifted to the other side using explicit placement<br> <fantasai> jensimmons: or use subgrid to align metadata across cards<br> <lea> +1 for letting Jen finish. This is important, we can spend 5 more minutes on it. Also, talking about timeboxing came close to taking more time than the actual presentation.<br> <fantasai> jensimmons: subgrid is powerful here<br> <fantasai> jensimmons: questions?<br> <fantasai> jensimmons: As I wrote in the article, this is about saying "hey, we've got grid -- but what if we let go of the idea that it's only modular grids?"<br> <fantasai> jensimmons: columnar grids are grid systems, historically in graphic design<br> <fantasai> jensimmons: this just lets us turn off rows (or turn off columns)<br> <florian_irc> q+<br> <fantasai> jensimmons: and contents pack together<br> <astearns> ack emilio<br> <Rossen__> q?<br> <fantasai> ?: is this display: block grid?<br> <Rossen__> q?<br> <fantasai> jensimmons: no inlines, this is just 'display: grid'<br> <fantasai> s/?/Keith/<br> <lea> q+<br> <fantasai> TabAtkins: I posted a long comment to the issue about an hour ago. Long because I went into our reasoning, but can read tldr and proposal<br> <fantasai> TabAtkins: summary of our position, we the Chrome+Edge engineers find the current spec unshippable given the algorithm in it<br> <dbaron> https://github.com/w3c/csswg-drafts/issues/9041#issuecomment-2075210820<br> <fantasai> TabAtkins: it can trigger quadratic or exponential behavior, which could brick the page<br> <fantasai> TabAtkins: we acknowledge they are edge cases<br> <fantasai> TabAtkins: The restrictions we need are not ones that Jen's demos hit<br> <fantasai> TabAtkins: We just need to restrict to either a) fixed or flexible tracks OR b) intrinsic tracks<br> <fantasai> TabAtkins: every demo presented works in those constraints<br> <fantasai> TabAtkins: problem only happens when you can mix intrinsic track with other types of track sizing<br> <florian_irc> q- later<br> <fantasai> TabAtkins: because that's when spanners start to contribute differently in different racks<br> <Rossen__> ack TabAtkins<br> <Zakim> TabAtkins, you wanted to discuss after the demos<br> <fantasai> TabAtkins: On a more conceptual level, we thing there's a number of friction points where the syntax is suboptimal because designed for 2D grid<br> <fantasai> TabAtkins: or concepts don't directly translate and need to default values instead of rejecting at parse time<br> <fantasai> TabAtkins: e.g. auto-fit is treated as auto-fill<br> <fantasai> TabAtkins: However, we thing there's also significant conceptual similarity to grid. It has tracks, lines, etc.<br> <fantasai> TabAtkins: so should do as much connection between the two<br> <fantasai> TabAtkins: e.g. have subgrid take lines from a parent, assuming we have fixed sizing bits<br> <miriam> q+<br> <fantasai> TabAtkins: Similarly submasonry value, taking lines from parent<br> <florian_irc> q- later<br> <fantasai> TabAtkins: Everywhere they interact, make it easy to translate knowledge. But they're still not the same thing, and enough pain points that they should be done in different display types<br> <lea> Lea: These demos are impressive, and this is solving real author pain points.<br> <lea> Lea: I did have some reservations about how this combines with multicol from an author point of view, but I think I'm now convinced this makes sense as a part of grid.<br> <fantasai> scribe+ lea<br> <Rossen__> ack lea<br> <dholbert> TabAtkins' github comment with more details: https://github.com/w3c/csswg-drafts/issues/9041#issuecomment-2075210820<br> <lea> Lea: One thing is that the `masonry` keyword seems a little magical. How can authors set constraints on the min and max size of these generated rows/columns? How does it interact with `grid-auto-flow`?<br> <fantasai> Lea: e.g. what about 'dense' keyword?<br> <florian_irc> q-<br> <fantasai> miriam: Agree quite a bit with Lea. Agree we like this as part of grid. Syntax feels right.<br> <fantasai> miriam: would like to add a few more constrainst<br> <Rossen__> ack miriam<br> <fantasai> miriam: get that there's some constraints on implementation<br> <jensimmons> q+<br> <fantasai> miriam: Looking at separate masonry proposal, seems like new terms for similar things<br> <fantasai> miriam: why do I need to learn new terms for the same thing?<br> <fantasai> miriam: I also might want to switch between grid and masonry at different break points<br> <fantasai> miriam: keeping them together makes it a lot easier to do<br> <lea> +1 to miriam great point about switching to/from masonry<br> <schenney> scribe+ schenney<br> <fantasai> miriam: I like the grid syntax if we can make it work<br> <Rossen__> ack fantasai<br> <Zakim> fantasai, you wanted to respond to Lea's questions<br> <ydaniv> q+<br> <schenney> fantasai: Reponse to Lea. I don't iunderstand min/max rows columns. Maybe explain later.<br> <florian_irc> q+<br> <schenney> fantasai: Dense, autoflow maybe mergable from ? and ?<br> <Rossen__> ack jensimmons<br> <rachelandrew> q+<br> <fantasai> jensimmons: We put this out to designers and developers to see what kind of feedback we would get<br> <schenney> jensimmons: Get it to developers. See what feedback.<br> <fantasai> jensimmons: overwhelmingly people want to see this as part of grid. It's not 100%, but on issue in CSSWG it's roughly 80/20 in favor of building into grid.<br> <fantasai> jensimmons: authors prefer making it part of what they're already familiar with, already learning, as part of CSS Grid<br> <fantasai> ydaniv: +1 to what miriam said before<br> <Rossen__> ack ydaniv<br> <fantasai> ydaniv: thinking about interpolation, animating to/from masonry and grid<br> <fantasai> ydaniv: could be easier inside grid than between display types<br> <dholbert> q+<br> <TabAtkins> wrt the author feedback, note that the blog post argued exclusively against an overly simplistic model (only fixed-size, identical tracks, a la multicol). Every demo was showing how we need more than that. As I said, tho, every demo is perfectly fine; the actual restrictions we need are much more subtle. We can't take support for "what the blog post displayed" as arguments for "build it into Grid".<br> <lea> q+ to ask how does this work with explicit col/row placement?<br> <fantasai> florian_irc: Thanks Jen & team for the demos, and also for presentation. I had skimmed the blog but realized more things during presentation<br> <fantasai> florian_irc: more compelling<br> <fantasai> florian_irc: wrt Google proposal posted recently, seems it's fuller than what was originally discussed<br> <fantasai> florian_irc: I think we need more time on this topic, and discuss the differences between the two<br> <Rossen__> ack florian_irc<br> <Rossen__> ack rachelandrew<br> <fantasai> rachelandrew: WebKit team presented to developers saying the only way is to have grid implementation, and I don't think that's the case as Tab outlined<br> <fantasai> rachelandrew: but when I first started showing people Flexbox and Grid, people would say "it's inconsistent", because it was different from block layout<br> <fantasai> rachelandrew: at this point we have good understanding of formatting contexts<br> <fantasai> rachelandrew: my worry as someone who teaches this is, if we put masonry in grid we have to say "these properties only work in grid that's not masonry" or "these properties only work in grid that is masonry"<br> <florian_irc> s/more time on this topic/more time on this topic soon/<br> <fantasai> rachelandrew: if we build into a separate display type, can still have a lot of cool stuff, but not dancing around the differences<br> <Rossen__> ack dholbert<br> <fantasai> dholbert: we have a prototype implementation of masonry in grid<br> <florian_irc> s/more compelling/more compelling, and really makes the case for needing these capabilities<br> <fantasai> dholbert: I'm sympathetic to the performance considerations of every item in every track<br> <fantasai> dholbert: agree with sharing a lot of the same behavior with grid<br> <fantasai> dholbert: using a restricted form of track syntax but compatible for masonry, that's only possible to do by using a different set of property names<br> <Rossen__> ack lea<br> <Zakim> lea, you wanted to ask how does this work with explicit col/row placement?<br> <fantasai> lea: How does masonry work with explicit grid placement?<br> <Rossen__> ack fantasai<br> <schenney> fantasai: If you specify specific track, maonsry item goes there.<br> <schenney> fantasai: Just like grid etc, move to that position and keep placing.<br> <Rossen__> q?<br> <schenney> florian_irc: Do you ignore a dimension?<br> <schenney> fantasai: Yes.<br> <TabAtkins> + there's a switch in masonry-auto-flow about whether to place all the explicit items first (like Grid does) or in the normal order.<br> <fantasai> Rossen__: Good discussion, let's review comments and come back to it later.<br> <lea> big +1 for integrating masonry-auto-flow with grid-auto-flow if this becomes part of grid<br> <astearns> let’s keep posting and conversing in the issue - please do not wait until we can schedule more call time<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9041#issuecomment-2075386656 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 24 April 2024 16:36:30 UTC