Re: [csswg-drafts] Alternate masonry path forward (#9041)

The CSS Working Group just discussed `Alternate masonry path forward`.

<details><summary>The full IRC log of that discussion</summary>
&lt;TabAtkins> iank_:  When Masonry was introduced there was discussion about whether this should be a new display type, or built into grid<br>
&lt;TabAtkins> iank_: After reviewing this in more detail, I'm more convinced we want a new display type<br>
&lt;TabAtkins> iank_: We didn't have a great proposal for what this would look like, so I typed up some details in a quick issue<br>
&lt;TabAtkins> iank_: There's some fudnamental tensions between Masonry layout and Grid. This leads to some undesireable complexities, possibly perf problems<br>
&lt;TabAtkins> iank_: So for a new masonry display type, we can do masonry-first, rather than bolting it onto Grid<br>
&lt;TabAtkins> iank_: This is so far a very simple proposal, it can be extended in the future, but it concentrates on the core use-cases<br>
&lt;TabAtkins> iank_: Handful of props. masonry-template tells how your non-masonry'd tracks look<br>
&lt;TabAtkins> iank_: One detail is that, at least for now, ahving all your tracks the same size is important for perf.<br>
&lt;TabAtkins> iank_: We also ahven't seen different-size tracks in the wild.<br>
&lt;TabAtkins> iank_: Another is masonry-direction, same concept as flex.<br>
&lt;TabAtkins> iank_: There are example where you want your masonry items to flow upwards<br>
&lt;TabAtkins> iank_: Another detail - you can tell a masonry item to span, but not specify in a specific track. Again, based on use-cases we haven't found any use for that.<br>
&lt;TabAtkins> iank_: A few other bits about alignment, squaring off.<br>
&lt;fantasai> scribe+<br>
&lt;TabAtkins> Rossen_: Next steps?<br>
&lt;TabAtkins> iank_: We might be interestsed in prototyping this in Chromium. I think if there are any fundamental issues, or use-cases that aren't covered by this proposal, that would be good to hear about<br>
&lt;TabAtkins> Rossen_: I see the issue thread is already fairly active, some +1s, some open issues.<br>
&lt;TabAtkins> Rossen_: I propose we take the convo back to the issue. When we have enough of an understanding on next steps we can bring them here.<br>
&lt;fantasai> -> https://github.com/w3c/csswg-drafts/issues/9041#issuecomment-1710838816<br>
&lt;TabAtkins> fantasai: I took Ian's issues and split them out into sub-issues<br>
&lt;Rossen_> ack fantasai<br>
&lt;TabAtkins> fantasai: I think we should go thru and address these individually<br>
&lt;TabAtkins> fantasai: The q of whether to make this a new display type or part of grid is kinda like the top of this issue, but some of the questions are "well is it even possible to build this into grid?" and I think we should answer that first<br>
&lt;TabAtkins> fantasai: Then the question about a new display type isn't about whether or not it's possible, but whether it's *better* to be part of Grid or a separate display type.<br>
&lt;TabAtkins> fantasai: I think all the issues Ian raises are addressable within the Grid framework, so it would be good to go thru the individual issues to see if they're actually blockers.<br>
&lt;TabAtkins> fantasai: Then we can come back and see whether there's acutally a blocker that forces a new display type, or if it *is* possible in Grid so it'll be more a decision of which is better<br>
&lt;plinss> q+<br>
&lt;TabAtkins> iank_: One thing I want to ensure is that, while lots of things are possible, perf is important.  I'm concerned about quadratic behavior to add this into Grid.<br>
&lt;Rossen_> ack plinss<br>
&lt;TabAtkins> plinss: Orthogonal q - what's the status of layout worklets?<br>
&lt;TabAtkins> iank_: We have a prototype; we want to clean it up after our layout rearchitecture.<br>
&lt;TabAtkins> iank_: It's not a huge list of issues, we're just evaluating where it is on priority.<br>
&lt;TabAtkins> plinss: k, just curious. if we're experimenting with new display types, seems like a great opportunity to explore in userland<br>
&lt;TabAtkins> (fwiw I'm fairly certain Masonry *can* be done in the existing layout worklet API)<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-1758047553 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Wednesday, 11 October 2023 16:16:47 UTC