Tested style updates with ACF and Yoast. I've corrected any of the style issues related to this change within Gutenberg, however WP core is also using #poststuff in the style sheet. Currently, labels are displaying larger than they should be.

I'm not sure whether I should be overwriting core's styles whole cloth, or if this PR is something which should be reviewed later when Gutenberg is merged with core.

Thanks for the updates @gthayer This is way better. And yes, let's "copy" these styles to make them work with the new selectors and once we merge we'd have to remove the useless styles from Core.

Added the styles for improved metabox labels. I did some more testing with ACF and other metabox plugins, and found a few more issues.

#poststuff is being used commonly in plugins for styling and JS calls, notably ACF's map field was no longer working. I raised #poststuff to be higher in the DOM so it better wraps the meta content.

In an effort to reduce styling based on ID, I've switched #poststuff css calls to .postbox. However, core is still overwriting the styles because IDs have a higher priority than classes. I've added a #poststuff wrapper to the style sheet to make sure the correct styles are displaying, which can easily be removed at a later date.

Lastly, metabox inputs had a max-width of 300px. This was breaking the display of some plugins. I don't see where this was adding any value, so I removed it.

Moving the #poststuff class up higher in the hierarchy has caused CSS bleed into the editor:

While I can increase the specificity and even rewrite the CSS rules for headings, @mtias only just discovered the h2 heading receiving the new styles. There could be a bunch of other stuff cascading into the editor.

Do we actually need the poststuff class there, or is there a different way to apply it so that metaboxes can inherit those styles, but without them bleeding into the editor?

@jasmussen Unfortunately, we need it there because it has to contain all the meta boxes (content and sidebar) since we can't use an id twice. And this id is necessary for some meta boxes to work properly.

So if it's easy enough to override these styles, I think we should do it. If it takes a lot of time, we can revert this change temporarily while fixing those.

The problem is as soon as we start overwriting these styles with more specificty we are making it much harder for themes to supply their own styles. I really don't want to see #poststuff proliferate as a selector in ways we cannot easily undo.

Maybe we're fine with not valid HTML in this case? (instead of breaking meta boxes)

Is there a way we can find out how many, even ball-park, plugins that are affected by the previous configuration compared to this? And how hard would it be for those plugins to update to function in that configuration?

Would something like this work?

https://github.com/gthayer/gutenberg/commit/d35b16e3b4ae7342607a12f79a7eee998df59d12

This maintains the backwards compatibility for plugins, but "#poststuff" only wraps the metaboxs.

I did a quick search on one of my sites, and found that #poststuff is used by Gravity Forms, WooCommerce, ACF, and Jetpack.

@gthayer This doesn't take the "side" meta boxes into account.

Seems like it would be valuable to try and find out in slightly more detail what, specifically, metaboxes do with the #poststuff class. For example if we were to limit this class to only below-the-post metaboxes, how would that affect side metaboxes? Would there only be CSS issues?

I'm all for supporting metaboxes, but we have to try and find a balance between a clean and optimized codebase going forward, otherwise we are creating new technical debt.

Also CSS bleed in the Cover Image:

I think part of the problem is #poststuff has a very high position in the classic editor's DOM and plugins are using it align their styles and templates with core. It's not specific to metaboxes alone.

I've looked into a few flagship plugins I use, and the usage appears somewhat consistent.

Advanced Custom Fields

• Added as a wrapper to their options page
• Added to CSS as a wrapper for Post Box
• JavaScript events are initialized with #poststuff
• Note: The PRO version is less reliant on #poststuff

BuddyPress

• Added as a wrapper to their admin pages
• No specific styles or JS events I see

Gravity Forms

• Added as a wrapper for the entry details and results section
• Minimal styling for margins

Jetpack

• Added as a wrapper for the CSS Stylesheet Editor
• Margin and padding based style edits for CSS editor and publicize.

One more:

WooCommerce

• Added as wrapper for report admin pages
• Margin, padding, and border based style edits for sidebar metaboxes