Try Layout half image half vertical center content

[jorgefilipecosta]

Part of: #6993
This PR is a first draft to implement more advanced Layout blocks. The main objective is to discover what is lacking on the "engine" to make the creation of this blocks as simple as possible.
It shows how the usage of child-blocks + locking + allowedBlocks allows us to implement blocks that just make use of other blocks (like legos) (without having attributes or their specific logic).

Inside the block, we use columns to divide content in half. We could have done that with CSS and not use columns but I feel using columns is a better approach as it forces us to have a UI for layout blocks with other layout blocks inside working well. In the long term, I fell achieving layouts by nesting layout blocks inside other layout blocks is better than using CSS rules.

Improvements / changes needed:

The columns block CSS applies to grid styles not only to the first inner-area but all descendant inner-area. So if we have two columns and on the second one a block with InnerBlocks the inner blocks area will be 25% instead of 50% (50% set on the column * 50% set for the descend layout area). I used a CSS rule to avoid that for now, as this problem will probably get solved after we refactor column.

We may need a mechanism to allow to disable some settings from blocks when they are in nested contexts. E.g., the align option in the image still appear even though in this layout block they are not required. The result is not as wrong as I expected (screenshots available).

Blocks may take advantage of child blocks, to define subareas of the layout with specific prefilled blocks, specific locking levels, and/or specific allowed blocks. Child blocks may be used a lot and we may have complex trees of child blocks.
It may make sense to refactor registerBlockType to accept an object of { name, settings, children }. This makes developers life easier because with just one call to it is possible to register a complex tree of nested child blocks. Now we need to call a registerBlockType per child block we have.

For very simple blocks that just set an area for InnerBlocks ( with some settings for the InnerBlocks area ) like "core/half-image-content-area" it may make sense to provide a helper that generates the edit and save function or even all the block.

Screenshots

cc: @mtias, @karmatosed, @jasmussen

[jasmussen]

This has incredible potential. Holy guacamole. You get a medal: 🏅

😍

Here are some screenshots and gifs:

Summary: I love this, it feels like an extension of the placeholder concept which is incredibly powerful. That is — we can help designers put together glorious layouts and lock them, making it easier for editors elsewhere in the company to fill in the blanks, quickly, easily and with little friction. Or it can just help the small blogger create richer layouts without knowing HTML/CSS, which is the ultimate vision and goal for Gutenberg.

We need to do a few tweaks to the experience though, and I think the key here is to reduce the amount of blocks used to as few as possible.

Specifically:

1. If we can do without the columns block as nested inside the Half Image block, the entire thing becomes less fiddly. The columns slider doesn't seem to work well anyway, and I would guess it will add complexity to the responsive aspect anyway.

2. We should consider either not using too many child blocks inside, or locking them down further. The following isn't useful:

That is, the image block when inside the Half Image block doesn't need movers, or an ellipsis, or even alignment options. In fact it would better if those weren't there at all.

Similarly, it doesn't feel too helpful that there is a "Half Image > Content Area" child block on the right side. There is no interaction you can take on this child block, and the fact that it seems there should be (i.e there are movers and ellipses), just confuses.

Perhaps the solution is that we need to be able to limit options on child blocks. Something like "hasBlockUI" or something, which when false doesn't show hover or selection outlines, block toolbar, side UI. Just invisible, locked blocks that the user doesn't have to know about.

What do you think?

[ZebulanStanphill]

@jasmussen The responsive issue is something that needs to be tackled in the Columns block anyway, is it not? I think it would be unwise to launch Gutenberg with a Columns block that does not work responsively; even launching it with a Columns block that lacks non-equal-width columns seems like a bad idea.

The image block already does not have movers, unless you count drag-and-drop, which does not seem to currently respect locking. The alignment options in the Image block are definitely useless in this context, so I agree that they should be removed.

However, I think removing the ellipsis options is a bad idea. The ability to edit the Image block as HTML and convert it to a shared block would still be useful in this context. The Hide Block Settings option is the only one that seems unnecessary to me.

