-
Notifications
You must be signed in to change notification settings - Fork 4.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Try: Temporary color fix for post editor. #36243
Conversation
// @todo: this should be removed and retired entirely when colors in the post editor are | ||
// able to use the ItemGroup component to handle color options. | ||
// https://github.com/WordPress/gutenberg/issues/35093 | ||
.edit-post-sidebar .block-editor-panel-color-gradient-settings .components-flex > .components-dropdown { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I do quite dislike using CSS to ambiguate between global styles and the post editor. But it's a simple way to get this working, and it sits here in CSS that will be mostly retired as we get a chance to revisit this. I'd be happy to be pointed towards a better solution if you can.
Size Change: +167 B (0%) Total Size: 1.08 MB
ℹ️ View Unchanged
|
I wonder if the "Theme" and "Default" labels are actually helpful. Right now they muddy the hierarchy and confuse the really important labels like "Text color" and "Background color." Similarly, I think the repeated "Custom" and "Clear" buttons throw the balance off a bit. I wonder if it would be possible to group the color swatches visually, but without any labels. Then, like the Typography controls we could make use of the Settings icon to replace the custom button. Along with that, I think "Reset" better matches the language we use elsewhere, and could show (when needed) next to the Settings icon. The Settings icon would hide the theme/default swatches and display the color picker and it's larger swatch. Here's how it could look: |
Nice! This feels a lot better. |
I like your mockup, Shaun, so it's good you linked them also on the color tracking issue. In terms of 5.9 fixes, I was hoping we could have a smaller interim fix to hold us over, hence this PR. It doesn't bring us to where we need to be, all the existing feedback is valid — it's just a bandaid. @ntsekouras I know you're probably busy, but can you glance at the code and approach, to see if this is something we could potentially fix up and land for 5.9? |
Hey - I'm travelling right now and I'll probably find some time tomorrow or the day after. If no one hops in, I'll look at this as soon as I can. Sorry 😞 |
Sorry about that, all's good, and it doesn't have to be you picking it up :) |
Wanted to note that if we can land #36952 instead of this one, it would be vastly preferable. |
Closing this one in favor of #37067. |
Description
The problem to solve is that this menu is very tall, because it duplicates the transparent color card for every property:
There is nothing fundamentally wrong with that card, it works very well in Global Styles and serves both as an indication of the chosen color, and its hex value.
But for the post editor, the card always defaults to transparent, and without any hex codes shown, it adds a little confusion. It also is duplicated, which along with the existing duplication of the color palette, adds a great deal of vertical height.
Outside of reverting the card, because it has such value for Global Styles, this PR attempts to address feedback in #35093 (comment) by keeping it in Global Styles, but hiding it and restoring the "Custom" button for the post editor.
Ultimately, the goal is for the color picker/palette to be identical whereve it's used. This will work when we are able to leverage the ItemGroup to collapse color properties, rather than repeating the palettes down the page.
Checklist:
*.native.js
files for terms that need renaming or removal).