Meta boxes: update core styles to match Gutenberg's

[keoshi]

Description
Default meta boxes in Gutenberg have a different style than other components.

The out-of-date styles are coming from here: https://github.com/WordPress/gutenberg/blob/3d3c2a4d52903131f68d2694bd551408561fa778/packages/edit-post/src/components/meta-boxes/meta-boxes-area/style.scss

To Reproduce
Steps to reproduce the behavior:

1. Install Jetpack and/or ACF.
2. Go to Posts > Add New
3. Notice:

• Sharing meta box in the sidebar
• ACF meta box

Expected behavior
To have all components styled equally and consistently.

Screenshots

Desktop:

• MacOS Version 10.14 (18A391)
• Chrome Version 70.0.3538.102 (Official Build) (64-bit)

Additional context

• Gutenberg Version 4.4.0
• WordPress Version 4.9.8
• Jetpack Version 6.7

[designsimply]

I tested with WordPress 4.9.8, Gutenberg 4.4, Jetpack 6.7, Advanced Custom Fields 5.7.7, and Yoast SEO 9.1 using Firefox 63.0.1 on macOS 10.13.6 and found that the Sharing panel in the sidebar added by Jetpack is not styled the same as the other sidebar panels—the heading is lighter and it appears to be a ver slightly larger font size.

^{Seen at https://tan-otter.jurassic.ninja/wp-admin/post-new.php running WordPress 4.9.8 and Gutenberg 4.4 using Firefox 63.0.1 on macOS 10.13.6.}

I am not sure whether this is intentional for the sidebar panel and I am also not sure what the expected styling for meta boxes below the content area should be. @keoshi are you saying that the styling for the default meta boxes below the content area should exactly match the styling of the sidebar panels?

[keoshi]

@designsimply I would expect all elements on this screen that share the same behavior (expandable/collapsable panels) to also share the same styling (heading and icon).

Can you think of a scenario where this distinction would be a benefit? Should meta boxes be represented differently depending on their location (sidebar vs below the content)?

[karmatosed]

I think it should be styled the same and if coming from Gutenberg we should make sure it is. Let's put this to 5.0.1 to make sure styling isn't being adjusted.

[jasmussen]

Although I agree it would be so very very nice with consistency between these two, this is actually intentional. We actually tried doing this a while back, but ran into a plethora of issues with existing metaboxes; the fact that we are changing the box-sizing model is just one small example. You can see some of the challenges Yoast ran into here and here, and keep in mind Yoast has been developing their plugin in context of Gutenberg for well over a year to ensure compatibility. Consider the metaboxes that haven't yet.

So even though I do agree it would be nice with consistency, PHP metaboxes were designed and built in a context that relied on this particular CSS file to be loaded and present, and removing that CSS file can cause unintentional breakage in a number of ways. I really appreciate this ticket as an opportunity to discuss this, and it will be helpful for people searching as well, I'm tempted to close it as intentional. But for now I'm going to move it out of the milestone, as even if we were to revisit this discussion it would be too risky to do it as a .0.x update.

[keoshi]

@jasmussen Those are odd secondary effects for sure, but just thinking MVP here — does not changing the color of the metabox title/label and updating the arrow to a chevron improve this parity a lot, without breaking other things that are expected to work out of the box (no pun intended)?

[jasmussen]

Sure, and I think that's fair. But even for a 5.0.x release I'd be a little nervous about that. I may be shell-shocked from debugging the most obscure metabox error ever, but the point I'm concerned about is that the metabox in Gutenberg is based on bringing a very old API into a completely new context. What we have works reasonably well, but can definitely use a ton of improvement. I hope we can do that as a 5.1 thing, though, because at this point even small changes can have butterfly effects in the metabox implementation. For example we redesigned the checkbox in Gutenberg to have a more accessible checked state — I believe we tried, and ultimately failed, in letting that seep into the metaboxes.

[keoshi]

Oh yeah, totally. Not trying to get this fixed on the next release, was just asking to understand what a minimal solution might be. Thanks for all the context! :)

[youknowriad]

I added a "Good First Issue" label, Let's try to match the colors in a PR (I think the icons are impossible to match without hacky code) and consider the impacts.

[skorasaurus]

was reported at https://core.trac.wordpress.org/ticket/53194 ; referred reporter to here.

[stevenjcoates]

If this drives anyone as crazy as me here's some hacky admin css that almost makes the meta box styling match the Gutenberg panels by matching font size/colour/weight and swapping to different dashicons for the toggles.

.block-editor__container .edit-post-meta-boxes-area { border-bottom: 1px solid #e0e0e0;} .block-editor__container #poststuff .inside { margin-top: -6px !important; } .block-editor__container .postbox .handlediv .toggle-indicator::before { right:5px; font-size:15px !important; color:#1e1e1e; } .block-editor__container .meta-box-sortables .postbox.closed .handlediv .toggle-indicator::before { content: "\f347" !important; } .block-editor__container .meta-box-sortables .postbox .toggle-indicator::before { content: "\f343" !important; } #editor.block-editor__container .postbox > .postbox-header .hndle { font-size:13px; color:#1e1e1e; font-weight:500; }