Directory of RSS feeds
Statistics

RSS feeds in the directory: 374

Added today: 0

Added yesterday: 0

Hi-Tech / Internet

Adventure Masonry layout in CSS

Css-live - Severstal your world! 07.05.2020 at 08:06

Community that speaks the languages of HTML, CSS and JavaScript

"Masonry-layout", it also "tile layout", it also "layout blocks", aka "Cascading Grid", it — or rather, one of its variants — "layout like Pinterest," she's... in General, the problem of layout this type of layout is known to the coders for a very long time, under many names. Earlier in pure CSS to the end she did not dare. You can achieve superficially similar results for individual cases, but some nuance escaped. In practice, you had to use JS libraries, primarily Masonry, written by Dave Desandro and, in fact, gave its name to this layout.

but in the Working group on CSS, a proposal, and after a few months — and its experimental implementation, which already can feel in Firefox Nightly/Beta for the flag. In addition to the clear joy, the novelty has managed to cause a lot of confusion and disputes. Try to understand.

the Statement of the problem And then the "masons"? :)

the Similarity of the name of the library and the legendary secret society is not accidental: both — the word "Mason". The overall logic of the masonry-layout similar to the logic of masonry: take the "brick" and put it close to the previous one.

But where at least alluded to the masons, there is not without confusion:). As it turned out, the word "masonry-layout" different people to imagine very different things — and often by default, everyone thinks their version is the only possible!

the Layouts and libraries

Some imagine the "masonry" as a set of completely random blocks, which is necessary as it is possible more densely to press to each other — like in this photo:

In the web form of blocks (so far) limited to rectangles, but their size can theoretically be any. In fairness, it's more of a different library of Desandro — Packery. Below is a screenshot from her site (the"cap" works there as a visual demo, all those dark rectangles are animated separate blocks):

Desandro there is a third library for layout blocks — Isotope. The author explains that the task Packery — packaging custom blocks and Masonry creates masonry layout (logical!:), and Isotope the emphasis on interactivity (dragging, etc.), and it can handle various mapping schemes (including "masonry"). But all three frameworks are broadly similar and, to some extent, interchangeable. Five years ago, Masonry has helped us to solve the problem of close packing, and the first example is called Packery... "masonry-gallery".

But most often under the "masonry-layout" means a layout where horizontally the blocks fit in some regular grid (take the whole number of columns, optionally with the dividing intervals), and vertical — as it will. First comes to mind is, of course, Pinterest, where all blocks are of equal width (one column). Many already think the word "Pinterest" a synonym for "masonry" and not even think about other options. But the capacity of the library is much broader, and its online documentation Dave gives many nice examples like this:

Two different block order

this is a key difference between the "masonry layout" from the usual multi-column: columns are filled with blocks not sequential, vertically and simultaneously horizontally. But in the library of the Masonry there are two modes, switchable parameter horisontalOrder:

By default, no option, next block hits in the short column, i.e. trying to get as high as possible. Thus the total flow blocks always comes from the top down, but their order horizontally completely unpredictable. But the filling of the columns is always more or less evenly (no in the same column blocks go over the edge, and the adjacent almost empty), it is convenient to dynamically load these blocs as scrolling.

And enabled the blocks on the contrary, comply with the order horizontally (the first block in the first column, the second in the second... n-th — n-th, n+1-th again in the first n+2-th — again in the second, etc.). Because the blocks are different and unknown in advance, the resulting "rows" quick start "jumping" up and down, and the height of the columns can be uneven. But since the author added such a mode, perhaps, for something he might need...

Subtotal: options

it Turns out that the masonry-layout — not one specific schema, but many different, though related, tasks. At least:

Dense as possible packing of blocks of arbitrary size, without reference to any mesh (like Packery); Writing blocks in a grid on one axis (with the multiple step) and dense packing on the other (as in the examples from Masonry); Fill column space available (Masonry default); filling the columns in order across (Masonry horizontalOrder c=true); ... etc (looking forward to your examples in the comments!) Approaches to CSS-column

This is the first thing that comes to mind when thinking of the layout a La Pinterest. Visually — almost that is necessary. A bunch of articles on the Internet directly represents them as "masonry with pure CSS". But the main snag is the order of the elements is not the one we're looking for. Dynamic loading not to do. And one more catch — columns cannot be combined, except that all at once (at least not yet). However, since the order does not fit, it's the little things...

Fluxbox

With flex-flow: column wrap; they are like Multicolore, but they have a powerful bargaining chip to control the order: the order property. This would have the ability to explicitly force columns Flex-items to be deferred (in Firefox it is already possible to emulate due to a bug) and it turns out the solution to 4-th version of the problem, filling in the columns in order. Oriol Bruto even showed him an example:

#flex-container {

display: flex;

flex-flow: column wrap;

}

#flex-container > :nth-child(3n + 1) { order: 1; } /* column 1 */

#flex-container > :nth-child(3n + 2) { order: 2; } /* column 2 */

#flex-container > :nth-child(3n + 3) { order: 3; } /* column 3 */

#flex-container > :nth-child(-n + 3) {

break-before: flex; /* so it must be for current spec */

break-before: always; /* works in Firefox, but it shouldn't be:) */

}

But... too many "but". This is just one version of the problem, not the demand. About the Union of the columns will have to forget — a one-dimensional flexbox such do not know. How about "compassion" — for each number of columns you will have to separately register n selectors: cumbersome and inflexible.

maybe... old floaty?

Their behavior is often very similar to option 1 (as in the Intro from Packery): strive to be as above, and if there is no space — look for it next to horizontal:

