[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...

[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 https://github.com/w3c/csswg-drafts/issues/9733#issuecomment-2075740240 ...

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