What problem does this address?

In recent releases, WordPress has increasingly embraced intrisic design as a fundamental modern styling methodology.

And since the term was coined, CSS Grid has been a central tool of intrinsic design.

The CSS Grid Layout Module offers a grid-based layout system with rows and columns, enabling an endless variety of layouts beyond its simpler cousin, Flexbox.

Nearly all modern CMSs have adopted CSS grid in some form.

Numerous Gutenberg issues have explored the topic of grids from several angles:

• Try: Editor Grid #4314 Use grid to absorb wide and fullwide alignments
• Block Editor: Implement a responsive grid mode for InnerBlocks and a basic grid block that leverages it. #18600, Block Editor: Implement a responsive grid mode for InnerBlocks and a basic grid block that leverages it 2. #20000 A bespoke grid block implementing almost the full range of grid properties
• Edit Site: Creating a new template from scratch #19254 Blank template potentially exposing a Grid block
• Query block: CSS Grid for Grid View option #32443 Query block: CSS Grid for Grid View option
• Post Template: Refactor ad hoc flex container to use layout block support flex type #44557 layout for Post Template
• Grid Layout type #47809 a grid profile for the group block
• Try adding a grid layout type #49018 Implementation of Grid Layout type
• The Layout Grid plugin which implements a responsive 12 column grid system

But a recurring challenge has been to design a user interface that copes with the versatility and complexity of the CSS grid properties.

A CSS grid block design needs to:

• fit the needs of both WordPress users and designers
• not over-simplify and constrain CSS grid options to the point of limited usefulness

A start-simple approach postpones the UI design issues down the road and constrains the real power of CSS grid, which is in the interplay of its 10 basic properties:

• grid-template-columns/rows/areas
• grid-auto-columns/rows/flow
• row/column-gap
• grid-column/row

A fully-functional CSS grid block needs to consider 3 potentially conflicting use flows:

• Using: A CSS grid block should be quick and easy to use, like the row block but with more layout options, without learning CSS grid.
• Designing: Designers need access to all the CSS grid properties, including column, row, and area templates. CSS grid design involves some level of CSS knowledge.
• Sharing/locking: Pattern, site and theme builders need to share grid layout designs in a way that it is easy for users to select and configure, but also lockable so that pre-built designs are used as intended.

A core design question is whether it is necessary, or feasible, to design an "ultimate CSS grid user interface" that is both easy for users without CSS knowledge and flexible enough for designers to access all of CSS grid's power.

Or perhaps multiple user interfaces on top of the css grid properties might be more tailorable to particular uses.

What is your proposed solution?

Here is a proof-of-concept CSS grid block that fully implements CSS grid and addresses the use flows of using, designing, and sharing/locking.

For users, it is easy to use, like a row block with more layout options:

There is a design panel for designers to make and save grid layouts for users to use:

Sharing/locking:

• Designers can create, name, save, and share layouts inside a specific block instance.
• Designers can customize the UI of a specific block to show only their pre-defined layouts, turn off standard layouts, or hide the Design panel.
• The Design panel can be turned off when locking is set on the grid block. There is an "enableDesignMode" block property.

Note that the css grid block works with the Query Loop block -- just put a Query Loop inside it and set the flag.

The block supports per-instance custom CSS, to enable advanced uses like different template areas at breakpoints. The placeholder ".wp-grid-name-class" is auto-replaced with the actual name of the grid block instance.

Possible refinements:

• auto-name each grid with hashing or other technique
• provide slots to add additional UIs for grid selection and design, like a classic 12-column grid
• Add a lock to the locking modal for grid blocks to directly disable design mode
• add a field for free-form names in the template-areas property, beyond single letters
• simplify the underlying CSS, particularly for the editor view, when the :has() pseudo-class is more widely deployed. This would allow removing the flag for enabling an inner Query Loop.
• further isolate grids in a server-rendered web component, perhaps when declarative Shadow DOM is more widely deployed
• provide an instance-specific custom Javascript field, to facilitate designing and sharing interactive grids

Hopefully, a proof of concept of a fully functional css grid block will inspire more consideration of how to extend WordPress's intrinsic design capabilities.