Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

innerBlocks Component -> Essential markup differences -> Please Help! #29513

Closed
CreativeDive opened this issue Mar 3, 2021 · 4 comments
Closed
Labels
[Type] Question Questions about the design or development of the editor.

Comments

@CreativeDive
Copy link
Contributor

CreativeDive commented Mar 3, 2021

Hey together,

I have opened this issue, because by using the innerBlocks Component, adds essential markup differences to the block editor output. This is a real horror show for theme developers to get the same design result for both, frontend and backend (block editor).

I'm starting to describe this issue:

WordPress core blocks with inner Blocks

All WordPress core blocks, which including inner blocks, using the following markup. It's always the same scheme:

<div class="wp-block" data-align="full">

	<div data-type="core/cover" data-title="Cover" class="block-editor-block-list__block is-selected">

		<div class="wp-block-cover__inner-container block-editor-block-list__layout">

			<innerBlocks />

		</div>

	</div>

</div>
1. Level --> Alignment wrapper container [align = full / wide / center / left / right]
2. Level ----> The block container
3. Level ------> The block inner-container
4. Level --------> All inner blocks

This is the basic state of how WordPress builds blocks, including inner blocks in the case of the block editor.

Custom blocks with inner Blocks

Custom builded blocks, which including the inner blocks component, are totally different, to the basic state of the core blocks markup:

<div data-align="full" data-type="acf/my-custom-block" data-title="My custom Block" class="block-editor-block-list__block is-selected">

	<div class="wp-block" data-align="full">

		<div class="block-editor-inner-blocks">

			<div class="block-editor-block-list__layout">

				<innerBlocks />

			</div>

		</div>

	</div>

</div>
1. Level --> The block container
2. Level ----> Alignment wrapper container [align = full / wide / center / left / right]
3. Level ------> Another container (block-editor-inner-blocks)
4. Level --------> The block inner-container
5. Level ----------> All inner blocks

My feedback to the core blocks differences to custom builded blocks:

1. Level --> Contains an additional [data-align="full"] attribute, but not the core blocks) --> Why?
2. Level ----> Is positioned inside the block container. In the case of core block, this container wraps the block container. --> Why this is different?
3. Level ------> Why using an additional container / level here? Is that important?
4. Level --------> Why the "{block_name}____inner-container" class name is missing here?
5. Level ----------> Fine. Follows the basic state.

What does that mean?

You can see the order of the containers and the usage of the class names is totally different.

But the structure is actually exactly the same. No distinction is made here in the frontend either. But in the block editor everything is totally different.

I ask myself why? I have to say that it shouldn't be like that.

Why does this inconsistency have to be in the block editor? Why do I ask that?

Because it is very difficult for me as a theme developer to get the same design results for the frontend and backend.

I use some CSS rules to make dealing with nested (inner) blocks easier.

CSS rules like this:

[class*="__inner-container"] > .alignwide {
	...
}

However, these CSS rules cannot work in the block editor. Because the innerBlocks component has a completely different structure. But that shouldn't be the case.

I hope someone realizes this issues and will realize that if you want to design blocks for frontend and backend in the same way, it will always lead to frustration in the future.

Please find a uniform solution that makes sense.

@talldan
Copy link
Contributor

talldan commented Mar 4, 2021

@CreativeDive It looks like the custom block in your example might not be using the useBlockProps hook (https://make.wordpress.org/core/2020/11/18/block-api-version-2/).

For inner blocks there's also a useInnerBlocksProps hook that removes the extra wrapping element around inner blocks. This is experimental at the moment though and yet to be considered stable for public use, but is being used on core blocks to help test and stabilise things.

One of the goals of both those APIs is to make the editor markup as close as possible to the front-end markup, so should result in improved consistency.

@talldan talldan closed this as completed Mar 4, 2021
@talldan talldan added the [Type] Question Questions about the design or development of the editor. label Mar 4, 2021
@CreativeDive
Copy link
Contributor Author

@talldan this sounds good, but do you can explain it more exactly please?

There are not only additional and unnecessary containers. There are some more differents between the core blocks markup:

1. Level --> Contains an additional [data-align="full"] attribute, but not the core blocks) --> Why?
2. Level ----> Is positioned inside the block container. In the case of core block, this container wraps the block container. --> Why this is different?
3. Level ------> Why using an additional container / level here? Is that important?
4. Level --------> Why the "{block_name}____inner-container" class name is missing here?
5. Level ----------> Fine. Follows the basic state.

You are sure we can solve all this with using the useBlockProps hook from (https://make.wordpress.org/core/2020/11/18/block-api-version-2/)?

@talldan
Copy link
Contributor

talldan commented Mar 4, 2021

@CreativeDive useBlockProps combined with useInnerBlocksProps will you to have markup like you describe here:

1. Level --> Alignment wrapper container [align = full / wide / center / left / right]
2. Level ----> The block container
3. Level ------> The block inner-container
4. Level --------> All inner blocks

That seems like it's about as minimal as can be.

@CreativeDive
Copy link
Contributor Author

@talldan perfect! Thank you

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Type] Question Questions about the design or development of the editor.
Projects
None yet
Development

No branches or pull requests

2 participants