Remove default colors

[rilwis]

I see Gutenberg included quite a lot of default colors in the CSS:

pale-pink
vivid-red
luminous-vivid-orange
luminous-vivid-amber
light-green-cyan
vivid-green-cyan
pale-cyan-blue
vivid-cyan-blue
vivid-purple
very-light-gray
cyan-bluish-gray
very-dark-gray

They're available in the CSS files only, but not in the color palette when editing posts. To make them appear in the color palette, themes must define support for those colors. But in that case, themes still need to add their own CSS to make sure they work properly.

So, it's redundant to keep the CSS in the Gutenberg CSS to keep things minimal. There's also some config in the block-editor.js file that reflects these colors as well.

[jorgefilipecosta]

Hi @rilwis,

Themes don't need to define support for these colors. If the theme does not use any color functionality at all these default colors will appear in the color palette.
In your tests when a theme does not reference any color functionality, these colors do not appear in the color palette? If that's the case I guess we may have a bug.

Thank you in advance for further information!

[rilwis]

Hi @jorgefilipecosta ,

In my case, our theme has a custom color palette (different from default). And the default colors don't appear in the edit page, which is correct.

However, the CSS is still in the outputted CSS of Gutenberg, which causes these issues:

• it's redundant and makes the CSS files large, which is bad for performance
• when testing with theme unit test data, the data contains default CSS classes for default colors, which makes the blocks appear incorrectly. Some theme reviewers (we got one on ThemeForest, and probably there'll be more on .org) say it's inconsistent between admin and frontend
• might cause unexpected result if the theme use the same CSS class elsewhere (without the color functionality)

[aristath]

I'm thinking that we could probably remove all these custom colors from the hardcoded stylesheets, and instead create them dynamically.
So the idea here would be to create a new function that checks if the current theme has a palette defined. If it does not, then we can wp_add_inline_style all existng colors. If on the other hand the current theme defines a color palette, then we could check the colors defined and only wp_add_inline_style styles for colors that are default.

But then that brings up another interesting point:
If I had a theme on my site which was using the default palette (in other words didn't have a custom palette defined), and created a bunch of posts using these colors, should I lose these colors on the frontend when I switch themes?
We could of course add a filter on render_block and add inline styles if the current theme doesn't support a default color but the block uses it... But that would probably over-complicate things. 🤔

[rilwis]

I think Gutenberd shouldn't add default color palette at all. Let themes do that via add_theme_support. Then no custom CSS is added at all and we can eliminate all the issues.

If users switch to another themes, then they should know that themes use different color palette and thus, the old color palette might not be applied.

[youknowriad]

@aristath yes, that's an idea we explored previously with @jorgefilipecosta (auto-generated the palette styles) and i think it's something we should revisit when we move all the presets definitions to theme.json.

[skorasaurus]

Update: Still applicable in Gutenberg 12.4.3; WordPress 5.9

Goal/Issue: Do not include the CSS for gradients when these presets are disabled within the theme.

I found this issue because I was about to create an issue for this same problem, the problem that @rilwis is referring is that the Global/default CSS colors are defined and included inline in your html even when you disable them in the theme support hook or through the theme.json

To reproduce:

1. Add the following theme filters like applied and hooked into a theme properly.

	add_theme_support('editor-gradient-presets', []);
	add_theme_support('disable-custom-gradients', true);

Or its equivalent rules in a theme.json file.

    "color": {
      "customGradient": false,
      "defaultPalette": false,
     "defaultGradients": false,
      "gradients": [],

2. Create a page
3. publish page
4. View source:
   Using the Gutenberg plugin,

(Feb. 2022:
The rules (includes all of the global inline styles, including rules for fonts, colors, duotones, and gradients) are minified, included on each page, within the HTML of each page, about 10kb, uncompressed when in a separate file.

(In July 2021:
the rules are minified are included build/block-library/style.css ; and make up 3.6kb of the 58kb file (as a resource size). (Notably, css/JS files are compressed by the network during transfer, so that 58kb file becomes about 9kb.)
If you are not using the plugin, they're deminified, stored in wp-includes/css/dist/block-library/style.css, make up 4.5kb of the 62kb file.

[oandregal]

In my case, our theme has a custom color palette (different from default). And the default colors don't appear in the edit page, which is correct. However, the CSS is still in the outputted CSS of Gutenberg.

Hi, note that this is the expected behavior. The idea is that the core colors are always available in CSS (only for themes with theme.json support).

There're two reasons for this: one is patterns, and having a system that works across themes; the other is that there's plans to redesign the color component to show core, theme, and user colors. #29568 is the relevant issue and I'd welcome comments on it, so others that follow it can see them as well.

I'd think we can close this issue as discusses things that are already in #29568 and the behavior is expected.

[oldrup]

I cannot say I'm thrilled to have such a massive block of inline styling on every single page. Could it maybe be moved to a stylesheet instead? I'd love to get rid of it.

[aristath]

I cannot say I'm thrilled to have such a massive block of inline styling on every single page. Could it maybe be moved to a stylesheet instead? I'd love to get rid of it.

This is a performance enhancement. If you want to disable inlining small assets, try adding this:

add_filter( 'styles_inline_size_limit', '__return_zero' );

You can read more in this article: https://make.wordpress.org/core/2021/07/01/block-styles-loading-enhancements-in-wordpress-5-8/

[oldrup]

This is a performance enhancement. If you want to disable inlining small assets, try adding this:

add_filter( 'styles_inline_size_limit', '__return_zero' );

Thank you for this input @aristath. That would be sufficient for me, however I can not get it to work.

I tried both the snippet above, and the alternative
add_filter( 'styles_inline_size_limit', function() { return 0; // Size in bytes. });

To no avail.

Let me clarify, that this block of inline styling first occurred on my WordPress 5.9 RC2/3 test installation. I'm not seeing it on my WordPress 5.8 sites.

And while I'm aware, that inlining small bits of styling makes great sense performance wise, I'm using brand colours for all my sites, not WordPress core colours, and I have a hard time grasping how beginning to load unused colour-styles inline, is a performance enhancement. I only see 8 kb of additional overhead since installing WP 5.9.

I'm not complaining. There is obviously something I don't understand, and I'd prefer to.

My WP 5.9 test site is https://oldrup.net/, should anyone have an idea what I'm doing wrong.

[aristath]

Ah perhaps I misunderstood the issue then. I thought the comment above was about the fact that the styles get inlined as opposed to enqueued as a stylesheet.
In WP 5.9, for compatibility reasons, the default palette gets enqueued too. I haven't tested this, but I believe that you can remove these by adding some values to your theme.json file (settings.color.defaultPalette and settings.color.defaultGradients) and setting them to false. Found the above in this comment

{
	"settings": {
		"color": {
			"defaultPalette": false,
			"defaultGradients": false
		}
	}
}

[oldrup]

Thank you, @aristath.

I attempted this approach both in my child theme folder and on the parent theme, with theme.json version 1 and 2, but was unable to succeed in removing the inline styling. I have no prior experience with configuring themes using .json, and it is clear to me that I need that first. Thank you for giving me some direction.

[agent-617]

Following @oldrup from his question over on wordpress.org topic in the event this is helpful to others.

You can remove the Gutenberg theme library on the front-end (if not necessary) along with the inline injection, and save an additional 77.3KB in the DOM. As well as address WooComm variant with the following code in your functions.php:

//REMOVE GUTENBERG BLOCK LIBRARY CSS FROM LOADING ON FRONTEND
function remove_wp_block_library_css(){
wp_dequeue_style( 'wp-block-library' );
wp_dequeue_style( 'wp-block-library-theme' );
wp_dequeue_style( 'wc-block-style' ); // REMOVE WOOCOMMERCE BLOCK CSS
wp_dequeue_style( 'global-styles' ); // REMOVE THEME.JSON
}
add_action( 'wp_enqueue_scripts', 'remove_wp_block_library_css', 100 );

Alternatively, you can just remove the inline style injection with the following (but this will NOT remove the block library stylesheet but rather the global variables that are injected inline):

// DISABLE GUTENBERG STYLE IN HEADER - WORDPRESS 5.9
function wps_deregister_styles() {
wp_dequeue_style( 'global-styles' );
}
add_action( 'wp_enqueue_scripts', 'wps_deregister_styles', 100 );

[annezazu]

Going to close this issue out based on the above dialogue and resolutions! In case it's helpful to more folks, wanted to flag the following sentence from this post:

Additionally, when you add theme.json to your Classic Theme, some controls for color and typography are enabled by default. This can be managed by using this theme.json setup that disables all features to allow you to opt-in to the ones your theme uses.

If this needs to be re-opened for some reason, please just comment :) For now, seems best to continue the discussion here: #29568

[JiveDig]

For anyone that finds this issue before others, a working solution is this filter:

/**
 * Filter the default theme.json data.
 *
 * Removes default duotone, gradients and color palette values provided by WordPress core.
 * This allows the theme to define its own color settings without also loading core defaults as CSS variables.
 *
 * @param WP_Theme_JSON_Data $theme_json The default theme.json data.
 *
 * @return WP_Theme_JSON_Data The modified theme.json data.
 */

add_filter( 'wp_theme_json_data_default', function( $theme_json ) {
	// Get JSON data as an array.
	$data = $theme_json->get_data();

	// Remove duotone, gradients, and palette values.
	$data['settings']['color']['duotone']['default']   = [];
	$data['settings']['color']['gradients']['default'] = [];
	$data['settings']['color']['palette']['default']   = [];

	// Update the theme JSON data.
	return $theme_json->update_with( $data );
});

I wish I had found this issue before digging for a while to find it, since the solution I came up with was already there ;P

Basically, these properties are there for backwards compatibility. For new sites, I'll be running this filter for the foreseeable future.