[css-grid-3] Renaming masonry keyword

[fantasai]

Just overheard a conversation suggesting that maybe masonry isn't the word we want, so opening an issue to track that suggestion. Maybe pack? Open to ideas, if we find one we like we can consider renaming it...

[yisibl]

Can you explain why you use pack? For Chinese developers, you are more familiar with the term Waterfall Layout, which is used on the front page of many Apps.

https://github.com/topics/waterfall-layout

[fantasai]

I suggested "pack" because you're packing things into the grid as tightly as possible in that axis, instead of creating grid rows.

Waterfall is a lovely name, and a better analogy than masonry imho!

[bkardell]

fwiw, I have only ever heard this referred to as masonry layout, and using the same topics measure that @yisibl provided, there are 151 repos on the masonry-layout topic vs the 28 for waterfall, kind of confirming to me that that is a more widely understood term... So, why not use it? Where did you overhear the conversation @fantasai and what about it should it cause us to change? I'm sure there's a reason, it's just not clear from the issue what it is.

[yisibl]

For non-native English speakers, masonry may seem a bit difficult to understand.

[jfkthame]

To my mind, the waterfall name would only be appropriate if used in the vertical axis. For the horizontal version (e.g. like I see in Google image search results), masonry is a better analogy.

[SelenIT]

The eponymous JS library by @desandro is being presented as "Cascading grid library", which is somewhat related to watefall metaphor too. But it seems to me that "masonry" already became a common name for that type of layout, for many non-native English speakers as well (for example, in the Russian-speaking community the word "masonry" is most often used without translation as none of the possible translations became prevalent).

[desandro]

I'd recommend sticking with masonry as its been used since 2009, so its an established convention, not just with my library, but many other approaches and techniques.

[yisibl]

Let's finalize the naming as soon as possible, Safari seems to have shipped. WebKit/WebKit#24414

cc @nt1m

[fantasai]

@yisibl Safari hasn't shipped yet, let's not panic. :)

[fantasai]

@jensimmons points out that none would have been a very nice keyword for this purpose. Unfortunately it's the current initial value!

[jensimmons]

The longer I look into this, the more convinced I am that we can let go of the idea of "masonry layout" and instead embrace this framing:

• CSS Grid currently lines things up in both columns and rows
• Thousands of years of graphic design have used grids, but for most of that time, "grid" = columnar grid. Where things lined up in columns, but not in rows. The idea that rows should line up too is very modernist.
• grid-temple-rows: off is what "masonry" is doing. It's turning off lining things up in the row direction.

Like Elika said, none would be a great way to express this. Rows? None. But since none already means no explicit rows (only implicit, please), we cannot use none.

"Off" may not be the best word, but that's what I'm using at the moment. Please turn off the functionality that creates rows.

[potch]

Would there be value in re-using the dense keyword (as used in the -auto-flow properties), or would that cause confusion? It has a similar meaning in terms of intention to the auto-flow situation (fill gaps please), and is semantically similar to pack. Otherwise, off or some other version of "no rows" makes sense.

[chrisarmstrong]

I don’t mind masonry, as it has become a fairly established term in the industry (we use terms like leading even though we’re not working with metal type anymore).

However, if we were wanting a different metaphor that might be more universally recognisable, I'd suggest Tetris, as the layout logic (especially with multi column elements) resembles the stacking behaviour of one of the most famous video games of all time (though upside down, to be fair).

That said, I can also see the logic in ditching the metaphor and going with something more generic like auto-flow, stack or pack... but I bet all the articles explaining how to use it will still be titled “Here’s how you create a Pinterest-style Masonry layout” or similar.

[oscarotero]

I think grid-template-rows: none is confusing, because it seems that no rows are created, but they are. The only difference is they are not aligned each other through all columns. In fact, row-gap is used to separate the elements vertically, so it's contradictory to indicate that there's no rows, but we apply a gap to separate them.

I think the keyword should reflect the idea of the rows, or columns are not aligned each other. For example grid-template-rows: no-align as opposed to align (the default behavior).

I'm thinking of this keyword as an initial setting, like inset is for box-shadow (inset configures the type of the shadow, but you have to configure the offset, size, color, etc).

For example, it could be possible to customize the size of the items:

