- From: Joshua Lindquist via GitHub <sysbot+gh@w3.org>
- Date: Tue, 05 May 2020 20:17:29 +0000
- To: public-css-archive@w3.org
> > One of the debates we've had is whether we should make Masonry a part of Grid, or to make it a separate display type. By adding it to Grid, we then have all of the tools of Grid to define the layout in the other dimension. Which makes it far more powerful than the Masonry JS library. > Is there something preventing `display: masonry` from adopting the important features from `display: grid` (like track sizing/naming) if it is not included in the Grid spec? ---------- I share the concern that adding complexity to Grid could be a problem in the future. Adding a new feature to Grid means making sure that everything works with Masonry as well. Syntax/features may not work in the expected way and the answer could be "it's that way because of Masonry". I feel like making it a separate display type would give more flexibility to both even if they share a lot of syntax/features. I think that just adding `display: masonry` is the easiest to understand, but I know I've read concerns previously about adding too many display types for every possible design. If it needs to be baked into an existing specification, I think Flexbox or Multicol makes more sense - especially Multicol - but it would require Multicol in the block direction to make some of the examples work and that wouldn't get you the more advanced features from Grid. -- GitHub Notification of comment by JoshuaLindquist Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/4650#issuecomment-624283331 using your GitHub account
Received on Tuesday, 5 May 2020 20:17:31 UTC