Then again, if this block is only intended for beginner/basic/quick-and-easy usage in page building, maybe it makes sense to limit options. What exactly is the intended usage of this block? @jorgefilipecosta

I can see that the Content Area block is being used to vertically align the contents. It may be desirable to allow for different vertical alignments, though perhaps those settings could be put on the parent Half Image block. If that is the case, then the UI for the Content Area block could potentially be removed without removing the ability for some handy customization options.

The Columns block should probably have all of its UI made invisible when nested in this block.

I think List blocks should be allowed inside the Content Area. They seem to fit in the same category as Headings and Paragraphs and I see no reason to prevent them from being used there.

What about the Custom HTML block? Should that be allowed here?

There could be 2 styles for the Half Image block: one with the image on the left, and the other with the image on the right. You could use CSS to re-order the columns and switch between styles using the upcoming style-switcher/transfrom UI. Actually, you could take this further and have multiple styles for 1/3 image and 2/3 content or 2/3 image and 1/3 content, assuming the Columns block was updated to support non-equal-width columns.

[jasmussen]

The responsive issue is something that needs to be tackled in the Columns block anyway, is it not? I think it would be unwise to launch Gutenberg with a Columns block that does not work responsively; even launching it with a Columns block that lacks non-equal-width columns seems like a bad idea.

For sure, and I imagine that responsiveness would entail collapsing to fewer columns at lower breakpoints, in editor and frontend both.

However I see the columns block as just that — a columns block. You want to create columns that behave as columns and use that as part of your layout. I don't see the columns block as being a base ingredient for layout — I would imagine we'd want a much more specialized block for that, one which surfaced more or other aspects of flex & grid.

Then again, if this block is only intended for beginner/basic/quick-and-easy usage in page building, maybe it makes sense to limit options. What exactly is the intended usage of this block?

I think using the term "beginner" does an injustice to how valuable a basic block like this could be. Left aligning an image with some text to the right of it is a very common pattern, and although you can do that by floating an image left and putting some text right, in some other very basic use cases (like an About Me card), you want subsequent blocks to clear. In cases like these a completely simple layout block like this — with no child blocks (or at least no visible child blocks) could be a major quality of life boon. Imagine you want a directory of employees on your company's about page. You insert a Columns block and make it responsive — 1 col on mobile, 2 on tablets, 3 on big desktops. You insert a bunch of "Text & Image" blocks, choose the configuration that has the image on the left and the text on the right, and you simply start filling out the placeholders. You could even have those card pre-made as filled-in shared blocks that you automatically insert as author cards at the end of posts.

Let's remember here that we're exploring a potentially core WordPress block, and just like a columns block needs to be responsive to graduate to core, so should a "Text & Image" block live up at least to the Gutenberg vision of making it easy for everyone to create rich layouts without knowing how to code. This is another way of saying that I expect a plethora of far more powerful blocks like this being created by plugin developers, and that's completely fine.

For that reason, I think it's important to pull waaaay back and keep this block as simple as possible. We want to avoid rebuilding Microsoft Frontpage — and for nested blocks I think it's especially important that we start to think long and hard about what child blocks we actually want to be manipulable, and what aspects are simply baked into the block itself. There is also the incoming improvement to the block variation interface — perhaps this block is literally just that, a "Text & Image" block, with a baked in image on the left and born with a Paragraph in a free-for-most content area on the right. Then variations could decide whether that image goes on the right, or above, or below, or pulled to the side.

The other aspect is — if you can remove every child block inside and be left with an empty container, then what is the purpose of the block in the first place, shouldn't that just be the "Section" block?

[ZebulanStanphill]

However I see the columns block as just that — a columns block. You want to create columns that behave as columns and use that as part of your layout. I don't see the columns block as being a base ingredient for layout — I would imagine we'd want a much more specialized block for that, one which surfaced more or other aspects of flex & grid.

This is a bit hard for me to understand, as basically every page builder plugin I know of uses the Section → Columns → Column → Module/Widget system in one form or another. Could you elaborate on what exactly you mean?

To me, a "Half Image" or "Text & Image" thing sounds more like a block template than a whole new block. See #6297 and how Divi implements this concept through the Divi Library, Global sections/rows/modules, and Selective Sync.

