Re: [csswg-drafts] [css-grid][css-flexbox] Pinterest/Masonry style layout support

@frivoal Most of the examples I've seen use a consistent width for all columns, so I wasn't considering an option of different sizes as part of the layout requirement.

[David DeSandro's Masonry library](https://masonry.desandro.com/options.html#layout), which is also used in [Isotope](https://isotope.metafizzy.co/layout-modes/masonry.html) supports multi-column spanning objects (within a grid of fixed column sizes), in addition to the simpler layout I was focusing on.  The packing algorithm works most effectively if the item heights are also multiples of a grid row height, so that it becomes very much like a densely packed auto-fit grid. However, the number of row spans is calculated by the JS, and there may be gaps created by one element filling multiple columns that weren't the same height. So, this could be a basis for using `column-span` within `display: masonry` as I described it above.

In contrast, [Oracle Jet's masonry layout](https://docs.oracle.com/middleware/jet400/jet/developer/GUID-BD7B8E48-6BDA-49A7-A932-6F6B15900A87.htm#JETDG564) and the [Nested JQuery plugin](http://suprb.com/apps/nested/) are densely-packed grid layouts as defined in CSS grid, with each item given fixed row and column spans; they don't support arbitrary or auto-height items.

Other masonry JS libraries/plugins I found on a search, all use columns with the same width, each item in a single column, and heights determined by the content items: [Macy.js](https://github.com/bigbitecreative/macy.js), [Wookmark JQuery plugin](http://www.wookmark.com/jquery-plugin), [WordPress Masonry Layout](https://en-ca.wordpress.org/plugins/wp-masonry-layout/).

[This SitePoint article](https://www.sitepoint.com/understanding-masonry-layout/) also includes horizontal flow layouts in the category of "masonry", but they are more like wrapping flexbox: fill one row, then wrap to the next, with flexible size adjustments to fill the row width.

(One limitation of using `columns` is that it only divides the container along the inline direction. If you really wanted a layout in LTR language with a fixed number of rows, where you added items to the row that has the least content, so that the reading order goes down columns first then across the screen, you would need to change the `writing-mode` on the container to vertical, then change it back to horizontal on the items.  But I haven't seen examples of this layout in practice, so that doesn't seem like a problem.)

________________________

A comment on this entire topic:

The goal of the extensible web & of the Houdini project is to allow web authors to implement custom features, and let actual use determine which new web platform features are most wanted. Once an idea is proved popular, and a consensus has been achieved about its key features, _then_ it would be standardized.

I'm not a huge fan of the masonry layout, but I do believe that it has met this standard.

I just listed four different JS implementations of Masonry that implement the same basic layout rules.

There are also numerous search results promising "Pure CSS" masonry, which use multicol or flexbox columns to create something that is visually similar to the column-based masonry layout. But as mentioned elsewhere in this thread, these solutions are sub-optimal because the DOM order doesn't match the normal LTR reading order & the layout is unstable when you add new items to the container.

To me, the only confusions / questions about features (separate from debating the actual API) are:

- One of the masonry libraries also supports elements that span multiple columns. Should that also be included in the native feature?
- Two other libraries that came up in my search use the name masonry, but implement a 2D densely packed grid, which is now supported natively in CSS under another name. Does that mean that the name "masonry" is ambiguous, and another name is needed? (I'm pretty sure we can't use `display: pinterest-style`...)





-- 
GitHub Notification of comment by AmeliaBR
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/945#issuecomment-372133265 using your GitHub account

Received on Sunday, 11 March 2018 17:34:44 UTC