[css-grid] [css-grid-2] Manage GRID cell as FLEX (subgrid).

[korenevskiy]

Adding support for styles like this

grid-direction: ...;
grid-wrap: ...;

in GRID
We perceive GRID as something more advanced than FLEX.
But if we draw an analogy, we can see that if FLEX is a full-fledged completed embodiment of the idea. Then the GRID is not finished.
There is a proposal to complete the idea of GRID. I propose to make each GRID cell similar to the FLEX markup.
So we need style properties

grid-direction: ...;
grid-wrap: ...;

Appointment:
We use a grid for the site: Header, modules, footer and content.
by setting a position in the grid for each block, we can solve our problems, but only apart from one important problem we have not solved.
If we place several articles in the grid in the content position, then the articles will overlap each other. But the number of articles is an indefinite and unknown quantity in the layout. Today there is 1 news on the site, and tomorrow there is already a lot of news. We are forced to use nested tags. But it happens that nested positions require stretching into several columns.

Or for example, you add a second news block to the page, we do not need to rewrite the layout, we need to create a nesting of blocks. If we can manage each cell as FLEX, then by setting grid-direction: column;
we will get the ordering of news blocks in one cell.

Do you think it would be useful for you to use the GRID-DIRECTION and GRID-WRAP properties managing each cell as FLEX.?

body{
	display:grid;
	grid-template-areas: "left content right";
       grid-direction: column;
}
.content{
	grid-area: content;
}

<article class='content'>Blog article one</article>
<article class='content'>Blog article two</article>
<article class='content'>Blog article three</article>

All these blocks are now arranged in one cell as a column.
I repeat that my idea is to determine the behavior of the blocks by placing them in one grid cell. In one grid cell.

Example

[korenevskiy]

@gregwhitworth @chrisdholt
I want to ask you for your advice.
Do you think this is something worthwhile or not an interesting idea at all.

[tabatkins]

As far as I can tell, what you're asking for is already provided by the grid-auto-flow property - any grid items that aren't explicitly placed can instead automatically flow into grid cells one-by-one, and you can control whether they flow in a column-first direction (vertically until they run out of cells, then starting a new column) or row-first (horizontally, then starting a new row).

If you don't know how many items you'll have, and thus don't know how many extra rows/columns might be needed, you can use grid-auto-rows/-columns to control the size of the implicit rows/columns that get auto-created for you.

[korenevskiy]

As far as I can tell, what you're asking for is already provided by the grid-auto-flow property - any grid items that aren't explicitly placed can instead automatically flow into grid cells one-by-one, and you can control whether they flow in a column-first direction (vertically until they run out of cells, then starting a new column) or row-first (horizontally, then starting a new row).

If you don't know how many items you'll have, and thus don't know how many extra rows/columns might be needed, you can use grid-auto-rows/-columns to control the size of the implicit rows/columns that get auto-created for you.

I'm sorry, but you didn't read carefully.
I wrote that in my idea, each individual cell behaves like a separate FLEX container.
You are suggesting to me that the filling with tags should take place in different cells.
And I wrote what the behavior of a single cell will be if a lot of blocks fall into it. Many blocks will fall into one cell.
Otherwise, what's the point of what I'm offering? It is obvious that each GRID cell should be completely equivalent to FLEX.

[SelenIT]

each individual cell behaves like a separate FLEX container

This is also totally possible already by setting display:flex to the grid item.

Regarding making this behavior the default one, I doubt it would be a good idea as changing the internal behavior of the element implicitly just because of the type of its container seems rather counter-intuitive and potentially confusing. Having explicit options to make grid cells behave as block containers (useful for content-oriented websites) or flex containers and even nested grid containers (good for UI components), without implicit dependency of this behavior on the container type — as we have now — is much more consistent and makes more sense to me.

[korenevskiy]

each individual cell behaves like a separate FLEX container

This is also totally possible already by setting display:flex to the grid item.

I wanted FLEX behavior for a cell, and you offer me FLEX for a separate element.

Excuse me, I use a translator, express your the idea more clearly.
I'm not suggesting overriding implicit properties.
If I suggest entering GRID-DIRECTION; it means that this property will have a default value of NONE (this standart behavior). This value will correspond to the default behavior as now.

I didn't suggest changing the behavior from the container type at all.
Which container are you talking about?
I propose an idea without a container, in which the cell itself behaves like FLEX.
You probably know that GRID and FLEX have the same properties

    justify-content: ...;
    justify-items: ...;
    align-items: ...;
    align-content: ...;

