Make global styles available to all themes #34334

oandregal · 2021-08-26T15:09:14Z

This PR makes global styles available to all themes.

Themes without theme.json and no experimental-link-color support either: the stylesheet contains the core presets.
Themes without theme.json but experimental-link-color support: the stylesheet contains the core and theme presets.
Themes with theme.json: the stylesheet contains the core and theme presets, plus the result of merging core & theme styles.

How to test

Activate TT1-blocks: a theme with theme.json support. Visit the front end. Check the content of global-styles-inline-css is:

Both core & theme presets (classes and variables).
The block gap styles (see).
The theme styles.

Activate the TwentyTwentyOne theme: a theme without theme.json but with experimental-link-color support. Visit the front end. Check the content of global-styles-inline-css is:

Both core & theme presets (classes and variables).

Activate the TwentyTwenty theme: a theme without theme.json and no experimental-link-color support. Visit the front end. Check the content of global-styles-inline-css is:

Core presets (classes & variables).

Follow-ups

Remove the styles included here from the block-library package.

They just differ on what data they have: 1. Without theme.json and no experimental-link-color support either: the stylesheet contains the core presets & styles. 2. Without theme.json but experimental-link-color support: the stylesheet contains the core and theme presets, plus the core styles if any. 3. With theme.json: the stylesheet contains the core and theme presets, plus the result of merging core & theme styles.

oandregal · 2021-08-26T15:11:07Z

@youknowriad I'm seeing this piece of CSS in addition to the presets output for TwentyTwentyOne and TwentyTwenty. I presume this doesn't have to be enqueued unless there's a theme.json file?

body {
  --wp--style--block-gap: 24px;
}
.wp-site-blocks > * + * {
  margin-top: var(--wp--style--block-gap);
  margin-bottom: 0;
}

oandregal · 2021-08-26T15:46:07Z

ok, removed the block gap styles for TwentyTwentyOne and TwentyTwenty.

jffng

The test cases work for me as described.

ok, removed the block gap styles for TwentyTwentyOne and TwentyTwenty.

There may be a harmless edge case here:

Activate a theme with a theme.json
Make a post/page and add a block that inherits layout
Switch to a theme without a theme.json
Gutenberg will still generate alignment styles for those containers, but --wp--style--block-gap will be undefined.

oandregal · 2021-08-31T09:31:07Z

@jffng That seems to happen in the transition from a theme with theme.json to a theme without theme.json, so it happens with or without this PR. I'd think it's unrelated to this.

mkkeck · 2021-09-02T08:27:57Z

Why? and how could this be disabled?

oandregal · 2021-09-02T08:35:21Z

Why? and how could this be disabled?

Hi Michael, the issue this fixes #34328 explains the rationale. Note that this won't add any additional CSS that is not already shipped by other means (block-editor, block-library). We're simply moving that CSS from the packages to the global stylesheet.

mkkeck · 2021-09-02T08:54:42Z

Okay, I see.

But in my frontend is added:

<style id='global-styles-inline-css' type='text/css'>
/* ... */
--wp--preset--color-- 
/* ... */
</style>

This is what I want to disable because it's useless for me and bloats my frontend output.

oandregal · 2021-09-02T09:00:51Z

This is what I want to disable because it's useless for me and bloats my frontend output.

Hey, that's how the global stylesheet works. These are used across all the color classes (color, background, border) and theme authors reported them as useful as well. We don't have plans to remove them or to add any option to do so automatically.

mkkeck · 2021-09-02T09:28:44Z

Okay, I see the point.

But is it not really possible, via hook, to remove not used presets like gradients, duotones, colors?

I'm a frontend developer, I want to reduce code for faster loading. So why should I ship things, my theme and frontend never use?

Yes it is usefull for theme authors, but not really for theme or frontend developers.

oandregal · 2021-09-02T09:45:42Z

But is it not really possible, via hook, to remove not used presets like gradients, duotones, colors?

Hey Michael, if the theme you're using does not define any presets, no classes and CSS custom properties will be enqueued. Is that enough for you?

A different thing is that the presets defined by core will always be enqueued. The rationale for this can be discussed at #29568 It boils down to have stable colors available across themes for patterns. We also plan to expose them in the UI for users soon (see new color panel) #27473 (comment)

youknowriad · 2021-09-02T10:48:58Z