Depending on the implementation, you may even still be able to lock down blocks using a template system as opposed to a new block. There could even be an ellipsis menu option on the topmost block of the template to "unlock template" and enable all the borders, movers, and other UI for the contained child blocks, so you can have both simplified UI for basic situations, but also still be able to break out of the template later on if you decide to take existing content and change it in ways not allowed by the original template.

Including something like this as a block feels like it verges on the edge of being something that does not belong in core. How many options does this block have? Why is there a specific block for this specific layout situation? What other specialized layout blocks are there?

In terms of how this block works, there is the question of whether it is made up of existing blocks (hidden or not) or if it is more specialized, being a single block with nesting for the content area. I would think that from a modularity and DRY perspective, blocks like this should always be composed of existing blocks rather than built from scratch.

The other aspect is — if you can remove every child block inside and be left with an empty container, then what is the purpose of the block in the first place, shouldn't that just be the "Section" block?

Regardless of how the block works technically, I would have said that the Image block would be locked in position, and unable to be removed. However, it recently occurred to me that in some cases, you may want to have this sort of layout, but with a video on the side as opposed to an image. Would that be covered by this block? Would you be able to remove the Image block and insert a Video block there? What about the Embed block for things like YouTube videos? Where do you draw the line?

Side note: the Section block is now being called a Container block.

[karmatosed]

Lots of great thoughts here so going to dive right in.

I think it's a good point to consider responsive or adaptive when thinking about the columns block. Do we want to have set breakpoints or do we want to truly be fluid? It's a decision we have to consider.

I tend to agree with @jasmussen here, a columns block is just that. Right now it's being seem as more because it's a hint of blocks to come in phase two. That's when we get true layout blocks and forcing the columns block to be that today is something we need to be cautious about. That's not saying it's not useful, we just have to think of the context.

I absolutely agree we need to keep things as simple as possible. Whilst it's tempting to compare to other site building columns block this today isn't that. Could it grow into that, maybe but also maybe it doesn't. We shouldn't force it to be something it's not or rule out other approaches here.

[jasmussen]

Thanks again Zeb, your insights here are very much appreciated.

This is a bit hard for me to understand, as basically every page builder plugin I know of uses the Section → Columns → Column → Module/Widget system in one form or another. Could you elaborate on what exactly you mean?

I think it's too early to go full-on page-builder for Gutenberg. This is not to say it won't happen — there's a full-on customization focus coming up as Tammie alludes to. But also as she so eloquently puts it, it is perhaps too soon for Gutenberg to optimize for these behaviors simply because page builders do it.

It's entirely possible we'll come back to this as being truly the best way to do this, but for now I simply meant that there are many other ways to create layouts than grid-auto-columns — in the right context, a good old fashioned float might be a better choice.

Or maybe grid-auto-columns is the perfect choice, in which case that's fine to use. But in that case I'm not sure that actually surfacing the full-on block controls in the nested context actually makes things easier for the user, especially given some of the nested block challenges we have that you surfaced in the block breadcrumb thread.

To put it differently, as we are fast approaching a feature freeze for Gutenberg V1, if a block or blocks like that/those suggested in this PR has a chance to make it into the core offering, then we need an approach that is vastly simpler from a UI perspective. I note UI specifically because I will always defer to programmers on what the best approach is technically — if the best approach involves child blocks like the PR does now, then that's fine — but I think we should hide the UI from the user as right now it adds a ton of complexity and not a ton of value.

Did that clarify?

[ZebulanStanphill]

@jasmussen

Did that clarify?

Yes, thank you. I guess for an initial implementation, it makes sense to have things be more locked down, and open them up over time if necessary. I was a bit confused to see something like this block was being worked on right now since it feels like something from a page builder, but I think I understand the intent/purpose now.

[jorgefilipecosta]

Hi @SuperGeniusZeb ,

Then again, if this block is only intended for beginner/basic/quick-and-easy usage in page building, maybe it makes sense to limit options. What exactly is the intended usage of this block? @jorgefilipecosta

