Feature: child blocks

[bastianallgeier]

This is complicated but would be fantastic for anything like nested lists, images within list items, etc.

[nilshoerrmann]

I think this would be very helpful for blocks extensions as well because having nested blocks allowed for easier content wrapping. Think of a question/answer block extension where each question and each answer should be wrapped in a div: having nested blocks would make it easy to let the answer have multiple paragraphs etc.

From an input point of view, for a block with child blocks enabaled, I could imagine to use one return to add new children and two returns to exit the nested structure and continue with a new block on the main level.

[nilshoerrmann]

Question: Are nested blocks something you consider complex but doable in the near future or is this something that might not be possible for a long time?

[luxlogica]

We often do article page layouts, where the body content is broken down into sections (blocks) that vary in the number of columns, and their content type. For example: At the top of the article, we might have a simple, full-width text block. Below that, we might have a 2-column block with an image on one side, and an aside (blockquote) on the other. Then, we might have 3 columns of text.

Right now, we either have to use the Structure field or the Builder plugin to enable the user to build this kind of layout: the user creates a new 'block', then selects the number of columns (1, 2, or 3), and then selects the type of content for each column ('text', 'image', 'aside'). TBH, the existing solutions are not elegant - and are sometimes buggy.

The Builder plugin has caveats, specially when building 'nested' layouts like this, where we might need one builder inside another. The 'preview' functionality can get really complicated, as the builder interface itself takes up a lot of screen real-estate - the preview ends up looking 'clogged' and nothing like the actual layout on the page. The overall experience of constantly switching between a 'preview' that doesn't really work well, and a crowded editing interface that feels unintuitive, is less-than-optimal.

The Structure field solution has its own problems - e.g., 'blocks' are listed in a table, and the client can never see the entire content at once in the Panel. It also requires us to create 9 fields for each 'block', and then use 'when' options to show/hide them in the interface - content files are a mess.

The Editor could easily handle this use-case, if child-blocks - or 'parent-blocks' - were implemented. In order to cover the widest amount of use-cases possible, I would suggest the following:

• first, implement options for custom class & ids for all blocks, as suggested in Issue #28.
• then, create a new block type, the 'parent block', which is just an empty container for other blocks
  • parent blocks can also have class and id, like all other blocks
  • we should be able to specify (on blueprint) min/max limits on number of child blocks
  • we should be able to specify (on blueprint) TYPE of child blocs allowed (e.g., paragraph, but not h1/h2/h3)

Visually, there are many unobtrusive ways to show the 'parent block' within the Editor:

• it can be displayed with a slightly different shaded background, and the child blocks slightly indented
• it can be indicated just with a subtle border around the children, and a clickable icon to display the configuration options
• it can be shown as a thick, clickable 'bar' along the left-side of the child blocks

At the template level, the 'parent block' would be output as a div containing the child blocks - or, if wanted, options could be given to the developer to use an arbitrary element (e.g. by setting an option in the parent block settings, by passing a parameter to the blocks() method, or perhaps with a blueprint option for the Editor field.

This might also cover the suggestion in Issue #38.