lib/global-styles.php

+	$type = 'all';
+	if ( ! WP_Theme_JSON_Resolver_Gutenberg::theme_has_support() ) {
+		$type = 'presets';
+	}


Shouldn't this $type check be part of gutenberg_experimental_global_styles_get_stylesheet directly? Meaning if there's no theme.json just pint the presets otherwise print everything?

Could be inside this function that way it works consistently regardless of the caller.

gutenberg/lib/class-wp-theme-json-gutenberg.php

Line 1072 in a59775a

public function get_stylesheet( $type = 'all' ) {

🤔 not sure how to do it. There're other calls below where, in the same code path, where want to build two different stylesheets (pseudocode):

$block_styles = gutenberg_experimental_global_styles_get_stylesheet( $tree, 'block_styles' ); $css_variables = gutenberg_experimental_global_styles_get_stylesheet( $tree 'css_variables' );

As I understand it, themes without theme.json shouldn't return just the "presets" like always. It shouldn't be the responsibility of the caller to switch the "type" depending on the theme, the caller just asks for the stylesheet and returning the right styles should be internal logic.

mkkeck · 2021-09-02T10:53:02Z

Hi again André,

yes I understand:

At the moment, it’s frustrating as a user that upon switching to a theme that overwrites the default color palette you lose access to the rainbow-color set that comes with core. The core palette aims to provide quick access to distinct hues reliably. A theme palette generally aims to define a restricted set of semantic colors for branding.

But such people could also add / merge the system colors via theme settings on their own (that I've done before).

... if the theme you're using does not define any presets, no classes and CSS custom properties will be enqueued

That's right but my theme uses presets, custom properties and - of course - lot of classes:
theme.json

Is that enough for you?

Not really. The wp-presets - specially the gradients - should not be merged, if theme has no gradients or set to false.
global-style-inline-css

But I found a solution (in hope not having other side effects):

add_action('wp_enqueue_scripts', function() {
  wp_dequeue_style('global-styles');
  // ... code for to enqueue my own 'global-inline-css'
});
// or as an alternative:
//remove_action('wp_enqueue_scripts', 'wp_enqueue_global_styles');

youknowriad

This works well in my testing (as advertised).
Maybe we could abstract away the "type" check as suggested above.

oandregal · 2021-09-02T14:57:59Z

@mkkeck Note that the core classes and properties may be used by patterns and will be exposed to users through the color panel well. I'd think it's fine to dequeue the global stylesheet and do your own enqueueing if you don't personally mind about that.

I'd recommend checking regularly in the Gutenberg release announces for changes in that area to make sure changes still work for you, though, as removing the core CSS is unexpected and not something we can cover for.

oandregal · 2021-09-02T15:25:33Z

Follow-up to remove CSS from the base-styles and block-library packages at #34510

oandregal · 2021-09-13T13:19:48Z

Devnote

To review/clarify/check when time comes to publish it.

We've made some changes to the stylesheets enqueued by default such as:

The preset classes for colors & font sizes that were previously in the block-library are now part of the global stylesheet, which is loader later (but before the theme's). We've removed them from the wp-block-library-css stylesheet, see Only enqueue default colors & gradients once #34138 and Only enqueue default font-sizes once #34006
Each preset value also generates a CSS Custom Property themes can use. There's some CSS that looks like this:

:root {
  --wp--preset--{preset-type}--{preset-slug}: <core-value>;
  --wp--preset--color--pale-pink: #f78da7;
  --wp--preset--font-size--huge: 42px;
  // ...
}

The preset classes now use these custom properties, and they look like:

.has-<slug>-<preset-type> { ... }
.has-pale-pink-color { color: var(--wp--preset--color--pale-pink) !important; } 
.has-huge-font-size { color: var(--wp--preset--font-size--huge) !important; }

Themes that use the theme.json can set these values in that file. Themes that don't, can set the CSS Custom Property in their stylesheet with something like:

:root {
 --wp--preset--font-size--huge: <theme-value>;
}

landwire · 2021-09-19T08:26:30Z

Devnote

To review/clarify/check when time comes to publish it.

We've made some changes to the stylesheets enqueued by default such as:

The preset classes for colors & font sizes that were previously in the block-library are now part of the global stylesheet, which is loader later (but before the theme's).

The preset classes now look like this: .preset-class { css-property: css-value !important; }. This is, they gain an !important they didn't have before.

There's also a new ruleset containing CSS Custom Properties for the presets (body { --wp--preset--color--value: value; ... })

Can we please remove the "!important" flag within the preset classes? Or at least add a filter that enables us to do so? See #34575 (comment)

I really do not want to start using the !important flag all over my theme to override things. My frontend theme is also CMS agnostic, so it's a pain to code more and more exceptions for WordPress.

mkkeck · 2021-09-19T11:45:28Z

To review/clarify/check when time comes to publish it.

We've made some changes to the stylesheets enqueued by default such as:

The preset classes for colors & font sizes that were previously in the block-library are now part of the global stylesheet, which is loader later (but before the theme's).

The preset classes now look like this: .preset-class { css-property: css-value !important; }. This is, they gain an !important they didn't have before.

There's also a new ruleset containing CSS Custom Properties for the presets (body { --wp--preset--color--value: value; ... })

More and more the Gutenberg project dictates theme and frontend developers how to use, write and code their themes to work with Gutenberg.

General, I like the Gutenberg Editor, but sometimes there's project philosophy, which is not acceptable:

Putting tons of new features, are knitted with hot needle, wich breaking current themes and plugins
New features rolled out to WordPress core, flagged as experimental, no opt-in or opt-out with no documentation
Eat or die mentality of some peoples here

That things have nothing to do with "CODE IS POETRY".

New features are really welcome, but these features should always have an opt-in or opt-out before rolling out to the WordPress core. All these features should also apply filters and actions, which enables patching.
Things which may break themes or plugins should be better tested and documented.

It is really bad to leave users, after minor upgrading their WordPress, with broken themes or plugins (and as result broken websites).

I must say, before FSE, there were less such issues.
Of course many users out there, mainly using a hosted WordPress on a SASS, require the FSE. But I know users, which disagree.

But some core developers here, I think, won't here them.

WordPress and Gutenberg should be tools to help end users to build pages and write content, not more and not less.
Styling pages and content should be done with themes only. I know, that users want a quick and ready to run solution, but for such cases there shiped themes like TwentyTwentyOne with the WordPress install package. Please patch these themes instead patching Gutenberg to overwriting themes handcrafted by theme developers.
Gutenberg should help to build great websites and themes and not sabotage the work of theme authors.

oandregal · 2021-09-20T11:43:42Z

This introduced a bug that I'm fixing at #34955

oandregal · 2021-09-23T07:30:12Z

I've updated a bit the devnote for this.

oandregal · 2021-10-07T16:37:39Z

Prepared #35424 to enqueue preset styles in the editor as well.

oandregal self-assigned this Aug 26, 2021

oandregal added [Status] In Progress Tracking issues with work in progress Global Styles Anything related to the broader Global Styles efforts, including Styles Engine and theme.json labels Aug 26, 2021

oandregal requested a review from youknowriad August 26, 2021 15:11

Do not enqueue block styles if theme does not have theme.json

a59775a

oandregal marked this pull request as ready for review August 26, 2021 15:46

oandregal requested a review from spacedmonkey as a code owner August 26, 2021 15:46

oandregal removed the [Status] In Progress Tracking issues with work in progress label Aug 26, 2021

oandregal requested review from aristath, carolinan, kjellr, jffng, scruffian and MaggieCabrera August 26, 2021 16:00

jffng reviewed Aug 26, 2021

View reviewed changes

This was referenced Aug 31, 2021

Make the global stylesheet available for all themes #34328

Closed

Prototype: merge block CSS with theme.json styles #34180

Merged

Add default editor styles applied to themes without theme.json and without editor styles #34439

Merged

oandregal requested a review from jorgefilipecosta September 2, 2021 08:35

youknowriad reviewed Sep 2, 2021

View reviewed changes

youknowriad approved these changes Sep 2, 2021

View reviewed changes

oandregal merged commit 482650a into trunk Sep 2, 2021

oandregal deleted the add/global-styles-to-all-themes branch September 2, 2021 14:51

github-actions bot added this to the Gutenberg 11.5 milestone Sep 2, 2021

oandregal mentioned this pull request Sep 2, 2021

Remove colors classes from the packages that are already provided by global styles #34510

Merged

mkkeck mentioned this pull request Sep 6, 2021

#34334 Breaks styles in theme's styles.css #34575

Closed

getsource added the [Type] Enhancement A suggestion for improvement. label Sep 8, 2021

oandregal added the Needs Dev Note Requires a developer note for a major WordPress release cycle label Sep 13, 2021

chad1008 mentioned this pull request Sep 17, 2021

add_theme_support() disabled for some editor options on without theme.json or experimental-link-color support #34931

Closed

oandregal mentioned this pull request Sep 20, 2021

Fix theme supports for themes without theme.json #34955

Merged

oandregal mentioned this pull request Oct 7, 2021

Enqueue preset styles for all themes in the editor #35424

Merged

scruffian mentioned this pull request Oct 11, 2021

Global Styles: Don't output preset classes for colors defined by the theme #35514

Merged

7 tasks

vinkla mentioned this pull request Oct 12, 2021

Remove Gutenberg's global styles vinkla/headache#5

Merged

mkaz mentioned this pull request Nov 11, 2021

Dev Notes Tracking Issue for WordPress 5.9 #36401

Closed

oandregal mentioned this pull request Jan 10, 2022

The global stylesheet should be enqueued for all themes WordPress/wordpress-develop#2129

Closed

This was referenced May 16, 2022

Regression: Columns CSS affects readability in WP 6.0 #40952

Closed

Block supports: add fluid typography #39529

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Make global styles available to all themes #34334

Make global styles available to all themes #34334

oandregal commented Aug 26, 2021 •

edited

Loading

oandregal commented Aug 26, 2021 •

edited

Loading

oandregal commented Aug 26, 2021

jffng left a comment

oandregal commented Aug 31, 2021

mkkeck commented Sep 2, 2021

oandregal commented Sep 2, 2021

mkkeck commented Sep 2, 2021

oandregal commented Sep 2, 2021

mkkeck commented Sep 2, 2021

oandregal commented Sep 2, 2021

youknowriad Sep 2, 2021

youknowriad Sep 2, 2021 •

edited

Loading

oandregal Sep 2, 2021

youknowriad Sep 2, 2021

mkkeck commented Sep 2, 2021

youknowriad left a comment

oandregal commented Sep 2, 2021

oandregal commented Sep 2, 2021

oandregal commented Sep 13, 2021 •

edited

Loading

landwire commented Sep 19, 2021

Devnote

mkkeck commented Sep 19, 2021 •

edited

Loading

oandregal commented Sep 20, 2021

oandregal commented Sep 23, 2021

oandregal commented Oct 7, 2021

Make global styles available to all themes #34334

Make global styles available to all themes #34334

Conversation

oandregal commented Aug 26, 2021 • edited Loading

How to test

Follow-ups

oandregal commented Aug 26, 2021 • edited Loading

oandregal commented Aug 26, 2021

jffng left a comment

Choose a reason for hiding this comment

oandregal commented Aug 31, 2021

mkkeck commented Sep 2, 2021

oandregal commented Sep 2, 2021

mkkeck commented Sep 2, 2021

oandregal commented Sep 2, 2021

mkkeck commented Sep 2, 2021

oandregal commented Sep 2, 2021

youknowriad Sep 2, 2021

Choose a reason for hiding this comment

youknowriad Sep 2, 2021 • edited Loading

Choose a reason for hiding this comment

oandregal Sep 2, 2021

Choose a reason for hiding this comment

youknowriad Sep 2, 2021

Choose a reason for hiding this comment

mkkeck commented Sep 2, 2021

youknowriad left a comment

Choose a reason for hiding this comment

oandregal commented Sep 2, 2021

oandregal commented Sep 2, 2021

oandregal commented Sep 13, 2021 • edited Loading

Devnote

landwire commented Sep 19, 2021

Devnote

mkkeck commented Sep 19, 2021 • edited Loading

oandregal commented Sep 20, 2021

oandregal commented Sep 23, 2021

oandregal commented Oct 7, 2021

oandregal commented Aug 26, 2021 •

edited

Loading

oandregal commented Aug 26, 2021 •

edited

Loading

youknowriad Sep 2, 2021 •

edited

Loading

oandregal commented Sep 13, 2021 •

edited

Loading

mkkeck commented Sep 19, 2021 •

edited

Loading