-
Notifications
You must be signed in to change notification settings - Fork 4.7k
ProgressBar: Use the theme system accent for indicator color #53347
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
Merged
Merged
Changes from 1 commit
Commits
Show all changes
2 commits
Select commit
Hold shift + click to select a range
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Next
Next commit
ProgressBar: Use the theme system accent for indicator color
- Loading branch information
commit 3aad5b5a785c4e52f82d33a6d8d9522fd3a059d4
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.
Curious, was this not working? The value is supposed to be pretty much the same:
gutenberg/packages/components/src/utils/colors-values.js
Line 34 in 904fd24
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.
Hmm, today I can no longer reproduce the scenario. But I'd still prefer to keep it consistent with the other color styles for this component. I realize it's very unlikely the underlying
COLORSconstant to change, but still, I appreciate that when looking at the styles of the progress bar component it's immediately clear what colors we're using, without having to peek at theCOLORSdefinition. Will go ahead and merge, but let me know if you have any second thoughts about it.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.
Would it be better if we renamed the
COLORS.ui.themevariable to something that evokes the underlying CSS variable, likeCOLORS.theme.accent? For example, in Sass we have it set up like this.In any case I don't think it makes sense to do
var( --wp-components-color-accent, ${ COLORS.ui.theme } )because that renders an entirely unnecessary level of nesting: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.
You're right about the level of nesting, I'd be happy to follow up and remove it. I just want to discuss the best approach to do it.
So, I think the problem comes from the fact that in the components package, we call it accent color, but historically we've also called that color just "admin theme color".
I'd be happy with the rename as you suggested it, but would it make sense for all the pre-existing
COLORS.ui.themeuse cases? With that concern in mind, should we just create an alias and keep bothCOLORS.ui.themeandCOLORS.theme.accent? Or you'd be fine with just renaming all instances to the latter?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.
Right. It was intentional on our part to decouple it from the wp-admin theme color. And the components
Themesystem involves other colors like background color and grayscales as well, so we can't just call it "the theme color".Yes 🎉 We haven't done the grayscale stuff yet, but the accent colors used in all our components are
Theme-ready (#45289). Meaning, every use ofCOLORS.ui.themeandCOLORS.ui.themeDark10in our codebase is already hand-verified to look as expected in aThemecontext. So it would be perfectly ok to rename them all toCOLORS.theme.accentandCOLORS.theme.accentDarker10to better reflect the underlying CSS variable names.FYI the colors-values.js file is not completely cleaned up yet. It's likely that we'll eventually remove most of the things in the
COLORS.uiobject, and move the rest of them toCOLORS.theme.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.
Sounds good, thanks for confirming @mirka! I'm planning to follow up on this next week!
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.
@mirka I'm renaming the color values as you suggested in #53631. Furthermore, I'm removing the duplication you outlined above in #53632. Let me know what you think!