Description

This is still a work in progress as there are some final details to be figured out.

This is the final step in lightening the block DOM. This PR allows block types to opt in to rendering their own wrapper.

supports: {
   lightBlockWrapper: true,
}

Why?

• If a block type opts in, there is no longer a need for the getEditWrapperProps setting. Blocks can now apply the props themselves. The could be useful for e.g. alignment. A block can now set proper classes instead of data-align attributes, which will make it easier for themes to style the editor. Currently, for many themes, even the latest core theme, alignment in the editor doesn't reflect the alignment on the front-end.
• As we lighten the InnerBlocks DOM, it will be possible to build more complex block that need a semantic relationship with its child blocks. E.g. for a table and list block, the table cells and list items need to be direct children of the parent block, so these blocks need to render their own wrapper.
• This also means that complex nested blocks become much easier to style by themes as the element tree in the editor matches that of the front-end.

<div class="wp-block-columns">
  <div class="wp-block-column">
    <p>one</p>
  </div>
  <div class="wp-block-column">
    <p>two</p>
  </div>
</div>

The above is much nicer to handle than many layers of nested div elements.

I believe that allowing simple block markup in the editor will be essential for full site editing and theming.

• For blocks that opt in, it will get rid of the useless focusable wrapper element. For example, a paragraph block has currently two focusable elements: the wrapper and the paragraph. The focusable wrapper is useless here, and adds an extra tab stop. There's no reason for the paragraph not to be the wrapper.

Implementation notes

The way I'm approaching this is a bit inspired by react-spring. I created a base block component that is provided with the context it needs to render and the props that the block Edit component may pass. For every element that can act as a block wrapper, I created a wrapped component as properties of the base component, so you can have Block.p, Block.div, Block.figure etc.

This works well together with RichText too. You can pass the component through the tagName props, and RichText will render the wrapper.

How has this been tested?

Screenshots

Types of changes

Checklist:

• My code is tested.
• My code follows the WordPress code style.
• My code follows the accessibility standards.
• My code has proper inline documentation.
• I've included developer documentation if appropriate.
• I've updated all React Native files affected by any refactorings/renamings in this PR. .