Hi @Mamaduka, Thanks for the feedback! I’ve implemented all the updates — looking forward to your thoughts on the latest changes. Let me know if there’s anything else you'd like me to adjust!

@Sukhendu2002, please don't forget to mark PR as "Ready for review". Otherwise contributors might mistake it as "In Progress" work.

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Co-authored-by: Sukhendu2002 <sukhendu2002@git.wordpress.org>
Co-authored-by: Mamaduka <mamaduka@git.wordpress.org>
Co-authored-by: t-hamano <wildworks@git.wordpress.org>
Co-authored-by: skorasaurus <skorasaurus@git.wordpress.org>
Co-authored-by: carolinan <poena@git.wordpress.org>

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

Thanks for addressing the feedback, @Sukhendu2002!

It seems that failing mobile unit tests is caused by this change. Did you have time to investigate the problem?

Hi @Mamaduka, I'm not entirely sure, but it looks like HTMLElementControl might not be defined properly in the React Native context. Do you think we should:

• Add a platform check like !Platform.isNative && <HTMLElementControl /> to avoid rendering it in native?
• Create a separate edit.native.js implementation file?

What's your thoughts on this?

@Sukhendu2002, I think the new private component should also be listed in packages/block-editor/src/private-apis.native.js. I've not tested this, but I've seen similar resolutions in the past - #59632.

All the feedback appears to have been addressed. I'm going to merge this.

@Mamaduka Sorry for the late feedback here. I think it's overall a good implementation, there's just two things I've come across I'd like to mention:

The first one is probably a smaller one as it's a design issue, there's not enough space after the warning if there's a following element, same goes if there's no warning and just the select, there's also no space:

The second thing is, and I'm not sure if there's a solution for this: When I have a template, where the Content block is already in a Group with the HTML Tag set to main (like the Default Themes) and I have a block within my content that is set to main as well, the warning message does not show up when Show template is deactivated. I assume this is to what the check is iterating over. It also gets more confusing when the template is shown, because the surrounding group block around the content is not shown in the list view, despite it's there. I've made a ticket for this separate issue already: #67621

One suggestion for making it at least clearer to the user is to communicate that the template may contain the main tag as well. Otherwise people might look for it and are not able to find it, despite the warning is correct. I know this will bloat the warning message but I'm not sure if any other solution would bring more of an advantage.

When I have a template, where the Content block is already in a Group with the HTML Tag set to main (like the Default Themes) and I have a block within my content that is set to main as well, the warning message does not show up when Show template is deactivated.

Unfortunately, this would be hard to resolve. The editor only has details for the blocks that are rendered on the canvas. When "Show template" is deactivated, we can only check the post content blocks.

Maybe this is something we can improve by clear messaging.

there's not enough space after the warning if there's a following element, same goes if there's no warning and just the select, there's also no space:

I think this is because the HTMLElementControl component is not based on BaseControl. I think the following CSS is required:

diff --git a/packages/block-editor/src/components/block-inspector/style.scss b/packages/block-editor/src/components/block-inspector/style.scss
index dd9d8f254f..4913b4c5f8 100644
--- a/packages/block-editor/src/components/block-inspector/style.scss
+++ b/packages/block-editor/src/components/block-inspector/style.scss
@@ -11,7 +11,8 @@
        }
 
        .components-base-control,
-       .components-radio-control {
+       .components-radio-control,
+       .block-editor-html-element-control {
                &:where(:not(:last-child)) {
                        margin-bottom: $grid-unit-20;
                }
@@ -20,7 +21,8 @@
        // Reset unwanted margin-bottom from being applied to BaseControls within certain components.
        .components-focal-point-picker-control,
        .components-query-controls,
-       .components-range-control {
+       .components-range-control,
+       .block-editor-html-element-control {
                .components-base-control {
                        margin-bottom: 0;
                }
diff --git a/packages/block-editor/src/components/html-element-control/index.js b/packages/block-editor/src/components/html-element-control/index.js
index 3024301f19..a3dc68f7ee 100644
--- a/packages/block-editor/src/components/html-element-control/index.js
+++ b/packages/block-editor/src/components/html-element-control/index.js
@@ -86,7 +86,7 @@ export default function HTMLElementControl( {
        } );
 
        return (
-               <VStack spacing={ 2 }>
+               <VStack spacing={ 2 } className="block-editor-html-element-control">

Before	After

See #49520 (comment) for why such an approach is necessary.

Thanks @t-hamano — that makes a lot of sense. I'll start working on the fix!