Gutenberg: [Explore] Site Block

[mtias]

As block areas are being explored (#13489) there should some time spent on exploring how a Site block might operate, and whether it's needed as an abstraction. Some of its salient aspects would be:

• It's always the _root_ block.
• It encapsulates global styles (such as colors for body text, links, or base font sizes, line-height, etc).
• Always occupies the full size of the editor canvas, so it's selection model is equal to nothing else being selected.
• Certain customizer functionalities are naturally ascribed to it (background color / image, for example).
• Can handle certain add_theme_support qualities (defines a grid, alignment widths, etc).

[jasmussen]

I took the liberty of creating a mockup for this. It is a relatively direct interpretation of this ticket. Paragraph block selected:

Here's what happens if you deselect a block, i.e. select the _site_ block:

Note that I included the breadcrumb bar as suggested in #17089 as it would play a part in the discoverability of this.

One of the benefits of this approach is that it is relatively simple to implement, UI wise. There are a couple of open questions, though:

1. When the Site block is selected, does it have a block toolbar?
2. Is it sufficient clear to the user that it's the _site_ that has been selected? Right now when you don't have any blocks selected, you see the document level sidebar.
3. If selecting the Site happens by deselecting all blocks, how do you deselect all blocks if all blocks are full-wide?

For question 2, and depending on where development on the sidebar goes, the tabs might solve this. I.e. selecting the Site might not also select the Site tab. Another approach could be to rethink the sidebar so Site and Document each have their own top-level button, and the Block sidebar becomes fully modal.

For question 3 we probably want to allow you to click outside the editing canvas in neutral whitespace like in the editor bar or the sidebar, to deselect blocks. Once again the Escape key could play a role there.

[shaunandrews]

Another idea I've been toying with is adding a "frame" around the document, and giving it a visual appearance similar to a sheet of paper sitting above another surface.

This would provides some room around the document that a user could click on to select a Site.

Along with this, it opens up a place for @jasmussen's breadcrumb trail.

One question I do have is what we do with the sidebar when the site is selected?

Having "Document" and "Block" there could be confusing. Maybe we'd add a "Site" tab?

[karmatosed]

Mentally a 'site block' makes sense in terms of a site space. I wonder though if that's a better way to call it, a space?

I guess when thinking about a tab in addition for this my brain wonders what document is for. If that's just settings perhaps that needs to be iterated or positioned in other spaces? It's a leap of exploring though as a mental model to have that sidebar. For me, I wonder if having 3 tabs makes sense of confuses types. Are 'document', 'block' and 'site' the same types that would fit the same panel patterns?

If we have a better way to show hierarchy in a true navigator, for me then seeing the root space a 'root block' makes sense.

[mapk]

@shaunandrews' frame concept works well when thinking about responsive preview controls in Gutenberg. If I select a mobile viewport, the frame can adjust to show the site in a mobile view similarly to browsers today.

Overall though, I'd prefer a site block to extend to the chrome around it similarly to Joen's concept.

When the Site block is selected, does it have a block toolbar?

Maybe. If so, it can always be in the Top Toolbar position.

Is it sufficient clear to the user that it's the site that has been selected? Right now when you don't have any blocks selected, you see the document level sidebar.

As the mockups exist right now, it's not clear. In the mockups, the Site block isn't providing any indicator that it is selected. Because it's a block, I'm half expecting to see a border somewhere. I don't want this... but would like some visual that a block is still selected.

If selecting the Site happens by deselecting all blocks, how do you deselect all blocks if all blocks are full-wide?

By clicking the Top Toolbar? It's always in view. I'm not sure it's very intuitive though? I'd expect to click on any negative space and not be stuck in another, difficult to understand, Site block.

Really great questions! I'm messing around with some thoughts right now.

[Wingo5315]

Maybe we should have an interface where the user can customise the header and footer in the Gutenberg editor? I think new users would find the "Site block" idea a little too complex, especially for beginners.

[aristath]

Maybe we should have an interface where the user can customise the header and footer in the Gutenberg editor? I think new users would find the "Site block" idea a little too complex, especially for beginners.

Though I like the idea of breaking it down like this, a header-content-footer structure is traditional but not global.
Not all sites have a header or a footer, and we shouldn't assume that people will keep structuring their sites that way in the future.
If the header is on the side instead of the top can we really call it a "header"? For example I've seen sites that have a left side-header with the navigation on the top and a copyright/footer link on the bottom, while the right side is all content, with breadcrumbs on the top. If we break things down to header-content-footer we'll just be hindering innovation and limit the user's imagination.

A site block on the other hand would allow users to do what they want, and a very good candidate for that "site" block is on #18600. Something like that would allow users to do whatever they want, unhindered from traditional limitations.

[mapk]

It feels like this may not be a thing anymore. Global Styles are being implemented without a Site block, and a Site block just may not be necessary in context of FSE. Do you mind if we close this out, @mtias ?

[mtias]

This one is still relevant for me because we might end up still attaching all of that to a site block once we figure out how to do the root container (grid, etc).

[mtias]

I'd like to focus this exploration on whether it makes sense to provide a foundational grid that can cascade to block properties down the tree (for example, every full-width block should inherit the grid) and as a source for top level global styles. cc @johngodley @jasmussen @nosolosw @jorgefilipecosta for thoughts.

We might also want to stop referring to it as a Site block and generalize it as an Area. That would coincide with the requirement of allowing different areas to overwrite style properties or layout baselines down the tree. It might be possible to coalesce this entirely into Template Parts as well and reduce concepts. In that case, Areas would be able to define a context that can supersede the base global styles values and integrate into the editing experience by offering focus, grid lines, etc.

[jasmussen]

Sounds good, I'll put on my list to do a mockup.

[jasmussen]

It's been a busy few weeks, but here are some mockups as promised. Emphasis mockups: I expect conversation to point out many errors. They also do not cover this aspect yet:

as a source for top level global styles

How selecting the site block affects the Global Styles sidebar is hopefully a topic that can get some clarity in discussing these mockups.

Here's the site editor, showing how to select the ~site~ area-block (named after the website):

Here it is, selected and showing a basic 12 column responsive grid complete with gutters:

You can select a template part inside:

Those template parts can be aligned to the grid. This part spans the full 12 columns, but the _Post Content_ block inside starts at column 4 and spans 6 columns:

[aristath]

It would also be beneficial to make it clear what we mean when we say "grid"...
To a designer a grid is usually the vertical columns and their gaps.
To someone writing CSS, a grid is the CSS grid, a place where they can define both columns and rows, assign areas to parts of the page etc.
In a "visual" grid, users have the columns as a visual aid, and I assume there will be some sort of snap-to-grid functionality.
In a CSS grid, users expect to be able to put their header on the left, the content on the right, and define what goes where not only vertically but also horizontally.
One does not exclude the other, but I'm still trying to understand what the purpose of the "site" block is from the above mockups.
If the purpose is to add the visual-columns aid, we can do that with an option without the need for a block/wrapper.
If however the purpose is to add a way for users to really structure their layouts, then we'll need a way for users to work on 2 axis, and build layouts that are not limited to header-on-top.

[beafialho]

Great exploration @jasmussen!

Those template parts can be aligned to the grid. This part spans the full 12 columns, but the Post Content block inside starts at column 4 and spans 6 columns:

I have one question: if I want to adjust the width of the _Post Content_, I can do so by clicking on the paragraph?

[jasmussen]

To a designer a grid is usually the vertical columns and their gaps. To someone writing CSS, a grid is the CSS grid, a place where they can define both columns and rows, assign areas to parts of the page etc.

Doing both, to me "grid" refers to the ability to align things on a page, both vertically but ideally also horizontally. The mockups shown here take a great deal of inspiration from the Layout Grid block which uses CSS grid to create column (and row) areas.

I have one question: if I want to adjust the width of the Post Content, I can do so by clicking on the paragraph?

Yes, the interface for selecting blocks should be mostly the same as it exists today. How to make that grid something blocks can snap to as it cascades down the levels is one of the things to think about.

Edit: I suppose if you clicked on the paragraph, you'd have to click the "select parent" button a few times to get to the Post Content block.

[beafialho]

Thanks. I do think the 'cascade' can be a bit confusing (that took me a while to figure out using the Layout Grid block) but still worth having as a customization option.

Would users also be able to edit the grid and define the column count, gutters and margins size, etc?

[aristath]

Ideally, a "site" block would help me do this:

Desktop:

        200px             1fr
      |-------------------------------------| -
      | Logo   | Breadcrumbs                | 3em
-     |        |----------------------------| -
200px |        |                            |
-     |--------| Content                    | -
auto  | Menu   |                            | auto
-     |--------|                            | -
      | Social |----------------------------| -
auto  |        | Footer Blocks              | 80px
-     |--------|----------------------------| -

-------------------------------------------------------
Mobile:

|-------------| -
| Logo        | 60px
|-------------| -
| Menu        |
|-------------|
| Breadcrumbs |
|-------------|
| Content     |
|-------------|
| Social      |
|-------------|
| Footer      |
|-------------|

When building a site, I'd need to be able to control things in both axis... And the current Layout Grid Block looks more like a glorified-columns block. It's beautifully and exquisitely done, but it's still just columns (unless I missed something while testing it?)

[jasmussen]

Going back to this comment which restarted the conversation, it de-emphasizez the "site" term in favor of calling it an "area", one implication seems to be that it might not be a be-all end-all layout building block, but more of a _provider of a grid_. In that vein, it might be up to the template parts and blocks inside how and whether to align to that grid.

So please take the Layout Grid block only as a basic example for how a layout grid can enable alignment across a page, not as a 1:1 comparison.

[jasmussen]

Would users also be able to edit the grid and define the column count, gutters and margins size, etc?

If the Site/Area block could provide a grid, then I think it would be up to the theme (perhaps user configurable in the site editor) to configure the gutters and margins. Probably column count too, but we'd need to be careful to make it as theme-switching friendly as possible.

[carlomanf]

I'm not a designer, so the "grid" stuff goes over my head, but seeing as this is being billed as a "root" block, I'm wondering if it would be responsible for rendering the doctype, calling wp_head, rendering a template and calling wp_footer? In other words, could the entire template loader and HTML document be relocated into the render_callback of this block? I'm thinking plugins could then replace this with their own version of a site block and be responsible for the HTML document if they want.