I can create a columns block without having to hack the container primitive UI (quanta toolbar with nested block support)

[djay]

Following from #3180

The current way selection in volto is done and the UI for the container primative gets in the way of creating some basic layout blocks such as a columns block.

@sneridagh Consider the following layout. Multiple vertical containers that can hold any of the basic block types. Ie a Grid > Column > Block.

My clients need to create things like this. EEA do too, that’s why they created eea volto-columns-block. It’s a fairly basic requirement I would guess.

One thing you haven’t answered is how the container primitive would work with this common columns scenario. How the UI would work without block developers have to remove the primitive UI and replace it with their own inconsistent versions?

Out of the box the container primitive would look like this as it is now.

I can only see three options

• Prevent any 2 level containment. Ie grid block is allowed but columns is not
• Give up on WYSIWYG and allow extra spacing/chrome around containers all at the same time. This prevents two different containers toolbars from being on top of each other.
• Go to a proper selection model where you only show overlays about the currently selected block and not it’s parents.

I remember the original discussions about containment in tokyo. I know albert thinks containment is an antipattern. You seem to be trying to stick to that idea of not dealing with containers yet wanting to create a universal container primitive at the same time. You can’t have it both ways. If you have a container then people will use it to make containers inside containers. This is unavoidable. Not dealing with this issue now will just create more problems later. You would be releasing a half baked solution and causing churn.

The current version on the container primitive means volto-columns-block would have to disable your container toolbar due to the overlapping toolbar issues I mentioned. Out of the box the container primitive would give them this.

Then they need to add in another way to insert and add in another way to navigate up the the parent container, like they had to do once already

And lhen later, once you get around to trying to solve this, which you will have to do eventually, they will then have to upgrade their block again with container primitive 2? We are going to have to do the same. And others too. You are creating a lot of work for other developers and an inconsistent user experience for end users. So I think for this reason trying to restrict containers to one level is also a bad idea.

I’d guess giving up on WYSIWYG is also out of the question. I believe it’s a core volto principle. Putting spacing/chrome/buttons around containers that make the items not appear how they would in the final version I believe is not the way to go.

So that only leaves showing chrome and overlays only on the current selected block (like every other WYSIWYG container based component editor I’ve found so far). Gutenburg may have iterated but that’s a good thing. We can take advantage of all their testing and not make the same mistakes.

However you don’t have to get this perfect now. You just have to provide a way that works regardless of how the containers are used so that block authors don’t have to remove your UI and replace it with their own.

What I’m suggesting is very close to the ideas in quanta (depending how you interpret it because it doesn’t deal with containers) and doesn’t change the current UI much.

The grid block toolbar is converted to a quanta toolbar “lite” that follows the block that is selected The key point is that it’s very clear what block is selected and the toolbar is contextual to the selected block. You aren’t showing a toolbar for the grid while you are working on a sub-block.

The toolbar doesn’t need slate merged in with yet or a context menu. Those can be done later. It doesn’t need the settings button as selecting the block will automatically do that. It just needs an add and delete and the “add” will always “add after” the current selection so the user experience is consistent.

• “add” will add a block below this grid block

• “add" will insert a new block after this text block. This is the most common thing you will want to do.
• I’ve left the outer containers having a border (but visually different) as you seem to prefer that (but I‘m personally not sure it adds much).

• “add” will insert a new column in the middle. (but you could also do this in the settings of the grid)

Because this is WYSIWYG and because containers might not have much padding to allow them to be clicked on superate from their contents there needs to be at least one other way of selecting a parent other than clicking. Gutenburg has 4 or 5 ways. We only need one to begin with. Again it doesn’t have to be perfect now.

You didn’t like having breadcrumbs in the side bar even though technically there is no reason it can’t be there but how about this instead?

but the gutenberg solution at the bottom of the screen is also good and could be added later (so can it’s outline view)

If you think the method to get to the parent is still too subtle another idea is the quanta toolbar could include a button that moves the selection to the parent. A kind of “back to parent” button. I’ve just noticed volto-columns-block has exactly this. So for grid scenarios you get something like this (not sure on the icon yet).

The add inserts a new column in the middle and “back” will select the parent grid block so you can adjust its settings.

You will probably say the add button doesn’t make it clear where the insert will take place even if it is consistent and I agree with you. But there is no reason another overlay can’t be used to show where it will be added if desired.

And clicking “back” we get to the grid block and can then add a new block to the page.

As you may have realised, the page is now a container so there is no inconsistency for how blocks work within the page vs how they work inside containers.

Maybe @avoinea and @tiberiuichim could add their thoughts?

[tiberiuichim]

@djay My interpretation of quanta toolbar is like this:

