Opened 3 years ago
Last modified 21 months ago
#54975 new enhancement
Allow filtering global styles
Reported by: | webmandesign | Owned by: | |
---|---|---|---|
Milestone: | Awaiting Review | Priority: | normal |
Severity: | normal | Version: | 5.9 |
Component: | Editor | Keywords: | |
Focuses: | css | Cc: |
Description
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.
Change History (5)
#3
@
3 years ago
Hi @oandregal,
Thank you for your feedback!
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.
#4
@
21 months ago
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
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?