Allow filtering global styles

[webmandesign]

Due to using !important and possibly high selector specificity in CSS declarations in global styles code produced by WordPress 5.9, many themes supporting Gutenberg editor (but not block/FSE themes) ​experience issues with WordPress overriding their custom font sizes and color palettes (​registered via `add_theme_support()`).

It would be great if WordPress allowed at least filtering global styles code (produced by ​`wp_get_global_stylesheet()`) with a hook, such as: changing ​`return $stylesheet;` in wp_get_global_stylesheet() to:

/**
 * Filters the global CSS styles code.
 *
 * @since 5.9.1
 *
 * @param string $stylesheet CSS styles code.
 * @param array  $types      Types of styles to load.
 * @param array  $origins    A list of origins to include.
 */
return apply_filters( 'global_styles', $stylesheet, $types, $origins );

That way WordPress can keep its global styles intact (even with !important if that's really the best way to provide the styles...) for block/FSE themes and Gutenberg editor themes can adapt the global styles by using this filter if needed.

(Block/FSE themes and themes that do not add support for Gutenberg editor do not seem to be affected.)

---

More info can be found in ​https://github.com/WordPress/gutenberg/issues/38252#issuecomment-1023345698 and related comments.

[oandregal]

Hi, we've discussed filters for global styles code a couple of times, including in the WordPress 5.9 cycle at ​https://github.com/WordPress/gutenberg/pull/36909 When we do filters for this code, I'd think we do it much earlier in the processing chain: we want consumers to have structured data to work with and not a blob string difficult to parse and modify.

We've heard the conversation in the issue you point to and we'll be shipping in 5.9.1 a fix for classic themes that modify the defaults ​https://github.com/WordPress/wordpress-develop/pull/2233 The editor styles and the front will be the same.

If themes want to do further modifications (editor & front using different styles), they can tap into the CSS hooks in place: using the existing CSS Custom Properties. See this devnote for an example ​https://make.wordpress.org/core/2022/01/08/updates-for-settings-styles-and-theme-json/

If the goal is to stop enqueuing the default styles (colors, font sizes, etc), there's an existing API for that: wp_dequeue_styles. As I mentioned in other places this can have unintended side-effects as there're pieces that use the defaults (patterns, existing content, etc).

Does this help clarify? Is there a need not covered by the existing mechanisms?

[webmandesign]

Hi @oandregal,

When we do filters for this code, I'd think we do it much earlier in the processing chain: we want consumers to have structured data to work with and not a blob string difficult to parse and modify.

That's a great idea!
I think it would still be beneficial to have a filter on the actual CSS string though. That way it's much easier for a theme to remove !important from the CSS, for example, or add its own CSS string if necessary.

The editor styles and the front will be the same. If themes want to do further modifications (editor & front using different styles), they can tap into the CSS hooks in place

So, if I understand correctly, we are still stuck with !important styles and the only way is to set --wp--preset--<PRESET_TYPE>--<PRESET_SLUG> in the theme :)

You see, the 5.9.1 fix will not really be beneficial for my usecase as I apply responsive typography in my themes on front-end only (it is not possible to do so in editor, unfortunately). So I have to set up --wp--preset--<PRESET_TYPE>--<PRESET_SLUG> CSS variables if I don't get rid of !important.

If the goal is to stop enqueuing the default styles (colors, font sizes, etc), there's an existing API for that: wp_dequeue_styles. As I mentioned in other places this can have unintended side-effects as there're pieces that use the defaults (patterns, existing content, etc).

I do not want to dequeue the global styles. I understand their importance and surely want to keep them for backwards compatibility if they were used in the existing content in the past. I just want a way to control the output of the styles and remove (in my opinion) redundant !important as my theme takes care of styles.

I came up with ​this code for the time. But it feels really hacky to dequeue global styles, process them, and enqueue again - I agree with you it may have side-effects I'm not aware of currently and that's why I don't want to "fix" them using that code.

Having a filter would be much better approach in my opinion.

[webmandesign]

Hi,

After a year, I'm building a block theme (actually a "hybrid" theme) and still came up with a usecase where I would really appreciate a filter for the actual CSS data passed to global-styles handle. It would really be nice if we could filter the ​`$stylesheet` variable passed as an inline data for `global-styles` handle.

The usecase is not the same as the original issue here, but the request remains the same as you can see.

If I'm not mistaken, there is currently no way for a theme developer to change where WordPress registers/sets its CSS properties. Currently this is done on body HTML selector. I'd like to use :root instead.

I understand this need to stay intact in core WordPress due to editor styles where body is being replaced with .editor-styles-wrapper, but please, at least allow theme and plugin developers to filter the data if needed.

body seems to be unnecessarily too high of a specificity to register CSS properties, at least on front-end of the website.

Thanks for consideration.

re: @oandregal

[webmandesign]

Also, the WP "Version" for this ticket is set to 5.9 and I can't change it. I'm afraid this is going to be forgotten. Should I create a new ticket for new WP version instead?