grid-template-rows: no-align;

/* Which is equivalent to: */
grid-template-rows: no-align repeat(auto-fill, auto);

/* To strech the elements so they are also aligned at the end */
grid-template-rows: no-align repeat(auto-fill, minmax(auto, 1fr));

This idea of configuring the size of the items can be implemented in the future if it's too complex. For now, simply no-align is enough and cover most cases. And it leaves the door opened just in case we want to introduce more options in the future for fine tuning.

[rianmurnen]

“Masonry” has such a rigid meaning—set a brick in place and it stays put. It's a print-media mindset. I also think "masonry" would hamper adoption because of the legacy perception that strongly connects the word to the grid of images use case.

Like masonry, “waterfall” is another metaphor. I think it would be better to use a term that declares a state rather than a metaphor.

The underlying concept of waterfall is flow. “Flow” has established meaning in CSS so perhaps troublesome to use this way, but grid-template-rows: flow feels appropriately descriptive. It explains that a behavior is happening more so than off.

[TarryDan]

this really isn’t about the layout used by Pinterest or other similar sites. This is a mechanism for telling the browser, “please create a grid, but without any rows.”

I was dubious about how masonry was even conceptually a kind of grid, but this quote from the article on webkit was useful in seeing the gridness of it. So:

grid-template-rows: no-rows

Very explicit, no ambiguity or metaphor which might feel complex internationally, and no associations with what a masonry layout is 'for'. It's some kind of grid, but you turn the rows off. It's also less ambiguous than off or none (what is being turned off? of what is there none?), and it also resolves some of the discomfort around grid for me. 'a grid, with no rows'

The idea of using no-align because rows are in fact created is a good point, but just in terms of what feels intuitive to me, what I would expect to happen when I choose no-rows would look like masonry. no-align, I associate align with text-align and align-items, moving objects around in a space. By implication, no-align suggests there should be a value align, but there's not - the opposite is rules for rows, which aren't exactly alignment IMO. The pair 'rows like this' and 'no rows' feel more clear.

& because the rows here aren't really behaving like rows - it's more of a kind of margin-between that can nevertheless be targeted as if they were rows. We wouldn't conceptualise a column of blog posts filling the whole span as 'each post is a row' or, a single plate on a shelf as 'a row of plates' in other contexts - a row implicitly has two or more objects in it, or a row is a horizontal relationship between things.

(no-snap? rows are present between objects, but objects don't snap to them - instead, the rows follow where the objects are. I like this less.)

There's also the way that align is used of vertical orientations in various contexts. Hopefully, masonry will be available for both rows and columns. It's a bit messy the way the orientation 'align' targets changes depending on how you're flexing. no-rows and no-columns are a clear pair, where 'align' makes me think 'aligning to what and in which direction'?

[rachelandrew]

Commenting here as this is where the community conversation has been directed to, but I still have concerns with the idea of bundling Masonry in with grid. We'll have to account for masonry things in any future additions to grid, and there will be parts of grid that don't make sense in masonry and therefore need explaining as to why they don't work. Given that things like gaps and alignment are already dealt with in other specifications, and there's no reason not to re-use the various methods of sizing columns from grid, having a display: masonry (or display: waterfall or whatever) makes a lot of sense. Then masonry can be specified with just the things developers need, not having to include things they don't because that's how grid behaves. There's an alternate proposal in #9041.

I'd also love to see Masonry (via any version of the spec) landed alongside reading-order-items. There's a strong possibility of disconnected source vs reading order when using masonry type layouts. There is discussion in #5675 about the problems, specifically related to masonry layouts. I think the reading-order-items proposal currently being specced here provides a route to a solution, and it would be great to be able to provide that alongside masonry.

[oscarotero]

After seeing the proposal of a different display value for masonry-style grid, I understand better the reasons of move it out of display: grid. Some properties like grid-template-areas make no sense for masonry, and other properties like masonry-auto-flow, justify-tracks and align-tracks were created only for masonry.

So I think a display: whatever is a cleaner solution.

[taksyon]

Heres some brainstorming:

Bricks
Tiles
Chasm
Collage
Mosaic
Cells
Waterfall
Quilt << I like this
Interlock
Canopy
Hive
Chain
Reef
Hexis
Shard

[chriswales95]

I quite like tiles display: tile.

Brick is also good display: brick.

Both are easy to type and are pretty basic and easy to understand. You can visualise both clearly and it's easy to understand what the intended result should be.

[ehvana]

I suggest: grid-template-rows: fluid

[kbrilla]

Please, mayby create an questionnaire like with nesting, to gather more votes on the matter.

[sfinevelir]

compact, perhaps? In particular, if the final approach is part of grid-template-rows, compact would, ideally, imply that the rows are compacted as opposed to retaining a "rigid" vertical structure.

Either way, 👍 for renaming masonry to something less metaphorical!

[theinfinit]

For the argument against display: brick, or masonry, I will post this inspiring brick wall here to remind us, that masons, set the CSS of walls to grid-template-columns: "OFF", but grid-template-rows to masonry. Which is, the opposite of the proposed masonry layout :)

