<wp-inner-blocks> causes DOM differences between edit and frontend

[yscik]

The <wp-inner-blocks> wrapper being added implicitly on the frontend is something block authors might not expect. It's not added in the editor right now, so anything relying on the DOM tree needs to handle two versions. Most notably this is styles with relationship selectors.

For example, Sensei's Flashcard block uses a structure where the first and second child blocks are considered the front and back of the card, respectively:

&--flipped-front > *:nth-child(1),
&--flipped-back > *:nth-child(2) { ... }

This is likely an edge case and can be worked around, but making it consistent across editor and frontend could improve the developer experience.

[luisherranz]

Interesting.

I thought display: contents would solve all the CSS issues, but it doesn't work with nth-child: https://codepen.io/luisherranz/pen/WNzyMJW

[luisherranz]

making it consistent across editor and frontend could improve the developer experience.

@yscik: will adding <wp-inner-blocks> to the Edit component would be enough, or can it cause other issues?

[yscik]

On second thought, there are a few cases where having a wrapper is not desired, like HTML list and tables, and sometimes folks want to insert elements at the same level as the inner blocks. I think those were the reasons on introducing the useInnerBlocksProps API:

• Inner blocks: try hook approach
• Take more control over Inner Block Areas (as a block developer)

[luisherranz]

Ok. Thanks, Peter.

It seems like flex children could use display: contents, but for the rest of the cases, targeting the correct nodes still requires knowing that the wp-inner-block/slot exists in the hierarchy:

:is(wp-inner-blocks, div) > span:nth-child(2) {
  color: red;
}

codepen

Let's keep talking about the alternatives in:

• Children slots in client components #62

[luisherranz]

Coming back from #62, I think the solution for blocks (islands) can be different than for client components.

Blocks can't be nested, and they usually have a single wrapper node (although it doesn't seem to be mandatory). So I think the attribute approach could work:

<div class="wp-block-parent">
  <div>Some content</div>
  <div class="wp-block-child-1" wp-inner-block>Some child content</div>
  <div class="wp-block-child-2" wp-inner-block>More child content</div>
</div>

And instead of using:

document.querySelector("wp-inner-blocks");

We could use:

document.querySelectorAll("[wp-inner-block]");

The template selector (currently "template.wp-inner-blocks") that we use when the inner blocks are hidden doesn't change.

To avoid serializing or adding the attribute unnecessarily to the inner blocks of non-interactive blocks, we could do it dynamically with the upcoming WP_HTML_Walker:

if ( $is_this_block_interactive ) {
  $inner_blocks_html = '';
  foreach ( $block->inner_blocks as $inner_block ) {
    $html = new WP_HTML_Walker( $inner_block->render() );
    $html->next_tag(); // Find the first tag, which should be the wrapper.
    $html->set_attribute( "wp-inner-block" ); // Add the `wp-inner-block` attr.
    $inner_blocks_html .= string $html;
  }
}

And if we want to support multiple wrapper nodes (as long as they have the correct class):

EDIT: Not sure if this is feasible because:

• It'd have to rely on class names that start with wp-block but don't contain underscores (like wp-button__link) which seems fragile.
• It only works if we can apply it to the direct children's HTML. If not, the children's children's HTML will be incorrectly marked as well.

if ( $is_this_block_interactive ) {
  $inner_blocks_html = '';
  foreach ( $block->inner_blocks as $inner_block ) {
    $html = new WP_HTML_Walker( $inner_block->render() );
    while ( $html->next_tag() ) {
      $is_wrapper = $html->get_class( $block_classname ); // `get_class()` it is not implemented yet
      if ( $is_wrapper ) {
        $html->set_attribute( "wp-inner-block" ); // Add the `wp-inner-block` attr.
      }
    }
    $inner_blocks_html .= string $html;
  }
}

[luisherranz]

Closed as we're not actively working on this experiment anymore and this works fine in the Directives Hydration.