For now, my primary objective is to understand what needs to be polished on the engine to make this kind of layout blocks easy to create and allow them to provide a great UX for the user.

Thank you @jasmussen, @karmatosed and @SuperGeniusZeb for sharing your thoughts on this.

There is no interaction you can take on this child block and the fact that it seems there should be (i.e there are movers and ellipses), just confuses.

There are already PR's to correct movers/drag & drop behavior and they will not show up when they are not allowed.

The alignment options in the Image block are definitely useless in this context, so I agree that they should be removed.

I agree with this. To solve this I think we need an option in the engine that allows us to disable parts of the UI in blocks when they are nested inside some context. So we can disable alignment options of the image when it is nested inside the image area.

Similarly, it doesn't feel too helpful that there is a "Half Image > Content Area" child block on the right side. There is no interaction you can take on this child block, and the fact that it seems there should be (i.e there are movers and ellipses), just confuses.

I think we can address this with an option that allows blocks to be invisible e.g: make the UI behave as if the blocks were not there. No menus, hover, and it is impossible to select them. We can only select their children. It should be possible to set this option at the block registration level e.g: "Half Image > Content Area" would set it. And it should be possible to set the option from the parent block. E.g., we could use this option on columns, so we can make use of them, and we take advantage of the design they have and the CSS they provide, but they would be transparent, and the user would not notice them.

I would love to hear some thoughts on this possible engine features and if possible listen to some alternatives as this features look a little complex from the technical point of view.

[jorgefilipecosta]

Regardless of how the block works technically, I would have said that the Image block would be locked in position, and unable to be removed. However, it recently occurred to me that in some cases, you may want to have this sort of layout, but with a video on the side as opposed to an image. Would that be covered by this block? Would you be able to remove the Image block and insert a Video block there? What about the Embed block for things like YouTube videos? Where do you draw the line?

Nice point @SuperGeniusZeb I think we have three options to allow different blocks here.

• Make use of allowedBlocks and allow image, video, youtube etc... on the "image area". When a block exists, we set allowedBlocks to empty, so no more blocks can be inserted. The main disadvantage is that the user would be able to remove to block making this layout broken and the experience sub-optimal.

• Introduce the concept of a "Child Block Placeholder". Similar to media placeholder but with a plus sign, when pressed the sign would open the inserter (similar to the sibling inserter). Each time there are 0 child blocks this placeholder would be shown to fill the area. In the allowedBlocks, we would set image, videos, etc... Similar to the previous approach if a child block already exists we would set allowedBlock to empty so no more blocks can be added.

• Manage what block to use from the parent. E.g: A select box or a block style on the parent with Image, Video, Youtube etc... The main advantage is that we can disable the block removal and always have a block. The disadvantage is that we are not using the inserter to change the blocks.

[ZebulanStanphill]

I think block styles should be reserved for cosmetic changes, and using a select dropdown feels like it goes against the visual editing nature of Gutenberg somewhat, so I think the first 2 options are better.

When a block exists, we set allowedBlocks to empty, so no more blocks can be inserted.

Perhaps the locking API should be updated to allow for an area where only a single block is allowed to be inserted? Dynamically changing allowedBlocks sounds like a hack to me.

-> Introduce the concept of a "Child Block Placeholder". Similar to media placeholder but with a plus sign, when pressed the sign would open the inserter (similar to the sibling inserter). Each time there are 0 child blocks this placeholder would be shown to fill the area. In the allowedBlocks we would set image, videos, etc... Similar to the previous approach if a child block already exists we would set allowedBlock to empty so no more blocks can be added.

This sounds like a pretty interesting idea.

[jasmussen]

I agree with this. To solve this I think we need an option in the engine that allows us to disable parts of the UI in blocks when they are nested inside some context. So we can disable alignment options of the image when it is nested inside the image area.

and

I think we can address this with an option that allows blocks to be invisible e.g: make the UI behave as if the blocks were not there. No menus, hover, and it is impossible to select them. We can only select their children.

I like the sound of this. There will no doubt be some UI challenges, but it sounds right to me. The point is, if a user cannot interact with a particular aspect of a child block, the UI doesn't need to be there to confuse.

