Allow Concept of Section Wrappers

I can definatly agree with adding this, either as another button next to "Add Section" e.g. "Add Section Wrapper", or as a option in the Choose Layout UI.

This could be done in contrib.

Override core/modules/layout_discovery/templates/layout.html.twig
Add "Wrap sections" link at the top of the form
Open up Settings Tray to select sections to wrap(or allow selecting via clicking sections)

I think it would be easier if core/modules/layout_discovery/templates/layout.html.twig didn't also render the

Personally I don't see a reason we shouldn't do this in the core Layout Builder, a lot of uses of Layout Builder in practice will be for building things like home pages, showcase pages, product pages, etc, where you want to have greater control over the styling and make them look pretty, so I think a lot of people would find this useful.

+1 for this. An alternative (much less flexible) would be to define custom layouts that have all possible combinations of rows/columns that you may need. You could have custom settings for that layout like adding CSS classes. If we had a way to group sections together and apply settings to the group as a whole that would great.

I'm not quite sure I understand how this can be done in contrib based on #3. Maybe it can be expanded on?

I haven't checked if this already exists but the idea occurred to me, in addition to this possibly adding theme hook suggestions for individual sections and section wrappers, so you could do some custom theming using template files for individual sections.

If it doesn't already exist I imagine it wouldn't be too hard to implement and could be a first step for this idea.

Just like what Block Style Plugins doing for block and section component, what we need is just a "Section style plugins" to configure CSS classes for section.

Ok I am not sure about description in #3 it was a while ago and things have changed in the module.

Now that #3027938: Abstract the contents of LayoutBuilderController into a render element and #2942661: Sections should have third-party settings have been committed this should actually be easier in contrib.

Since layout builder now uses a render element you can take advantage for #pre_render callbacks like this

/**
 * Implements hook_element_info_alter().
 */
function tester_element_info_alter(array &$info) {
  if (isset($info['layout_builder'])) {
    $info['layout_builder']['#pre_render'][] = '_tester_prerender_layout_builder';
  }
}

/**
 * Prerender callback for layout builder element.
 */
function _tester_prerender_layout_builder($element) {
  $element['layout_builder']['your_stuff'] = [
    '#markup' => 'your stuff here',
    '#weight' => -100000,
  ];
  return $element;
}

So something like

1. Use the above to create a link at the top of the layout builder that says "Group sections"
2. that link should open in the off-canvas dialog
3. The link opens a form to select sections to be group together(exclude any already grouped sections and only sections next to each to be grouped)
4. also in that form add whatever properties for the group
5. You would probably want to save your setting with this #2942661: Sections should have third-party settings. Though would have to choose a section to store info about grouping somehow and maybe others just say they belong to group
6. I am pretty sure on the rendering you would have to use hook_entity_view_alter to actually do the wrapping of sections.

Site builder isn't a gendered role :)

Ted's proposal in #10 seems viable. I just worked thru something similar yesterday to prove it could work. The biggest hurdle I ran into is that the render array that's built for the layout element is pretty large and complex. I wanted to insert a link above each section, alongside the existing "delete" and "configure" links. In my own pre_render function, I ended up with something like this, which seems a bit brittle.

function _layout_builder_styles_pre_render($element) {
  // Find all sections, and add a link before the section for assigning a style
  // to the section.
  /** @var \Drupal\layout_builder\SectionStorageInterface $sectionStorage */
  $sectionStorage = $element['#section_storage'];
  foreach (Element::children($element['layout_builder']) as $key) {
    // Check if this render element is for a section by checking if includes the section array.
    if (isset($element['layout_builder'][$key]['layout-builder__section'])) {
      // Extract the section delta from this attribute. This seems to be the only place we can get to it.
      $delta = $element['layout_builder'][$key]['layout-builder__section']['#attributes']['data-layout-delta'];

      // Add a new link for configuring styles for this section.
      // No easy way to control the position of this link so that it appears after the other links, but before the
      // the section div. Probably need to splice the array rather then manipulate #weight
      $element['layout_builder'][$key]['layout_builder_styles'] = [
        '#type' => 'link',
        '#title' => t('Configure styles for section <span class="visually-hidden">@section</span>', ['@section' => $delta + 1]),
        '#url' => Url::fromRoute('layout_builder_styles.configure_section_style', [
          'section_storage_type' => $sectionStorage->getStorageType(),
          'section_storage' => $sectionStorage->getStorageId(),
          'delta' => $delta,
        ]),
        '#attributes' => [
          'class' => [
            'use-ajax',
            'layout-builder__link',
            'layout-builder__link--styles',
          ],
          'data-dialog-type' => 'dialog',
          'data-dialog-renderer' => 'off_canvas',
        ],
      ];
    }
  }
  return $element;
}

Some thoughts on how this relates to accessibility, and the (in-progress) accessibility plan.

So far there have been some discussion about the UI for configuring section wrappers. A dedicated dialog, and the overview UI have both been suggested. What hasn't been considered yet is that we need to convey the mere presence of section wrappers to assistive tech users. You need to understand the layout you are starting from, before diving into dialogs to make changes :-)

One challenging aspect is that the section wrappers proposed here are optional - is that right? As things stand, the other levels are all mandatory; every block is in a region, and every region is in a section. So we know there are exactly 3 layers of hierarchy to each layout, and the current accessibility plan is working on that assumption. But if we introduce section layers as an optional aspect, then the hierarchy will sometimes be 4 levels, and sometimes be 3 levels. That complicates things, especially as the current accessibility plan involves heading levels for section/region/block.

Re. #15.1: the overview UI could indeed be a good place for this. However the overview UI needs more work. Last time I looked at it, there wasn't enough context available. Basically it needs more columns, so each thing's type (wrapper, section, region, block) can be explicitly stated. Tables work by cross-referencing row and column names. I'll try to get around to updating the overview-UI issue.

#15.2: nesting section wrappers will complicate the level hierarchy even more, so we end up having to convey a tree of unlimited depth. We already do this for tabledrag in the Menu UI, but FWIW I don't think the current Menu UI is easy to understand in a non-visual way. In any case, we'd also need a way to convey the nested section wrappers outside of the tabledrag dialogs. At least all the items in Menu UI are the same type (they're all links). Nesting section wrappers means we'd have a hierarchy involving different types: wrapper > wrapper > ... > section > region > block.

#16: Nesting layout sections is the same problem, but more extreme. Now we'd have a tree of unlimited depth, with the additional semantics of levels which alternate in type (i.e. section > region > section > region > ... > block). I've never seen an accessible pattern to convey that to assistive technology. All bets are off :-(

#3075939: Allow layouts to provide dynamic regions I'm bringing this proposition to your attention. It's much less invasive, and contrib modules then could easily implement configurable sublayouts/subsections which would be simply a part of section's configuration. It could solve this and other use cases, without messing with anything else, and is even BC.

I agree with Luke_Nuke that adding the functionality to have nested regions that it is better than having a "Section wrapper"

Could a Layout Builder maintainer clarify how this relates to #3053145: Allow layout builder sections to be nested.? 🙏