See the Pen

abvqOVz by Ilya Streltsyn (@SelenIT)

on CodePen.

That's just what they are looking for it only in one direction, leaving blanks. For example, here for target "Title 7" with a stock would be enough space under "Title 2", but to go back, "poddernuv" before reaching the "Title 5", the algorithm he is not allowed.

In the discussion on github it was noticed by Robert Utasi and suggested new value for the top left float property. I would rather call it dense left — similar to the grid-auto-flow: row dense in how they can be harmonized, which differs from the usual row just the fact that "fills the gaps". But this is a part...

well, in theory this could be a solution for almost all variants of our problem (except the fourth): when equal to or a multiple of the width blocks column would be visually turned out themselves. But any layouts on floatj there is a performance problem: the position of each block may depend on any previous, so when you modify or even just read the coordinate of any of them you have to clear almost the entire layout. So, maybe someday such an extension of flotow and add, but it is unlikely to be a panacea.

Or is it grids?

On the website of the Masonry at the top right it says: "Masonry is a JavaScript grid layout library". That is, the author himself considers his library tool for grid layouts!

Standard tools CSS grids almost solve the problem in option 2 (strictly defined grid, horizontal, dense packing content vertically):

See the Pen

Masonry (rubber column) for the CSS Grid by Ilya Streltsyn (@SelenIT)

on CodePen.

Unfortunately, a key detail — the height of the blocks in terms of occupied grid cells has to specify by hand (or by script).

For the simplest ("interesovalo") of option grids, and even with the "appendage" may be a bit overkill. But it is their two-dimensional nature combined with the already mentioned keyword dense for a method of autoryzowany, now allows you to fill the columns evenly, as often you need. And we get all the advantages of grid layout (all ways of setting column width, auto-fill , column-gap, etc.) on the horizontal axis.

So what grounds to base its implementing grids from mats Palmgren and his colleagues from Mozilla was.

the Current experimental implementation Examples

For examples need Firefox Nightly, Developer Preview or Beta 77-th version and above. To work, you must first switch the setting layout.css.grid-template-masonry-value.enabled in about:config. I especially want to mention:

1st example Jen Simmons (compare masonry layout with other circuits) 2nd example Jen Simmons (advanced features: columns of different widths, the elements of several columns, etc.) Example Rachel, Andrew, in which one element is rigidly attached to the grid lines of the New properties and values

the novelty is in fact only 2 major new features:

the Key word for masonry properties grid-template-rows/-columns, including masonry-behavior ACC. axis; a New property masonry-auto-flow control the order of output elements.

the Value of this property may consist of two parts. The first part is essentially the analog of the parameter horisontalOrder from the library of Masonry: the key word next it switches the order from the default (space) for filling the columns in order. And the second part responsible for the behaviour in that case, if some of the blocks explicitly set the binding to specific columns. By default, such elements are placed in the first place, and the rest fill the remaining space. But you can disable that and force them all to be in the order of a single "queue" (in my opinion, the case is quite specific, but you never know...).

by the Way, the order property here also works and affects the original order of the elements in which they "spill" columns. However, with it a particularly high risk of completely confusing, because the procedure here and so is not always obvious.

Objections and counterarguments Complexity

Grids and so complex — a lot of new properties with similar names, even a big pile of new values, the abyss of possible combinations, a large number of rules and tons of exceptions to them... And even sub-meshes (subgrade), themselves, are just coming into the browsers. And more interaction with other CSS modules, for example, the same columns. Plus possible future extensions (e.g., non-rectangular area or multiple grids on the same element). How it all gets friendly even with a masonry-mechanism?

But thanks to the tools of grids (all methods of setting the width of columns, etc.) it is now possible to impose something even the original Masonry could not — see the second example Jen Simmons. And it's supposed to work fast (native ability browser, but still the dimensions can be fixed on the container level and not counted as uploading content). It's a pity because those opportunities to give. And also not to duplicate the same functionality in different modules?..

This is not grid

Actually, we deprive the grid of its main feature — a structured grid of strips, based on the actual grid. If only one axis, but still. To set display:grid in order to end up with no grid as it is not very logical. This is especially annoying for those who have "masonry" was associated exclusively with "Pinterest-like" what is grid, it's more like flexbox with an unusual order of elements.

But what elements spanning two or more columns? For Eric Meyer, this argument was enough to change my opinion: Yes, it's not exactly the grid, but flexbox it even further.

inconsistent behavior

This duality — "like a grid, sort of not" — can also be a source of confusion and surprises, especially for beginners. For example, in the grid with the ' grid-template-rows: masonry, in theory, should not even be grid-rows (only columns), but in practice it turns out to be the only "magic" the first how-to-clear series. This is well illustrated in the example of Rachel (if you "play" with the values of the grid row for the item .box).

When I'm "tinkering" in this example, I suddenly came to mind: what if the grid is not broken, leave it a grid with rows and columns, but allow items to ignore the lines when the auto-space? I.e. not grid-template-*: masonry and grid-auto-flow: row masonry — sort "quite so radical dense":). Then, because you can actually do incredible things, combining the normal grid elements at a fixed position with a "streamlined" their masonry elements... wow! The idea is too crazy to to offer on the court Working group on CSS, I decided that to consult first with you:)

total

to sum up too early. In the current implementation the masonry at the base of the grids has obvious disadvantages, but it is tempting advantages. The discussion is in full swing, and sometimes great ideas spontaneously arise in the process. So get involved, experiment and don't miss the opportunity right now to influence the future of CSS!