In GRID, these properties determine the behavior of elements in each cell, completely similar to FLEX.
Moreover, the impact of these properties spreads in each cell within the same cell. Which means that each cell is a FLEX behavior.
So why not add the ability to place several elements in each cell? Almost everything is ready here.

You're talking about meaning. I propose an idea that will allow you to abstract from containers.
The development of the grid allowed us to abstract from the elements and the table. And my idea also allows you to abstract. You suggest using GRID technology with a desire for rigid binding to positions. It's as if you use GRID exclusively instead of TABLE, and you don't see any new abstract ideas.

[SelenIT]

So, returning to your example and diagram above, you basically want the <article>s to be laid out as if they were items of the common display: flex container placed into the content single-cell grid area — but without such container?

[korenevskiy]

So, returning to your example and diagram above, you basically want the <article>s to be laid out as if they were items of the common display: flex container placed into the content single-cell grid area — but without such container?

Yes
Figured out about the idea itself. What do you think about it?

[SelenIT]

Interesting idea! But it seems a bit more complex than just extending the Grid with one new feature.

Grid was not meant to replace or incorporate Flexbox. They are two different layout tools designed independently for different use cases. Their formatting contexts have different rules. Flexbox is mostly about distributing extra space, Grid is mostly about knowing the placement of each item in advance. Overlapping of grid items placed into the same grid area is intended, it can be useful to prevent layout shifts. Even the same justify-content property works differently in these contexts: in Flexbox, it works with individual items, while in Grid, it aligns the whole grid tracks (it has different alignment subjects, as the specification puts it). There are other conceptual differences as well, so it's good to have different options for different cases.

What you propose would be effectively a kind of "super layout" having both formatting contexts simultaneously, Grid rules for some parts and Flexbox rules for some other parts.

While this sounds really interesting, opens nearly infinite flexibility, and definitely would have its use cases, it also doesn't look simple, for both implementors and web authors. For authors, it would mean more cognitive load, having to keep in mind both sets of layout rules along with the rules of switching between them. For implementors, it would mean tons of edge cases with potential new bugs. And, to be honest, I'm not sure that there would be that many cases where items of the same hierarchy level would require that different layout rules, and avoiding extra wrappers to group some of them would be that critical.

But with all that said, I believe it's totally worth analyzing and experimenting (e.g. with Houdini custom layout). Moreover, we already have kind of precedent: the native Masonry layout, that also tries to combine Grid features with some non-Grid features.

[Loirooriol]

This seems like #546 or #1183.

[korenevskiy]

Example

It is very convenient when the elements are under each other.
When creating media expressions, we transfer elements to a new area, while the elements line up under each other.

Yes, very similar to #546
But I want to note that in #546
The general idea is described, without specific suggestions.
I offered a more specific solution.
My proposal simultaneously solves the problems of SUBGRID. Which makes them meaningless.

Before writing this idea here, I was sure that this idea had already been considered. Since this idea is logical when developing a GRID after FLEX.
I completely agree that the implementation of this idea was impossible initially, I think it is due to the timing of the release of GRID. It is better to create a GRID as it is now than to postpone the creation for many years.
But now GRID has already been created in browsers, and therefore we can consider the benefits and necessity of this idea.

[korenevskiy]

@SelenIT @Loirooriol @tabatkins
I will write abbreviated in the format flex:justify-content property, so that it is clear what property we are talking about.
You are right, the justify-content property has different meanings FLEX and GRID.
But at the same time flex:justify-items are completely ignored in FLEX. At the same time, the grid:justify-items and flex:justify-contents are equivalent to each other, with the difference that one is for FLEX and the other is for GRID.
So we will act differently for this task, we will use the grid:justify-items property to align several blocks inside the cells.
This property has only the values: start | end | center | stretch ;
Let's supplement these properties with new ones taken from flex:justify-content.
space-between | space-around | space-evenly | safe | unsafe;
This way we get a GRID with property
justify-items: start | end | center | stretch | space-between | space-around | space-evenly | safe | unsafe;

But for FLEX, we can supplement.
To avoid confusion with the justify-content properties, we can make a flex:justify-items alliance for FLEX, which will fully correspond to the flex:justify-content property.

As you can see, we have added a new feature, but at the same time we have made it easier to understand FLEX and GRID by comparing properties.
We will get a SUPER GRID. simultaneously performing FLEX functions