[NetOpWibby]

Any of fluid, off, or waterfall sound great to me. brick seems silly, especially because the masonry is horizontal, not vertical. Makes me think of being in the Matrix wall-running sideways...THEN it'd make sense.

[vintagedave]

row: off combined with having row: none is potentially confusing because you have two 'no' options, both with different meanings. This kind of ambiguity is something I recommend avoiding.

Instead of specifying by what it is not, can we specify by what it is: columns-only, column-flow, or similar?

[shsteimer]

grid-template-rows: unaligned? Arguably each column is still divided into "rows", but they're not required to align with each other across columns like in a normal (two-axis) grid.

(Or grid-template-columns: unaligned for the horizontal-masonry version, obviously.)

This aligns well with my mental model of this type of grid as well. Commenting to suggest considering something like grid-template-rows: jagged

There are rows, but the rows are not forced to align and columns can have different numbers of rows within, as in a jagged array. https://en.wikipedia.org/wiki/Jagged_array

[maxhoffmann]

When it comes to API design I like to remember the rule "make invalid states unrepresentable". With this rule in mind, applying masonry layout vertically/horizontally via grid-template-rows: off or grid-template-columns: off creates the possibility of an invalid state:

.invalid-masonry {
  display: grid;
  grid-template-rows: off;
  grid-template-columns: off;
}
/* invalid but still possible */

Therefore I’d argue for using a different display value like display: waterfall, which could then have a flow-direction of inline, block etc. Turning one axis off in grid layout creates an invalid case and also disables the main idea of grid layouts in my view. I’d love to see more ideas that go into the direction of avoiding invalid CSS, so that we cannot shoot ourselves in the foot this easily. Another upside of flow-direction is that one might toggle the waterfall direction via a single CSS variable. flow-direction: var(--direction);

[ricktheartist]

This is the best argument I have seen for creating a new display type.

[t-var-s]

I still think leveraging display grid might be a nice trade-off 🤔
I also agree with avoiding metaphors and suggest something like
grid-template-rows: absent