• At any single moment, exactly only one block toolbar shows up on screen
• This block toolbar is for the currently selected block or sub-block (if it's contained in another block)
• The block toolbar provides navigation to the container parent. It could also provide a limited set of controls for the parent block.

[djay]

@tiberiuichim great. so what I proposed is what you consider to be the quanta toolbar (except maybe the toolbar containing some controls on the parent block). And that's what you think we need in volto and it will replace the current container block UI and @davisagli top level only add button?

[sneridagh]

@djay @tiberiuichim

I told you the other day in the Grid PR, we all want the same, we want to reach to the same point, but since we are all in different positions, we just can't realise of it.

I'd say that we meet and talk about the subject, so all of us are in the same page afterwards and draw a plan to reach there.

Should we? I'm available in Discord during the rest of the afternoon/early evening.

[djay]

@sneridagh my summary of the meeting is

• Elementor takes a different approach by using dnd to create new blocks and right click context menu for everything else. That means no on screen toolbar is needed. This is actually similar to mosaic except that elementor still has explicit container blocks. It does seem to have a small toolbar for the parent container, can't remember why.
• pretty much in agreement that quanta toolbar was intended to work in the way outlined where it always follows the selection and gutenburg way is most similar.
• discussed that text blocks shouldn't have the same boxed selection line that container or other blocks might need
• The problem is that the current architecture of selections makes it hard to achieve a quanta toolbar appearing next to the current block. All parent containers think they are selected and the individual block is responsible for rendering itself as selected rather than being a generic framework thing. What would be needed instead is for the framework to be adjusted so containers are responsible for rendering the toolbar and selection and they know if the block is directly selected or one if it's decedents is. Need to investigate if this can be achieved without breaking the block apis.
• but It would be possible to at least hide the container toolbar if whats selected is another container so at least they don't overlap.
• the idea of getting some kind of quanta toolbar lite into 17 was not considered and the whole thing is seen a big problem that needs to be solved at some future undermined point.

In terms of UI, I looked for the quanta toolbar mockups. They don't deal with containment so leave some questions open.

• the image there shows a add in the quanta toolbar https://github.com/plone/volto/issues/4206.
  • 
• but the figma mockups don't have this. they only have a global add at the bottom of the page and context menu insert before and after. They don't include what happens in a container or how to navigate container hierarchies.
  • 
  • 
• There is a blue selection which is a line for text blocks and a box for other blocks

I personally think that either an add button in the quanta toolbar or add at the edge of the current block is fine (probably the later) but not sure about the idea of "add" being always visible at the bottom of the page.

If you keep to the ideas of quanta you might get something like this?

however

• delete and add being too close together is not great. you might hit delete by mistake
• still don't like the delete icon being the same as the cancel icon. You might think it will just undo your changes not remove the whole block. It should be a trash can IMO. Also when put next to the add you can see they look similar.
• you also might run into issues with adding a column at the right of the page. similar to the problems with the current delete and drag buttons which can't be used on mobile
• I've taken out the parent container dotted lines as we agreed it doesn't add much but can experiment.

be interested to know @albertcasado thoughts.

CORRECTION: Looking at figma further the X is not meant to be delete. It's just used for images/videos to remove that image so you can replace it with another.

The quanta design doesn't provide a delete button. You would have to use the quanta toolbar context menu or the delete key. Which might be reasonable? I suspect the original design had the same idea for "add" to. No button, just context menu and "enter" key.

[djay]

Another question that remains open is where containment breadcrumbs might go and how to get to Page settings.

The mockups show you can no longer get to the page settings from the side bar but it's not clear how you get to the page settings actually.

The settings in toolbar either

• toggles the settings on/off
• always goes to the page settings

if it's a toggle then that means you need a way to select the document itself to get to the document settings since there doesn't seem to be another way provided?

However this shows that you can still get to the page settings without unselecting the current block. It's also won't be obvious this is how you get to page setting. So there has to be another way to get to the page settings?

if the toolbar settings button always goes to the page settings, then you will need another way to show the settings for a block if you decide to close it. Maybe the settings button in the block context menu is meant to be the way to do that? or open page settings and then click around changing the selection?

Either way I think the design could add an additional way which is to turn the block type name in the settings into a dropdown of containers going all the way to the page level. Doesn't change the design much and does provide another way to select parents.

The gutenburg container breadcrumbs at the bottom of the page still has an advantage that it can tell you the containers you are looking at without clicking anything so it would be a nice addition later on

[tiberiuichim]

@djay In Volto the sidebar tab automatically switches to content settings when you select a title or text block (it's configurable in each block config, the sidebar index). So the text block can show the page settings and any other block can show its own settings.

[djay]

@tiberiuichim text block has settings in the verison I use. But this was more a question about how its supposed to work in the quanta design which doesn't have tabs in the sidebar. if the solution to how to access the page settings is knowing to click on a text block, I'm not sure thats a great solution :( you'd need another more obvious way.

[rotavio]

Here in out company we use Plone in several projects and we are doing some tests with Plone 6 and Volto. One major need we have is to add multiple blocks inside the same column of a grid, which is currently not possible. I've tried to create a Group block using the Container primitive, setting its direction prop to "vertical", but it didn't work. Is this implemented yet? Is there any example of a vertical container?

[tiberiuichim]

@rotavio

While they're not based on the code in Volto (they predate it and they were the "source" for extracting the BlocksForm component from Volto, check https://github.com/eea/volto-group-block

There's more of them https://github.com/collective/awesome-volto#layout-addons

[rotavio]

Thank you! We've tried some of their addons, tabs, columns, group and accordion, and are currently using them in our proof of concept. They are great, and work well, but we found their UI were not consistent between them. Also, they have this bug where you only get the "+" add button on text blocks. So, to add new blocks, you would have to select the last one, hit Enter to add a new text, click the add to open the Block chooser and then delete the text block. Also, some of them do not accept adding a new block outside and below it, there's no add button neither Enter works.

Also, we would rather use a native official solution, to avoid future upgrade problems and content migrations.

Are there any plans to add more features to the grid ro container blocks?

The vertical prop for the container does not seem to work. Is this by design, a bug, or something that I've missed?

We have two big projects due to the next months, but the limited layout builder in Volto is currently keeping us on older Plone versions.

[djay]

The current sticking point is that the internal architecture on how selection works is centred on the block itself recognising when it's selected. Whereas the kind UI discussed above needs containers to be in control of selection. The thinking is we need to rehaul the internal APIs to make this possible. We do have an idea how we can achieve this within the current architecture and will be doing a POC but have been a little busy. But even if that POC works, it wouldn't get into 17 so still might require some time to be useful. We do however use eea.columns in production. And grids. It is inconsistent but it works.