Open daviedR opened 2 years ago
Yes please. I'm currently doing this in my theme's CSS, which means I have to generate all of the has-foo-color classes manually and it won't extend to custom colors added in the global styles editor.
Technically, if we can reuse the way (maybe a function) Gutenberg access the global colors list, we can add our own custom CSS based on that list.
I came up with the exact same idea, since I think it's probably a fairly obvious solution. We almost named the vars the same too, lol
As I mentioned on my version, if we use Local vars (custom properties), we could just pass them to a style
attribute directly instead of generating a class
and obviate the need to use .has-red-color
at all. Or, do both.
I'm not sure if there are any other ways to vote for Gutenberg feature request, but yes, please! :D
What problem does this address?
Gutenberg will add a combination of 2 CSS classes to the block's markup whenever user set the block color settings:
Setting the background color to
red
will add these CSS classes:has-background
andhas-red-background-color
. Setting the text color toblue
will add these CSS classes:has-text-color
andhas-blue-color
.The current generated CSS implementation directly sets the CSS properties with
!important
value:This will force the color to be applied to the block's root markup, where the CSS classes added. In some cases, theme designers needs to apply the colors on the inner elements.
For example:
Table block with Stripes style: Setting the background color on the block editor, will apply background color to the whole table. Theme designers might want to use the background color settings for the alternate row color instead of the whole table background color.
What is your proposed solution?
Let's use locally scoped CSS custom properties for the generated CSS:
The main advantage of this implementation is: theme designers can reuse the color value inside the block inner elements.
If we use this in the previous example, Table with Stripes style:
Another example: I took a look at the Navigation block styling, which is pretty complex. Currently we need to use
inherit
and!important
value to control the submenu colors, etc. With this implementation, it can be simpler, we can reuse the menu background color and submenu background color easier without the need to useinherit
and!important
in the CSS.CSS custom properties naming
If
--background-color
is too general name, we can use more unique naming to the locally scoped CSS custom properties, e.g.--_background-color
,--wp--local--background-color
, etc.