(For what is worth, I'm not a native English speaker)

[pageaffairs]

What a fascinating discussion to read. Jenn's article is a very compelling argument for including “masonry” (or whatever it will be called) in Grid, given how many options and combinations can be created. But having the likes of Rachel Andrew argue otherwise certainly gives me pause. At least we would have to modify how we explain Grid, as it will no longer strictly be a layout algorithm for columns and rows — although it's not too much of a stretch to add "unless you want to tightly pack elements along one axis" or something like that.

This discussion is all in English, though, and we are a pretty privileged bunch getting to discuss which English word will be used for this. At least it should be something easy to understand and spell. Even I have trouble spelling “separate”, let alone “disintegrate” etc., which many people would have to learn to spell, remember and understand as a concept. Something like “off” is much simpler and to the point, even if you can argue it's not strictly true. Maybe “tight” would be an option, but then you get spelling and perhaps comprehension issues again.

[qpn6ph9q]

grid-template-rows: elide; would be my preference. This layout fits both common definitions of the word elide.

[leonardo-fernandes]

Would there be value in re-using the dense keyword (as used in the -auto-flow properties), or would that cause confusion? It has a similar meaning in terms of intention to the auto-flow situation (fill gaps please), and is semantically similar to pack. Otherwise, off or some other version of "no rows" makes sense.

The keyword dense makes sense since the new rows would "fill gaps" left by previous items due to differences in aspect ratio, while also conveying that this layout will optimize the 2d space used by the grid.

[gorlanova]

Hi ! Non-native english speaker here, after giving it some thoughts and reading the suggestions made by everyone, those words make the most sense to me :

• masonry : I already know the word and what it refers to, so that would not bother me much
• off : makes a lot of sense to "de-activate" rows (or columns)
• tile : very simple keyword, easy to understand i think
• dense : the concept is clear and it's easy to understand, means no air in between
• magnet : I thought about this one because elements are bound next to each other (as a pile of magnets)

Hope my two cents will help !

[fantasai]

@jensimmons wrote in #9733 (comment) ...

grid-template-rows: separate
grid-template-rows: disband
grid-template-rows: disjoin
grid-template-rows: disperse
grid-template-rows: disintegrate

How about split? SImilar concept, but it's easy to spell.

[dulldaydudes]

I love this so much. I was coding the https://board-game.center next version and struggling with a column attempt. The only thing to change was going from block to grid and using 'grid-template-rows: masonry;', and it's looking great. (An Online demo will follow in some days.). But after all, I prefer the off option and still go with the display grid. I'm following the argument from Kevin Powell's video that it's still a grid layout.

[davemaxwell77]

The more I read the various discussion points, the more I get the feeling that adding a whole other display type seems to be overkill. It's a whole other faction where we'd have to learn the nuances and differences (an argument could be made that masonry is closer to flexbox than grid due to it's unidirectional nature), and an avenue where maintenance efforts would be duplicated for those features which cross the types. Keeping everything within the grid reduces maintenance efforts, lessens the chance of inconsistent behaviors to due things not being maintained in both situations, etc.

But I admit to not caring for the term "off" for some reason. Just seems clunky because you're really not turning them off but ignoring them instead. The term ignore seems more accurate to the nature of the effort.

grid-template-rows: ignore /* for vertical masonry layouts */

or

grid-template-columns: ignore /* for horizontal masonry layouts */

[gilsonnunesfilho]

As a graphic designer, the thing that makes more sense to me is to keep it into grid. Grids doesn't need to be two dimensional, the columnar grid @jensimmons mentioned makes the most sense to me.

I was pretty convinced that the sintaxe of disabling the rows with grid-template-*: off, or flex, or dense was the way to go. But then I came across this @maxhoffmann and it makes a LOT of sense.

When it comes to API design I like to remember the rule "make invalid states unrepresentable". With this rule in mind, applying masonry layout vertically/horizontally via grid-template-rows: off or grid-template-columns: off creates the possibility of an invalid state:

.invalid-masonry {
  display: grid;
  grid-template-rows: off;
  grid-template-columns: off;
}
/* invalid but still possible */

Therefore I’d argue for using a different display value like display: waterfall, which could then have a flow-direction of inline, block etc. Turning one axis off in grid layout creates an invalid case and also disables the main idea of grid layouts in my view. I’d love to see more ideas that go into the direction of avoiding invalid CSS, so that we cannot shoot ourselves in the foot this easily. Another upside of flow-direction is that one might toggle the waterfall direction via a single CSS variable. flow-direction: var(--direction);

So I thought why not create a new property?

.columnar-grid {
  display: grid;
  grid-template-columns: repeat(3, 1fr);
  grid-axes: column; /* new property. Could accept both (default), column and row (or maybe inline and block) */
}

The behavior should be similar to display: flex with align-content without flex-wrap: wrap. It should not work and maybe show an info message.

So if grid-axes: column, the grid-template-rows should be disabled and show a message.
And if grid-axes: row, the grid-template-columns should be disabled and show a message.

[rianmurnen]

+1 @fantasai suggestion of pack

Why pack?

How the browser handles placement is the unique behavior gained from this type of layout.

Reading over the CSS Grid Layout Module Level 2 and Editor’s Draft of CSS Grid Layout Module Level 3 the word “pack” is used to describe placement — especially dense packing.

Benefits

• Short / concise
• Not used in existing CSS properties or values
• Not a metaphor
• No en-US versus en-UK alternate spellings

Questions

• Does pack translate clearly to non-English speaking languages and cultures?

---

Using pack

The Webkit blog is persuasive and the use cases @jensimmons shared are wonderful. This is definitely a type of grid but that doesn’t mean it must be part of CSS Grid or within display: grid.

Over the last two weeks I’ve been reading all the related CSS WG issue threads about the syntax and implementation. In particular @tabatkins comments on issue #9041 stand out:

• allows you to write things that don't make sense in a Masonry context
• Friction Points with Masonry-in-Grid

There are so many properties and values within CSS Grid. Some make sense for pack/masonry/waterfall, but some very much do not. Especially once you start writing complex values or use shorthand declarations. And consider situations where @media, or @container are used with the cascade to change a declaration in certain contexts.

Once I started experimenting with full rulesets, I found it much easier to author and reason about display: pack than when the placement behavior was mixed into display: grid with grid-* property values.

.container {
	display: pack;
	pack-template-tracks: ;
	pack-template-areas: ;
	pack-direction: ;
	pack-threshold: ;
	pack-auto-flow: ;
}
.item {
	pack-track: ;
	pack-track-start: ;
	pack-track-end: ;
}
@media {
	.container {
		pack-template-tracks: ;
	}
}

In that media query, pack-* helps disambiguate. And when different sections of a stylesheet or different @layers are using the cascade to change a declaration, reading pack-* offers context about the layout types unique constraints that reading grid-* does not.

[nowthis]

I showed my spouse the really interesting text-layout example from Jen Simmons' article (embedded below).

She immediately said: "so, like a magazine."

Up above "newspaper" was mentioned, but I understand not wanting to bring paper into the digital discussion.

I do think magazine could deserve some consideration.

Yes it's a metaphor, but it is a metaphor without a rigid visual definition.

[pageaffairs]

@nowthis — Maybe the confusion with "magazine" is that some magazines are laid out like this, but some aren't, so it isn't a specific reference to what we've been calling "masonry".

[renet]

As this is a lot about language, even though I'm not a native speaker, I know that even in my mother tongue, it can be really hard to come up with a good word to describe something properly, and sometimes the best word is missed, just because nobody thought of it. So I'll try to throw in some more suggestions and hope they're considered useful.

• grid-template-rows: content
  As the rows of each column are defined by their contents.
  Alternatives: children, cells.

• grid-template-rows: flex
  This has been mentioned, but not really suggested. Inside a column, the rows behave just like one single child element with display: flex would (and flex-direction depending on wether it's used in a row or a column), if it contained all the cells of that grid column/row.
  Alternatives to prevent confusion with flex-box: flexible, dynamic, adapt, float.

• grid-template-rows: column / grid-template-columns: row
  Probably not the best idea, but as each column handles its rows on their own and vice versa, this could make sense. It would even contain something like "you need to define a grid-template for the columns, if you want to use column here, but a disadvantage of course would be the different values depending on the property.
  Alternatives: columns, rows.

• grid-template-rows: save-space
  In addition to suggestions like dense or compact this just describes what this property does for a column: saving space regarding the definition of a grid-template for the rows.
  Alternatives: reduce, min, minimal, min-space.

[montemartin]

I'm surprised I haven't seen more mention of the the first two ideas @renet mentioned. content and flex both make sense as a keyword for grid-template-rows. They explain the behaviour using patterns already established in CSS, no new keywords necessary.

grid-template-rows: content seems perfect. One dimension of each child will always be determined by the content in this layout. It follows the pattern of keywords used for width and height, children behave as if they had both min-content and max-content set on them. In order to avoid confusion with content: (the property) maybe flow-content would be a better option for the keyword.

On a side note, I am partial to cascade. It represents the layout well, It's a word anyone using CSS should be very familiar with. 😉

[t-var-s]

Leveraging an already existing keyword, content can also be grid-template-rows: fit-content

[Crissov]

Just here to drop gallery and flush.

[JensDeMuynck]

As others have mentioned, for non-native english speakers the term masonry is not easy to understand. As @chrisarmstrong proposed, i like the idea of the term stack as you are basically stacking elements on top of eachother (from top to bottom, or left to right) and is (in my opinion) way more explicit.

I understand why pack is mentioned, but for me this doesn't imply a sense of direction, where i feel like it should have.

[mkimitch]

Hey everyone,

I’d like to throw in a couple of suggestions for the name of the masonry layout. How about flex-grid or adaptive-grid?

Flex Grid:

• It combines the familiarity of Flexbox with the grid concept, making it clear that it’s a flexible type of grid.
• "Flex" is a term many developers are already comfortable with, which could help with understanding and adoption.

Adaptive Grid:

• It captures the essence of the layout's responsiveness and adaptability to different content sizes.
• "Adaptive" is a straightforward and easily translatable term, which could be more inclusive for non-native English speakers.

I think these names better describe what the layout does and might be easier for a global audience to grasp compared to masonry. What do you all think?

[tenphi]

Hey everyone,

I’d like to propose a different approach that keeps things simple without introducing too many new keywords and abstractions.

We can activate the masonry layout by adding pack, waterfall, or next as a keyword to the grid-auto-flow property. (To clarify, waterfall is a new keyword I’m suggesting, and it can have a distinct behavior from pack, but it's a different story)

For example, setting grid-auto-flow: row pack would mean the layout is calculated using only the grid-template-rows property and ignores the grid-template-columns property. It can also work in a subgrid as well.

The masonry layout is a one-dimensional grid, so it always has at least one row and column. This makes terms like none, off, or disabled less appropriate, in my opinion.

Maintaining the concepts of rows and columns here is crucial because placement properties (place-justify, place-items) should work accordingly.

Thanks for considering this idea!

[fantasai]

Quite a few people suggested or +1'ed collapse, so I think the current leading proposal is to rename the grid-template-* keyword from masonry to collapse.

[cat394]

I believe that the term pack is the most appropriate.

This is because it is extremely easy to understand for developers familiar with grid layout. While the Masonry layout mechanism is one-directional, since it is implemented as part of the grid, developers are expected to adapt to the new functionality while maintaining the concept of two-dimensional layouts.

By using the term pack, it intuitively conveys that Masonry's functionality is an "automatic packing function" that fills elements without gaps. On the other hand, the term collapse simply implies that the grid lines are removed, and it is expected that elements will float while maintaining the same display order as the existing grid layout. However, that differs from the actual result.

Therefore, to correctly associate the actual layout method of the Masonry layout mechanism with the concept of an "automatic packing function" held by developers familiar with grids, it is most logical to use the term pack. This allows developers to accurately understand the new functionality and achieve the expected layout.

[bkwebster]

I had a thought regarding @jensimmons’s article:

Names in CSS are usually simple words that directly describe the result they create — like center, under, contain, clip, revert, ltr, always, break-word, hidden, allow-end, scale-down, wrap, smooth.

Which made me think that a word like “flow” or “wrap” might describe the result? “Collapse” is also good.

My other personal pref. is somehow setting “rows none” or “rows off” - a good approach but it’s unclear how to name that.

[adarshrkumar]

I honestly think that since we already have some cases of misnamed things, we should just stick to a similar convention of misnaming. I think the "grid-template-" values should be "no-rows" or "no-columns" to create such a masonry layout just like we have the "background-repeat: no-repeat". We could also have something sort of descriptive like "grid-template-": do-not-create;" I also like the use of ignore.

[alkorlos]

For the proposal of replacing metaphor to the term.

In the article from the WebKit team it's mentioned that in graphic design there are grid types like Modular Grids and Columnar Grids. Currently the grid in web implements Modular Grids, while masonry for columns is Columnar Grid.

The property or value grid-columnar wouldn't be suitable for the web, as it only describes a single axis. It would be convenient to use an existing term rather than invent a new one, however, as far as I understand, there is no term in design that encompasses both vertical and horizontal Columnar Grids. I haven't been able to find such a term, so if you know one, share.

[nathanchase]

The reuse and repurposing of existing keywords make for a strong argument to use collapse.

There's already:

• visibility: collapse: https://developer.mozilla.org/en-US/docs/Web/CSS/visibility
• border-collapse: collapse: https://developer.mozilla.org/en-US/docs/Web/CSS/border-collapse

To make the keyword the same and use grid-template-rows: collapse makes for:

1. an elegant and semantic reuse of an existing keyword
2. no need to create a new keyword
3. no need to decide on a new keyword where the meaning is potentially misunderstood