Jonas, what if you used nested blocks? The first level item would be that "grouping" thing.
Hi Bartosz!
Sorry for late response.
It's these things we liked to avoid in the project I was working on. We were trying to avoid complex structures, but in the end we had to do 9-11 content areas with different behaviours and background colors etc., as a bad workaround.
If we could group any sequential blocks into display/custom groups, we could handle this (like multiple blocks zebra striping) in a custom content area renderer. And the nice thing here is that the code for grouping is almost equal to visitor groups in UI.
So, I consider it more or less a missing feature, it would provide simplicity for editors and developers to make groupings (like multiple blocks zebra striping) in one content area.
Daniel, we wanted to use these too, for traditional display options, actually 3-4 widths in different conditions for desktop, tablet and mobile... I can tell you in more details in Slack later... ;)
So, to cut it short, we had multiple needs, so we needed to use all available functionality and would really love to group blocks like Visitor Groups in UI, but for a different purpose, for content grouping and different rendering, like "Gray background" or something other solution specific grouping need... And the current functionality didn't meet our needs, so the least ugly, ugly solution, was to do 11 content areas to allow grouping, but that has the limits of how many content areas we actually coded... ;)
I combined my solution for controlling display options per block https://world.episerver.com/blogs/scott-reed/dates/2018/4/controlling-episerver-display-options-via-a-custom-attribute/ with a custom ContentAreaRenderer and extra options that could be set as standard on a block to support different layout sizes, colours and options. It works well
There is needs for organizings blocks by grouping them within content areas, for different reasons, mostly to comply with design. For example manual zebra striping or any more advanced stuff.
Since there already is visitor groups implemented the UI could be identical. The difference would be that you select a display group instead of visitor group.
The display groups (options) should be coded, not defined in admin or something, since it is a directive from the editor to the code on how to render — it’s a rendering contract so to speak.
Default behaviour for built-in renderer might be wrapper with display group as class name.
The group could be handled in custom content area renderers to enable using the group in the rendering process.
The content areas should be able to define which display groups is available for that content area.
Editor should be able to add as many groups they wish, one display group (option) could exist in more than one group in the same content area.
For now we have to do workarounds — but this would be the ideal solution of the needs we often see.