Zeb said:

you may want to have this sort of layout, but with a video on the side as opposed to an image

Jorge responded good point (I agree, it's solid):

Introduce the concept of a "Child Block Placeholder". Similar to media placeholder but with a plus sign, when pressed the sign would open the inserter (similar to the sibling inserter). Each time there are 0 child blocks this placeholder would be shown to fill the area. In the allowedBlocks, we would set image, videos, etc... Similar to the previous approach if a child block already exists we would set allowedBlock to empty so no more blocks can be added.

This seems like it could work — the gray fill of the placeholder block is to indicate "a big solid block goes here", kind of like in the good old days of graphic design and art direction, where you would draw a square with a cross in it to indicate "an image goes here" in a magazine layout.

If we had a placeholder block that was limited to media, including embeds, we could lock such a thing in place — perhaps it was a meta-placeholder block with the same gray background, which simply had a button in the center that said "Pick media block", and clicking it would open the same block type picker we're introducing with the new Switcher makeover.

Related: #2439

[jorgefilipecosta]

This PR was updated:

• We don't display align options on the image/other media blocks (right now via CSS, I will try to find a solution using an extensibility API).

• We introduce the concept of a child block placeholder. We now can use multiple media blocks at the side. I found some engine bugs namely we may trigger multi selection during the inserter. And an inserter items cache problem. After we remove a media block, we need to type in some other block to have the inserter button again.

• We don't make use of the columns block now. So we have less blocks in the UI.

The bugs/problems found will be addressed in different PR's, but I think we can already have some preliminary feedback and discuss the alternatives.

[ZebulanStanphill]

You know, without the align options on the Image, there is no way to make the image align to the right of the left half of the block, if you know what I mean. There is no way to center it, either.

As you can see, this image is stuck showing on the far left, with no way to make it align to the right or center, which may be something you want to do. Perhaps the align options should no longer be hidden for the Image block? Of course, floats are funky, so it would be nice if you could simply make the Image be aligned to the right without using floats.

The center alignment option should definitely be visible, though, since it does not use floats and therefore does not have any funkiness.

[ZebulanStanphill]

Also, you can still select/focus(?) the hidden blocks if you click in the right spot.

[ZebulanStanphill]

Also, whatever CSS you used to make the ellipsis menu appear in the right spot for some of the blocks may no longer be necessary if the ellipsis is moved to the block toolbar as proposed in #9074 and #9282.

[jasmussen]

Here's a GIF of latest developments:

I love this. This is too solid. It's muuuuch less complicated and it really starts to show the power of this system. Past feedback on too many container elements that you shouldn't interact with are moot. It will also be nice when the block ellipsis moves to the toolbar.

One note which Zeb above mentions too — when an image is small, or is resized, there's a lot of space. I think it's probably fine to not be able to center the image, that aspect doesn't really make that much sense in what is essentially a template block. But is it possible to make the media column scale to fit the contents inside? Notably if it's an image? I.e. if you insert a small image, you just get more space for the text?

[mtias]

I think we should probably not be using an image block on the left. It should be a media area and apply it through content-fit. So it always fits the container and you resize the container. It would also mean the image won't have its own resize handlers which would end up being confusing.

[jorgefilipecosta]

I think we should probably not be using an image block on the left. It should be a media area and apply it through content-fit. So it always fits the container and you resize the container. It would also mean the image won't have its own resize handlers which would end up being confusing.

Maybe not using the image block is our best option. Using the image block evolves much CSS fighting and I'm not sure if with the editor markup of the image block allows us to get the result we desire. Maybe the alternative is a new media block that provides image/videos etc... optimized for this nested iterations.
I would prefer to use our existing blocks, and I think it would be good to reuse them but the results seem suboptimal.

[ZebulanStanphill]

If this block used CSS Flex, that would make it easy to make the text content grow when you shrink the Image block, would it not? Just throwing ideas out there. It seems weird to me to create a media block specifically for nested situations.

[jorgefilipecosta]

Closing in favor of #9416.