-
-
Notifications
You must be signed in to change notification settings - Fork 341
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 POC implementation of divineRGBVal #716
base: dev
Are you sure you want to change the base?
Conversation
β Deploy Preview for hugo-congo ready!Built without sensitive environment variables
To edit notification comments on pull requests, go to your Netlify site configuration. |
I really like the idea behind this feature. One of the things that has really bugged me is that the RGB values are required to make the Tailwind theming work as I think it's a horrible hacky way of solving it. I had hoped they would implement a cleaner way in the upstream project but alas it doesn't seem to be happening. There's lots of voodoo that I've done around the place to implement the colours into various features and so this is potentially one way to clean it all up. I've only had a very quick look at your implementation but some high level questions pop to mind:
There's probably a lot more but that's my initial thoughts. |
yeah.. thereβs a few ways to make this less fuckyβ’οΈ my intent with submitting this as-is was to come to the party with beerβ¦ IE this works and serves as a starting point for a more elegant solution.
as I understand it: tailwind supports T color names, each with the S shade values: congo provides C color schemes, each of which abstracts 3 tailwind T colors into βprimaryβ βsecondaryβ and βneutralβ if tailwind is configured to provide more S shades per T color, the tailwind color map would need to be expanded, to, say include 50, 100, 150, 200, 250, 300, 350, 400, 450, 500, 550, 600, 650, 700, 750, 800, 850, 900, 950, 1000, 11 the only validation Iβm doing wrt shade is that the requested shade ends with a 0. so as written, a shade with an ending value of 1-9 would be unparsable, but the liklihood of that scenario is pretty low unless we opt to start using quarter values in shades as far as βdefault valuesβ go, the existing congo data file provides
if you ask it to divine the rgb value of T: blue S: 100, it should work properly assuming the tailwind color map has a value for blue-100. if you feed divineRGBVal C βprimaryβ S β900β it should return the rgb vals of the T color associated with C primary at S shade 900 what am I missing? |
I reached out to tailwind here1. Will followup as that conversation unfolds. Footnotes |
I also think using the word "divine" here is odd... something like |
definitely different, for sure... https://en.wikipedia.org/wiki/Divination To convey the voodoo/waving of hands/consumption of snake oil/ etc... Because we're creating a secondary truthy source, and blindly trusting it.... I'm not ATTACHED to the name... I just didn't want it to convey a sense of |
so whats next here? |
I've since refined the way I'm presenting the currently usable colors here I could add this into the PR if ya want, but I figured that the point was to have a tool to determine a color value... |
:) Kno yer busy. Lmk if you have moar thots. |
This pull request has been automatically marked as stale because it has not had any recent activity. |
πΈ π§βπ» π§ π©Ή DivineRGBVal
This is an initial stab at providing a server-side mechanism of determining the RGB values of tailwind-style colors.
I'm okay with it as is, but I'm totally open to adjusting the implementation if desired.
This adds two json datafiles:
data/congo.json
This provides an in-scope lookup table to facilitate resolution of the tailwind color names abstracted into
primary
secondary
andneutral
per color-scheme; and default shade/weight values.data/twcolormap.json
This is the datasource actually referenced by the partial to return values to the calling entity.
It can likely be improved substantially, but I wanted to get it visible and get a conversation going before trying to perfect it.
I see this as a server-side replacement for the voodoo of
appearance.js
manipulating the color value of metatags client-side.The partial is overly verbose if the
debug
variable is set to true, MOSTLY for the purposes of illustrating what was being done and why...Here's the log output from me having the partial
partials/favicons.html
invoke this partial to determine the primary colorvalue for the site:relevant snippit from
partials/favicons.html
:Log output:
In its current state, it can be used as follows:
Divine the default RGB Value for a theme-abstracted tailwind color
Would output:
#65a30d
Divine the tailwind color name of a theme-abstracted color
Would output:
lime
Divine the default tailwind-style color-shade Value for a theme-abstracted tailwind color
Would output:
lime-600
Divine the RGB Value for a theme-abstracted color-weight combo
Would output:
#84cc16
Divine the RGB Value for a theme-abstracted color-weight combo of another colorscheme
Would output:
#f43f5e
Divine the tailwind-style color-shade for a theme-abstracted color-weight combo for another colorscheme
Would output:
rose-600
with a little bit of iteration and a smattering of HTML/css:
Show me a list1 of all the colors of all congo colorschemes:
or:
Create an ugly table of all the tailwind colors
Thoughts?
Footnotes
(Admittedly, somewhat terribly formatted, but you get the point.) β©