Navigator and block generation Issues

[StrangeTech]

Hi @JulianM,

@JulianM

When you try to create several top level block wrappers or containers such as Sections, Divs and Containers, the default behavior is to generate them as a child items instead of duplicating them.

I have experienced what you are referring to and if I understand correctly you are saying you would like to insert a container block multiple times in a row and subsequent inserted blocks would be added within the same parent as the first item.

I can understand why this is desirable in that particular flow and there is something else to take into consideration.

Currently, one useful behaviour of the way blocks are inserted is - when you insert a container block, it automatically selects the inserted block. This allows you to quickly add child blocks to it. I believe this is the correct default behaviour because it makes sense to highlight the active block and in many cases when inserting a container block it is for the purpose of placing items within it, which this behaviour allows.

The change you propose would require when inserting a container, that its parent remains selected, which while it would enable the particular flow you described, it would not allow the one I described.

Perhaps this could be a nice opportunity for a feature request, something like if we shift click on an item in the inserter it adds it to the parent - this would give you the speed of flow while retaining the current default behaviour. Win-win.

@JulianM

This behavior reveals an issue with the navigator, of hiding the block navigator buttons behind the layout interface making it very difficult to interact with them, forcing me to narrow the layout to be able to reach the buttons and it is not good at all for a convenience and workflow.

This is a tricky one, because in a deeply nested layout, some blocks in the navigator may be indented so far that they are not visible at all.

Currently the two ways we can work with these are to resize the navigator width or horizontally scroll and I don’t see any other way to address that particular case.

Regarding the action buttons that appear on hover, for visible blocks in the navigator, it may be possible to argue the position of the buttons could be fixed to the right of the visible portion of the block it is in, but when the width of the visible portion of the block is shorter than the width of the buttons, this would still need to overflow somehow. Due to these considerations, I personally think it is implemented in the most practical way for the current navigator interface.

You may be interested in these threads:

Absolute positionned buttons on navigator panel hover

Hi, I don’t find the current navigator buttons display very handy: With a few nested blocks or long labels, buttons appearing on hover are partly hidden because they overflow the navigator panel. The only way to access the buttons is to scroll horizontally. [image] This becomes terrible when you need to delete a few blocks in a row because each time you delete a block, the scroll resets to the left Maybe limiting button width to panel width and displaying them with absolute position…

Improvement on Navigator

Hi! I have a suggestion for improvements to the navigator. Look at the screenshot. [image] In the area I pointed to with a red arrow, you will see that the delete icon on the element is outside the visible area. I have to scroll to the right to see it. *Scrolling to the left/right on the navigator is not a good UX experience. When I scroll to the right, I see this. [image] The right side of each element is not well aligned because of the nested elements. Feeling untidy. It would be gr…