Add color reference mechanism #21490
Conversation
jorgefilipecosta
added
[Type] Enhancement
jorgefilipecosta
requested review from
ajitbohra,
ellatrix,
Soean,
talldan,
TimothyBJacobs and
youknowriad
as code owners
|
Size Change: +215 B (0%) Total Size: 1.12 MB
ℹ️ View Unchanged
|
| type: 'string', | ||
| }, | ||
| } ); | ||
| } |
There was a problem hiding this comment.
It is very cool that we avoid the need for all these custom attributes.
There was a problem hiding this comment.
I'd like to try to understand the pros/cons of this approach in order to know how/if to move forward with it, for me:
- I like that custom colors and palette colors work in the exact same way, same attribute...
- I like that theme authors don't have to write any CSS for their palettes to work properly.
- Potentially, opens the door for InnerBlocks specific color palettes. (In this section of the page, the palette is different)
What could be considered as downsides:
- No smart behaviors (auto-apply text color when choosing a background color), while I understand why some theme authors do it, I feel it's not the right thing to do anyway because the behavior becomes inconsistent with custom colors and can be confusing.
- Inline style to apply the variable instead of a className: Again for me I don't see it as a downside, because choosing a variable, or choosing a className is similar in terms of reusability, we only need to change the value in a single place...
Backwards compatibility:
- For BC, it looks like themes need to keep their current classNames CSS for existing content.
Potential way-forward:
Is it possible to make this new behavior the default for new palettes (palettes provided using theme.json), document it as the canonical way to define palettes and keep the previous behavior for some time for themes that still use the old way of providing a palette (potentially throw a console log or something about it being deprecated)?
Hi @youknowriad, Although this PR allows specifying colors using theme.json, right now in practice is not possible in to do it -- colors have names that need to be translatable and JSON files are not translatable. So I guess new palettes will still not be specified in theme.json but using a PHP call. I guess we could achieve something similar if we use the new mechanism when a theme.json file is specified but we don't use if theme.json file does not exist. |
I think we can work with the CLI team to fix that. |
If we don't do it, we'd potentially break some themes. Maybe it's fine but we'd have to measure the impact properly. What number of themes do have smart logics? |
jorgefilipecosta
force-pushed
the
add/color-reference-mechanism
branch
from
4c49453
to
4b9c3c8
Compare
jorgefilipecosta
force-pushed
the
add/color-reference-mechanism
branch
from
4b9c3c8
to
4b851fb
Compare
|
Hi @youknowriad, some updates were performed in this PR:
|
lib/global-styles.php
Outdated
| $settings['__experimentalGlobalStylesUserEntityId'] = gutenberg_experimental_global_styles_get_user_cpt_id(); | ||
| if ( gutenberg_experimental_global_styles_is_site_editor() ) { | ||
| $settings['__experimentalGlobalStylesUserEntityId'] = gutenberg_experimental_global_styles_get_user_cpt_id(); | ||
| } | ||
|
|
||
| $global_styles = array_merge( | ||
| gutenberg_experimental_global_styles_get_core(), | ||
| gutenberg_experimental_global_styles_get_theme() | ||
| ); | ||
|
|
||
| $settings['__experimentalGlobalStylesBase'] = $global_styles; |
There was a problem hiding this comment.
mmm, is __experimentalGlobalStylesBase needed by the block editor?
There was a problem hiding this comment.
It seems it is not needed and it seems we have other settings not used at all. I will open a separate PR to remove unused settings.
There was a problem hiding this comment.
mmm, how so? __experimentalGlobalStylesUserEntityId is used in the site editor to retrieve the CPT through the entities API and __experimentalGlobalStylesBase is used in the site editor as well to know which is the base styles the user will overwrite.
There was a problem hiding this comment.
I think I'm missing something for example when searching for __experimentalGlobalStylesUserEntityId in the edit-site package nothing is found, how does edit-site accesses the setting?
There was a problem hiding this comment.
It's used by the GlobalStylesProvider but it the branch that introduces that hasn't landed yet.
lib/global-styles.php
Outdated
| dirname( dirname( __FILE__ ) ) . '/experimental-default-global-styles.json' | ||
| ); | ||
| // Todo: Remove this when colors are properly set on themes.json | ||
| // For now colors can not be set there because json files are not translatable. | ||
| if ( empty( $core_styles['colors'] ) ) { |
There was a problem hiding this comment.
We have these at the JavaScript level as well (packages/block-editor/src/store/defaults.js). Can we perhaps not to have them here and let the block-editor handle the defaults?
There was a problem hiding this comment.
We need to have the defaults here, in order to generate CSS vars on the frontend for each color. I think we should remove the defaults from the JS side to avoid the duplication, but as for now we only run this code if global styles are enabled it seems safer to leave the defaults there.
|
I really like the direction here. I'm inclined to think some of the things this PR does we should merge right away while others should wait. Let me explain my thinking: 1) Overrides the editor color settings from a theme.json declaration if it is present [WAIT] This is not ready due to lacking i18n support in JSON files. We're also storing color defaults in PHP in addition to having them stored in JavaScript. I think it'd be best to wait until the JSON situation is resolved. 2) Switches preset colors from classes to inlined CSS vars & opens up Global Styles mechanism to block editor. [WAIT]
3) Exposes color presets and introduces a namespace for colors. [MERGE] I think this is great and I also had a local experiment that I dusted off yesterday for all style presets (colors, gradients, font-sizes) that I published at #22076 It doesn't matter to me if we refactor this PR to address only this point or we merge 22076, whatever you think is best would work for me. Related to how to namespace the palettes/style presets, I was thinking we could use a namespace to accommodate "all the things themes": colors, gradients, and font-sizes style presets; but potentially any other theme support (wp-block-styles, align-wide, etc) and even the ability to disable the palettes (disable-custom-colors, disable-custom-gradients, disable-custom-font-sizes). In #22076 I propose using Final note This turned out to be a long comment! Thanks for your patience. Do you think this is a fair assessment of the current situation and what this PR does? How do you feel about all this? Should we move forward with 3 and let 1 and 2 wait for a bit? |
|
I think without introducing the block level support, this PR loses a bit of its importance cause right now, no one is using theme.json yet. That said, I agree that it should be done with care: nudge people to use the "new" palettes instead and softly deprecate the old ones without any breakage.
I think the JSON situation won't be resolved until we merge the PR :) (because we need an available API to implement it) I don't mind if we only merge the CSS variables generation first though. |
You're right! Poor phrasing on my part. I meant that this part of the PR should land after the CLI PR. |
It seems the work to have i18n in JSON files is ongoing. I think we should not wait for that work. We can continue the global styles work, without the strings being translated for now. When that work is done, the strings will be translatable. It seems they are independent things, and we should not feel blocked.
What are the issues we need to address that you think specifically block this task?
This PR does not apply any markup/style change unless a theme.json file is present, so it seems safe. From my point of view, if we still want to use CSS variables instead of classes for predefined colors, it seems like this PR could be merged without any blocker after rebased to account for the changes in #22076. |
|
@jorgefilipecosta can you point me to the definition of what a |
|
@swissspidy for internationalization, it's probably relevant to take into account all the presets we already allow defining for the block editor: color palette, font sizes, and gradients. We'd probably want all of them to be defined in We're still iterating on the theme.json shape, this is the direction we're aiming for. |
|
Ideally, we would have a way to easily configure the theme.json paths that are translated. I guess a possible simple version would be to translate all values under a name key as for now all the values we need to translate are under a name key. Would make all name properties objects part of the array config.color.palette translatable. |
|
No idea where you'd want to put that config, but adding it to the |
Sorry, I think I did not explain correctly, that config would be something internal and static, Gutenberg and WordPress core developers can change it when adding new features to theme.json. But the structure would not be part of themes.json. |
|
Ideally, such a config would be provided where WP-CLI can read it. So instead of hard-coding translatable string locations in WP-CLI, it would automatically keep in sync with Core/Gutenberg when trying to extract these strings. This makes it easier to adapt the definitions, as it would never be blocked by missing tooling support from then on. |
… styles reference mechanism.
jorgefilipecosta
force-pushed
the
add/color-reference-mechanism
branch
from
4b851fb
to
fddbf02
Compare
Hi @schlessera, thank you for sharing your thoughts. I totally agree with what you said. A possible place where the configuration could live is on the Gutenberg repository, so it is close with the code that reads the JSON files. For the configuration shape, I guess the same configuration should be used for block.json and theme.json. I guess the configuration could like this |
|
According to the feedback from @nosolosw I'm going to close this PR for now. Theme.json shape is not yet totally stable and passing parts of that data structure to color components etc would make changing things harder in the future. When the shape is more stable this PR should be reopened. |
|
it seems to me that the unstable state of theme.json is already clear by the fact that the file is named experimental-theme.json this suggests that we may be able to implement this in the blocks and just make it stable by renaming the file when we think it's ready for prime time. |
|
To clarify, I think there are two different things here that are conflated: The feedback I gave above, in which I point to CSS variables as something that needs more work. We are only using them for presets at the moment. Although we'll investigate to expand them to the block implicit attributes is not clear that we'll end up using them, so, in my view, it seems premature to use them at the block level. The other bit is about the shape of the theme.json file: Jorge and I were talking about using this file to connect with the existing editor subsystem (presets, etc), which right now use the presets defined via |
I'm not suggesting to use CSS variables for something else, I'm suggesting to use inline styles that reference the theme presets at the block level. |
|
@youknowriad sorry it took me so long to respond. I had this comment ready but, apparently, I didn't hit the send button. I'd like to explore an alternative: what if we inlined the actual values for every user modification (presets -custom and not- as well as style variations)? Have we explored that in the past? My thinking goes like this. What should happen with user modifications when they change themes?
From the options above, the more robust (predictable results) seems to be 1.1. What are your thoughts on this? |
This is how the original implemention of the palette worked. We had a lot of push back for it (inline styles) and we wanted to be able to support changing the colors across the entire site using global styles (or similar adhoc implementations in customizer...) |
|
As referred in #22722 (comment). I think we should not use direct value. Becase as @youknowriad referred we want to allow users to globally change colors across a website even for existing blocks in all posts/areas direct value does not offer that. Regarding the disadvantage, "when the user changes themes, the block style is broken because the new theme does not have the same colors". If predefined colors are kept and the theme is changed, the old colors may not look good at all on the new theme, and the design may appear broken as well. There may be cases where the design may look even more broken if predefined colors are kept than if the defaults (no color selected) of the new theme are applied. Between classes and CSS variables I don't have a strong preference. |
This PR changes the way named colors are implemented. Instead of using classes for named colors this PR's proposes to use the same mechanism we use for custom colors but instead of having the value inline we reference a variable representing the color value.
The variables are generated using a mechanism implemented with global styles.
In order to have the CSS variables always available, this PR exposes global styles functionality that was behind flags (new settings and printing the variables so side effects are expected). Related: wp-cli/i18n-command#163
This PR also proposes that colors are passed using theme.json. Although currently, we can not use that for colors because soon files can not be translatable so sweet the data structure on the PHP side.
This PR removes the need for themes to create color classes.
How has this been tested?
I verified using predefined colors on the paragraphs and headings works as expected.
I verified paragraphs and headings previously created using predefined colors, are migrated to the new reference mechanism.
I verified it was possible to change colors by using theme.json (although not recommended right now) by changing file experimental-default-global-styles.json to: