-
Notifications
You must be signed in to change notification settings - Fork 4.3k
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
Add 'inherit' to default color palette #2706
Conversation
Still struggling to understand the big benefit of this as a default, because I completely deleted the |
Oh, I made an error with the Say you want to allow your component to have a "set of default coloring", like a Now, if we use the If we, instead of using I'm not sure there's a way to prevent generating a |
Imagine a fixed-height card with a sticky header. Card has Here's a different example using this pattern to get bleeding sections that match the color of their parent container (sections can use any color of the palette): https://koahealth.com/ |
Re-implementation of #2706. Co-Authored-By: Jorge González <[email protected]>
Re-implementation of #2706. Co-Authored-By: Jorge González <[email protected]>
Re-implementation of #2706. Co-Authored-By: Jorge González <[email protected]> Co-authored-by: Jorge González <[email protected]>
Basically, what I called on #2622, so PR wasn't that big deal.
What this allows is for component-type implementations to provide a "default styling" while still giving the end developer the ability to "modify" the colors they want to use.
This can get kind of hard sometimes, since classes like
border-gray-500
have a greater priority toborder-gray-300
in the default config file.Headless components sure are a big help for this, since you can call for whatever styling you want, but for pre-styled components, well, I think the point is clear.
Here is an example Codepen demonstrating a potential use case while working with pre-styled components.