editor-styles-wrapper effecting previews in the components panel

[m-e-h]

To Reproduce
Steps to reproduce the behavior:
1.Create a button in Twenty Seventeen from the WP 5.0 Branch
2. Checkout the button preview

Cause
This: https://github.com/WordPress/WordPress/blob/5.0-branch/wp-content/themes/twentyseventeen/assets/css/editor-blocks.css#L724

And this: https://github.com/WordPress/WordPress/blob/5.0-branch/wp-content/themes/twentyseventeen/assets/css/editor-style.css#L27

Desktop (please complete the following information):

• Ubuntu 18.04
• Browser Firefox

Additional context

• Gutenberg 4.4

[m-e-h]

Twenty Sixteen too.

Also because of body margins.

[designsimply]

Noting to test these but also I think theme-specific issues should go to each theme's respective repository. I'll look into it!

[m-e-h]

I think this is more of an issue with the editor-styles-wrapper than any specific theme. It's only an issue with these two themes because their design adds margins to the body. It could easily be an issue with any other themes body styles as well.

Twenty Seventeen has this:

body {
	background-color: #fff;
	color: #333;
	margin: 20px 40px;
	max-width: 580px;
}

Which after the editor-styles thing mutates the selectors, it becomes this:

.editor-styles-wrapper {
	background-color: #fff;
	color: #333;
	margin: 20px 40px;
	max-width: 580px;
}

This interferes with the button preview because the editor-styles-wrapper class is actually being added to a div that wraps the button in the components-panel.

[m-e-h]

Here you can see the issue as I toggle the body margins on the .editor-styles-wrapper

[m-e-h]

Not exclusive to buttons #12066 (comment)

[jasmussen]

Thanks for the ticket, but can you help me understand exactly what the issue is? I realize there's additional margin on items in the preview, and prior to the pullquote gap I just fixed, there was a white gap in the right side. However the presence of the editor style wrapper in the preview is intentional, insofar as the items in the preview should inherit styles that the theme provides. The bug is not obvious to me (though forgive me if it should be, I've just had a sick kid for the past week so I'm slightly zombified).

[m-e-h]

I feel your pain @jasmussen . Having a sick kid is the worst!

The issue here boils down to user styles being injected into the components-panel.
This is done when we map the user's body styles to the .editor-styles-wrapper.
So this is only an issue if they add_theme_support(editor-styles).

In this case Twenty Seventeen from the 5.0 branch has margin: 20px 40px on the body so now they also have margin: 20px 40px on .editor-styles-wrapper which is squeezing the button out of the window.
Combine that with the body{background-color: #fff} and the margin-top: 2em that Twenty Seventeen has on the Button itself, and you've got a little white rectangle hovering over the button and causing the gap you were seeing in the box-shadow border.

Hope that makes sense.
A quick band-aid for this particular case and probably others would be:

.components-panel .wp-block-button__link {
    margin: 0;
}

.components-panel .editor-styles-wrapper {
    margin: 0;
}

But we should probably be more anticipatory of other common body styles that may break the preview.
Something like this:

.components-panel .editor-styles-wrapper {
    margin: 0;
    padding: 0;
    overflow: visible;
    min-height: auto;
}

I'm not going to beat my drum about #10178 anymore but I honestly thing we need to be doing more defensive coding. Mixing user styles with app styles can quickly turn into a game of whack-a-mole.

[jasmussen]

Thank you for the clarification. I didn't mean for you to stop beating that drum, I think it's an important one, and with your clarifications even more-so.

I suppose in light of that additional information, I still think that we should consider editor styles to b in their infancy and be be mindful with how far we're trying to go with them. However the purpose of doing this is exactly so tickets like yours can be raised and addressed as we continue to refine and improve the situation.

For example, I think Shadow DOM has huge potential here. Sadly it's not widely supported: https://caniuse.com/#feat=shadowdom

Element queries, similarly, will go a long way, but those are also not well supported and the polyfill isn't compatible with react and modern JS frameworks.

Finally, CSS display: contents; can probably go farther than any single other thing in improving the situation. https://css-tricks.com/get-ready-for-display-contents/

[jasmussen]

Submitted #12212 to potentially fix this.