Some buttons inherit font-size from styles coming from add_theme_support( 'editor-styles' )

[laurelfulford]

Describe the bug
Some buttons in the editor can pick up font sizes from a theme's classic editor styles, when they're pulled into to the new editor using add_theme_support( 'editor-styles' ).

Twenty Seventeen sets a font size for button in its editor-style.css, which is being picked up by some of the editing tools in the editor -- so far that includes upload buttons in media-based blocks (like Image and Gallery), and the editing buttons in reusable blocks. It might affect more than that, but it doesn't affect all buttons -- for example, when you edit the Permalink, the button there is fine.

It is something that can be fixed in the theme, but it seems better to try to protect against that in Gutenberg with more specific selectors, if possible.

This issue is similar to #11132 and #11503; @afercia spotted it when reviewing changes to Twenty Seventeen, here: https://core.trac.wordpress.org/ticket/45246#comment:4

To Reproduce
Steps to reproduce the behavior:

1. Switch a test site to use the version of Twenty Seventeen in the WordPress 5.0 beta.
2. Add an image block, and note the size of the buttons.
3. Create a reusable block, and note the size of the buttons.

Expected behavior
The buttons should still use the 13px font size, like they do in other areas of the editor, but they're picking up the 16px font size from the theme.

Screenshots

Additional context
I can recreate this using the Gutenberg 4.2 RC; it's also present in the master branch as of commit c8b4679.

[m-e-h]

A mentioned in #10178
This is what we're fighting here:

Any theme style property added to an html element that hasn't been used already to style an editor component will style the editor component.

The qualifier [class], .editor-styles-wrapper that's added with add_theme_support( 'editor-styles' ) compounds this issue because now element styles from the theme are given greater specificity and will override editor component styles applied to single classes like .components-button.

Now we're fighting this

.editor-styles-wrapper a,
.editor-styles-wrapper input, 
.editor-styles-wrapper select, 
.editor-styles-wrapper textarea, 
.editor-styles-wrapper button

We've got to figure out a way to make all the editor components immutable to html element styles.

[chrisvanpatten]

@laurelfulford Is this a version of #10178? Would love to consolidate, if so :)

[timelsass]

+1 this is very frustrating in the current state. Form fields have also been an area of conflict when testing various other themes with Gutenberg in terms of css conflicts. Another area that has been frustrating is that a lot of content I have uses .button-primary and .button-secondary. Previously the styles were fine as they were isolated in the classic editor, but in gutenberg they now inherit a lot of stuff from the admin button styles, and the gutenberg interface gets all sorts of random stuff from themes.

For example:

and #11474

@m-e-h had mentioned:

We've got to figure out a way to make all the editor components immutable to html element styles.

I agree - it's the job of a theme to style all of the base components that create the presentation, which means the known and unknown, and the way that's usually handled is from the basic elements that make up a page. Forms, buttons, p, h1-6, etc etc. For a true wysiwyg experience, I don't see anything useful coming out of finding a way around having the content and styles isolated that would make sense to designers and other developers. The solution now of prefixing styles sorta works and given more and more priorities of things it's going to become more and more problematic, and it feels more like trying to quick-fix the issue than to actually resolve it.

I know in testing people tend to use the same test theme, or something like 2019 which is very lightweight in comparison to a lot of other themes styles. I've been testing the editor styles on various bootstrap, foundation, and heavily customized _s themes and have not really encountered one where everything just works and looks right in gutenberg after enqueuing all the theme's stylesheets into the gutenberg editor, but they all were 100% wysiwyg after enqueuing the styles in the classic editor.

I don't know much about the overall design structure behind gutenberg right now, but it really seems like isolation of the content in to the shadowdom is the right solution, or at the very least an iframe. I think the customizer is a great place for inspiration in terms of the iframe approach. It has a solid api for communication between the preview/previewer contexts, and having a similar approach between the editor and customizer would make integration of these two feature more seamless in the future.

As a note I was playing around with wildhoney/ReactShadow earlier inside of some blocks, which might be a useful library to reference if it goes that route.

Just wanted to give my 2 cents on the topic, as I see a lot of these nuances keep popping up.

[laurelfulford]

Is this a version of #10178? Would love to consolidate, if so :)

@chrisvanpatten Yes! It's the exact same underlying issue. I'm happy to move the details from this one over there -- I just didn't want to muddy things too much :) Just let me know!

[chrisvanpatten]

@laurelfulford That'd be awesome, thanks! 🙌

[laurelfulford]

Sure thing, @chrisvanpatten! I left a brief comment in #10178 about this specific issue (it already covers the bulk of the information, so there wasn't a need for too much detail!). Closing this ticket to continue the work there :)