Try: Indicate when text color in post editor is inherited from Global Styles #55952
Conversation
|
This pull request has changed or added PHP files. Please confirm whether these changes need to be synced to WordPress Core, and therefore featured in the next release of WordPress. If so, it is recommended to create a new Trac ticket and submit a pull request to the WordPress Core Github repository soon after this pull request is merged. If you're unsure, you can always ask for help in the #core-editor channel in WordPress Slack. Thank you! ❤️ View changed files❔ lib/experimental/editor-settings.php ❔ lib/experiments-page.php |
michalczaplinski
added
[Type] Enhancement
|
Size Change: +178 B (0%) Total Size: 1.71 MB
ℹ️ View Unchanged
|
|
Flaky tests detected in 40a4b4b. 🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/8193624560
|
|
WOW, this opened a lot of flaky test reports. Let's remember to close those once the CI checks are green. |
michalczaplinski
requested review from
youknowriad,
oandregal,
ajlende and
cbravobernal
There was a problem hiding this comment.
One interesting thing here as well is on the design side (just make sure to include designers in the PR):
This PR kind of makes a difference between an actual "red" color or an inherit "red" color not that visible for the user. What happens if the user wants to explicitly set a color that is inherited, should that be supported, maybe not that important?
I also wonder if users would want to "unset" the inherited value locally. Also maybe not, but I wanted to ask the question.
I think @jameskoster also had thoughts about this kind of things.
| padding: '4px 3px', | ||
| } | ||
| : undefined | ||
| } |
There was a problem hiding this comment.
This is interesting, just noting that the "inheritValue" prop is a common prop to all the *Panel components and that in global styles for "block panels" it's possible to be set with the value set at the "root level" of global styles for instance.
So basically, the behavior you're introducing here is also going to trigger in the global styles sidebar for blocks. I think that's probably fine but it's something to be aware of.
There was a problem hiding this comment.
the behavior you're introducing here is also going to trigger in the global styles sidebar for blocks
yup, thanks for pointing that out! I noticed it as well, but I haven't tried to fix it at all yet.
| @@ -293,6 +294,9 @@ export function ColorEdit( props ) { | |||
| const { clientId, name, attributes, setAttributes } = props; | |||
| const settings = useBlockSettings( name ); | |||
| const isEnabled = useHasColorPanel( settings ); | |||
|
|
|||
| const [ userValue ] = useGlobalStyle( '', props.name, 'user' ); | |||
There was a problem hiding this comment.
I do think we need some kind of useGlobalStyle hook in the block editor or maybe just useStyle since we already have the useSetting one for the "settings".
So yeah I wouldn't use the "global styles provider" and useGlobalStyle or useGlobalSettings as they exist today. In fact these two hooks were in edit-site as well, they have been moved to block-editor but as you can check they're only used in edit-site, so while I believe the goal was to "merge them" with "useSetting" and a potential "useStyle" that is block editor specific, this was never done. So at the moment, I consider "useGlobalStyle" and "useSetting" as edit-site specific things just like the provider. (I think it was @noisysocks that moved them, I forgot the entire reasoning)
I guess in my mind, we need to introduce a new key to settings prop of BlockEditorProvider that should contain the global styles "styles" property (we only have settings right now) and use that property to build a block-editor version of useGlobalStyle hook?
Maybe I'm missing something here so would love to hear more thoughts.
There was a problem hiding this comment.
we need to introduce a new key to settings prop of BlockEditorProvider that should contain the global styles "styles" property (we only have settings right now) and use that property to build a block-editor version of useGlobalStyle hook?
Yes! This would certainly fulfill the needs of the current PR (and the larger styles inheritance UI system). I don't know enough to know if this potentially introduces any problems though.
Btw, is there any overlap here with #55970 ?
There was a problem hiding this comment.
@michalczaplinski not necessarily, the problem here is a bit different than sharing the same code between edit-post and edit-site, we want access to the style hierarchy in the "block-editor" package. Until now, the block editor was only aware of the editor styles as CSS (styles property in the settings prop) but now we want the theme.json structure.
There was a problem hiding this comment.
I dug here a little bit and these are the ideas I tried:
1. Create a useStyles() hook in the block-editor to get the styles and pass them to the BlockEditorProvider.
The GlobalStylesProvider that I used in the current PR relies on useGlobalStylesUserConfig():
which in turn loads the global styles from the core-data store:
However, we cannot use the core-data package in the block-editor either...
2. Pass the data to the settings on the server
My second thought was to see if we can pass the required styles on the server in PHP in the block-editor-settings.php. However, the Global Styles are loaded via the REST API so that's not an option either as far as I can tell.
3. Create a useStyles() hook in the editor package and use it in the edit-post to inject the styles.
This approach looks the most reasonable to me as we can use core-data in the editor package. I opened a new PR in #59929 following this approach.
However, I'm still not sure if that's the best way to solve the problem:
- Having distinct logic for getting the styles in the
edit-siteandedit-postdoes not seem ideal. - It seems a bit out of place to have styles-specific logic in edit-post/src/editor.js
I'd appreciate your guidance here @youknowriad! 🙏
There was a problem hiding this comment.
For me, the best approach is probably an additional "setting" to the settings prop of the BlockEditorProvider.
- We have
__experimentalFeatures(which we should probably rename at some point for the "settings" part of theme.json - We need the same but for "styles".
The problem is going to be the naming of these settings and I'm not the best person when it comes to naming things tbh 😬. cc @mcsf maybe
There was a problem hiding this comment.
@michalczaplinski you're right, sorry I missed this.
There was a problem hiding this comment.
No worries, I appreciate the guidance! I'm glad that we had roughly the same idea 🙂 We can continue to discuss in the PR.
There was a problem hiding this comment.
it is also possible to combine both "__experimentalFeatures" and styles in a single prop we could name
thememaybe but I'm not sure entirely. I'd defer to others.
How about template? 
More seriously, I think this should be an opportunity to inventory everything that goes into __experimentalFeatures (as someone who isn't touching these pieces all the time, it's hard to remember what goes where). I think I'd favour a solution that strives for consistency with theme.json, since theme.json is already established as the dominant mental model that people need to get comfortable with, so we might as well piggyback off that.
There was a problem hiding this comment.
(Since the question was about naming, this was implicit but omitted in my comment: it would be nice to be able to express things in terms of styles & settings)
There was a problem hiding this comment.
How about template?
I'll do you one better: Template hooks 😄
Makes sense @mcsf. I've closed this PR in favour of #59929 which is the approach @youknowriad suggested. Let's continue to discuss there 🙂 .
|
Thanks for the ping.
So essentially detach the inheritance, so that if the source is changed the local setting remains? That could potentially work like any other local override. IE you'd open the color picker and select the same color, after which the value becomes local. An alternative approach would be a dedicated "unlink" button like in Figma, but that would add friction if applied to all controls. More generally I saw some chatter about this feature yesterday, specifically that the purple accents might be a bit much. It might be simpler to start by showing default values in controls (without the purple accents / inheritance details) to begin with, then focus on adding the blue dot (designs in #49278) to local overrides. cc @SaxonF |
|
Thank you for your comments @youknowriad and @jameskoster ! 🙏
That makes sense, and I also think selecting the same color is better than adding a separate "unlink" button.
From the technical point of view, the majority of the logic in the code has to do with whether and when to show the default value. If we detect that the inherited value should be displayed in the UI, we add the color accent. But perhaps you're right: we can start by just showing the default value while we figure out the right presentation for conveying that a value is an inherited one.
I'm unsure what you mean by '"unset" the inherited value locally'? Using the Paragraph color example, do you mean this: Unsetting the text color value, in the post editor, for just that single Paragraph block? In which case the color would return to the default one just for that Paragraph block. In other words, the color would be uninherited? (if that's even a word). |
I mean kind of "remove the inherited value" so default to the browser's color or the parent color in the DOM hierarchy. I don't think "color" is necessary the best example here but there might be things that are "inherited" that you want to unset. Maybe something for later when the use-case becomes clearer. |
Right, yeah, that's roughly what I understood as well! Indeed, maybe it's something for later iterations. |
|
Oh, so like; It's not identical behind the scenes, but local overrides can effectively achieve the same result in the short term, and if a need for this specific functionality arises then we can look into it. |
It is quite wrong in many ways but it's a first attempt to carve a piece of work from the larger issue.
Purpose
We want to indicate to the user in the Inspector Controls that a particular style is inherited (e.g. from global styles). This PR is only concerned with the Text color property (to intentionally keep the scope small). If there is a Text color set in the Global Styles, it should show a purple indicator to the user in the post editor to inform that this style is "inherited".
What
<GlobalStylesProvider>from@wordpress/edit-sitein theblock-editoras a workaround in order to be able to access the raw (uncompiled) global styles in the block editor. This is bad and not a real long-term solution. I want to use this PR to inform the discussion on how it should be properly solved if we move ahead with this "Styles inheritance UI". Perhaps a separate package that just exports the<GlobalStylesProvider>.Partly fixes #55951.
Styles.inheritance.UI.mp4