Gutenberg: Hook to Deregister or Dequeue editor-styles.css that's CSS is inlined in admin head

Created on 19 Nov 2019  路  15Comments  路  Source: WordPress/gutenberg

Why is there no way to disable the editor-style.css file that gets inlined in the admin in Gutenberg?

That stylesheet (shown below) adds font sizing in ems, and line-height changes to the core CSS for headings and other elements in the backend, that makes it difficult to match the CSS on the frontend--especially for theme developers like us who are trying to make a block plugin work with most themes.

The only way I've found to reliably get the editor-style.css from inlining itself to the Gutenberg edit screens is to manually delete the contents of the file. No method I have found on Stack Overflow or in here on Github seem to show how to remove that inline styling that comes from editor-style.css from the wp-includes folder.

Our theme has declared custom admin editor styles in its setup, and we have also defined a custom admin stylesheet file that enqueues properly to enqueue_block_editor_assets, but for some reason the editor-style.css is still inlined to the admin head, and it interferes in font stylings and line-heights even if you overwrite them with more specific CSS.

If you're using ems in your font sizes, then having other line-heights and font-sizes defined before your CSS causes conflicts on the back/frontend. Outside of writing a ton of extra CSS to compensate in the backend for these inlined styles, is there any other way to tell WP to not load those core styles in the backend when declaring admin custom editor support?

Why is there no hook or way to declare an admin stylesheet, but not to remove the core Gutenberg style that just interferes with styling?

This CSS is what's causing most of our minor display issues, and it comes from wp-includes/css/dist/editor/editor-styles.css and you can't remove it:

`/**

  • Colors
    /
    /
    *
  • Breakpoints & Media Queries
    /
    /
    *
  • Often re-used variables
    /
    /
    *
  • Breakpoint mixins
    /
    /
    *
  • Long content fade mixin
    *
  • Creates a fading overlay to signify that the content is longer
  • than the space allows.
    /
    /
    *
  • Button states and focus styles
    /
    /
    *
  • Applies editor left position to the selector passed as argument
    /
    /
    *
  • Applies editor right position to the selector passed as argument
    /
    /
    *
  • Styles that are reused verbatim in a few places
    /
    /
    *
  • Allows users to opt-out of animations via OS-level preferences.
    /
    /
    *
  • Reset default styles for JavaScript UI based pages.
  • This is a WP-admin agnostic reset
    /
    /
    *
  • Reset the WP Admin page styles for Gutenberg-like pages.
    /
    /
    *
  • Editor Normalization Styles
    *
  • These are only output in the editor, but styles here are prefixed .editor-styles-wrapper and affect the theming
  • of the editor by themes.
  • Why do these exist? Why not rely on browser defaults?
  • These styles are necessary so long as CSS can bleed from the wp-admin into the editing canvas itself.
  • Let's continue working to refactor these away, whether through Shadow DOM or better scoping of upstream styles.
    */
    body {
    font-family: "Noto Serif", serif;
    font-size: 16px;
    line-height: 1.8;
    color: #191e23;
    }

/* Headings */
h1 {
font-size: 2.44em;
}

h2 {
font-size: 1.95em;
}

h3 {
font-size: 1.56em;
}

h4 {
font-size: 1.25em;
}

h5 {
font-size: 1em;
}

h6 {
font-size: 0.8em;
}

h1,
h2,
h3 {
line-height: 1.4;
}

h4 {
line-height: 1.5;
}

h1 {
margin-top: 0.67em;
margin-bottom: 0.67em;
}

h2 {
margin-top: 0.83em;
margin-bottom: 0.83em;
}

h3 {
margin-top: 1em;
margin-bottom: 1em;
}

h4 {
margin-top: 1.33em;
margin-bottom: 1.33em;
}

h5 {
margin-top: 1.67em;
margin-bottom: 1.67em;
}

h6 {
margin-top: 2.33em;
margin-bottom: 2.33em;
}

h1,
h2,
h3,
h4,
h5,
h6 {
color: inherit;
}

p {
font-size: inherit;
line-height: inherit;
margin-top: 28px;
margin-bottom: 28px;
}

ul,
ol {
margin-bottom: 28px;
padding: inherit;
}

ul ul,
ul ol,
ol ul,
ol ol {
margin-bottom: 0;
}

ul li,
ol li {
margin-bottom: initial;
}

ul {
list-style-type: disc;
}

ol {
list-style-type: decimal;
}

ul ul,
ol ul {
list-style-type: circle;
}`

[Type] Help Request

Most helpful comment

FYI, I'm using the block_editor_settings filter to remove the ['styles'][0] key which holds the inline styles. I'm not sure if this is safe or not.

add_filter('block_editor_settings', function ($editor_settings, $post) {
              unset($editor_settings['styles'][0]);

              return $editor_settings;
          }
);

All 15 comments

Hi There! Gutenberg needs a default editor styles to look/work properly. If you want to remove it, just enqueue an empty stylesheet in your editor styles by calling this function https://developer.wordpress.org/reference/functions/add_editor_style/ with a link to an empty stylesheet.

If you want to remove it, just enqueue an empty stylesheet in your editor styles by calling this function https://developer.wordpress.org/reference/functions/add_editor_style/ with a link to an empty stylesheet.

FYI, this doesn't work. I have an add_editor_style with a hook into after_setup_theme with the following and I it doesn't enqueue the empty stylesheet I have in my theme core, and it still loads that inlined editor-style.css into the backend footer...

So that method doesn't work.

I've tried a few different hooks trying to add my blank editor style and none of them seem to work properly with Gutenberg, and those default styles are still inlined despite me having them in another CSS sheet that's enqueued with enqueue_block_editor_assets

I guess I don't understand why there isn't a simple way to just remove these inlined styles somehow with a filter or something. Otherwise, you have inlined styles on core HTML elements that make it hard on theme developers to match up the aesthetics on the frontend/backend.

This issue is even more apparent if you attempt to use relative font sizes coming from a plugin that has to work with multiple themes as we are trying to do.

Any other ideas?

Did you enable the editor styles support:

add_theme_support('editor-styles');

See https://developer.wordpress.org/block-editor/developers/themes/theme-support/#editor-styles

Did you enable the editor styles support:

add_theme_support('editor-styles');

See https://developer.wordpress.org/block-editor/developers/themes/theme-support/#editor-styles

Sure did--this is hooked into after_setup_theme in a function:

`

    // Check and setup theme default settings.
    c9_setup_theme_default_settings();

    add_theme_support( 'align-wide' );

    // For the Block Editor.
    add_theme_support( 'editor-styles' );

    //Apply theme's stylesheet to the visual editor.
    add_editor_style('editor-style.css');

    add_theme_support( 'responsive-embeds' );`

So at this point, the inline style should contain your theme editor styles, not the ones coming from WordPress.

That's what I would have assumed, but I'm still seeing that stock editor style. Am I using the correct action?

yes, everything looks correct.

  • Maybe your function is not called properly or called too late?
  • Maybe a typo in the file name or something?

It's hooked into here with no priority--and as far as I can tell nothing is overwriting it:

add_action( 'after_setup_theme', 'c9_setup' );

I'm sorry but I'm not sure I can help more as everything seems correct at first sight. You could try to get more eyes on it in the forums https://wordpress.org/support/forums/

FYI, I'm using the block_editor_settings filter to remove the ['styles'][0] key which holds the inline styles. I'm not sure if this is safe or not.

add_filter('block_editor_settings', function ($editor_settings, $post) {
              unset($editor_settings['styles'][0]);

              return $editor_settings;
          }
);

I added @ligne13's code to my enqueue.php (included in functions.php) and removed the $post from the initial function declaration and it removes the inline styling.

Thanks @ligne13!

You're welcome !

@youknowriad,

Based on your expertise with the Block editor, is it safe to use this function https://github.com/WordPress/gutenberg/issues/18595#issuecomment-599588153 in order to disable the Editor Normalization Styles?

I am aware that we can override these styles using add_editor_style() (https://github.com/WordPress/gutenberg/pull/14407/files#r272065996) but I am wondering if it's possible to completely remove them in order to avoid loading the same styles twice (in case when the theme provides these normalize styles with its colors, spacing and line-height).

I've tried this solution https://github.com/WordPress/gutenberg/issues/7776#issuecomment-406700703 but it does not remove these normalize styles; while this solution https://github.com/WordPress/gutenberg/issues/18595#issuecomment-599588153 works perfectly.

Kind regards,
Taras

It seems safe for me yes. That said, some themes load styles without using the editor styles mechanism and this code won't have any effect.

This worked for me
```
/* /////////////////////
Function Reference/remove editor styles
Removes inline editor styles that TwentyTwenty puts in
https://codex.wordpress.org/Function_Reference/remove_editor_styles
///////////////////// */

function remove_twentytwenty_classic_editor_styles() {
remove_editor_styles($classic_editor_styles);
}
add_action( 'init', 'remove_twentytwenty_classic_editor_styles',20 );

Was this page helpful?
0 / 5 - 0 ratings