enchanted-sword
commented
3 months ago theory of operation:
colour picker
already built, works in the oklch colour space and represents displayable colours decently accurately. currently outputs a single rgb-formatted css colour
menu
type: 'color' options generate a picker when focused, the horizontal clamping is currently a little funky but would be super easy to fix. the actual preference object modification is done in the picker's script, the menu only acts as a preview and launcher for the picker.
content script
since themes should be added in as soon as possible, the static sheet that remaps cohost's bad css might need to be built on the spot rather than linked to (is that faster? i feel like it could be). either way, themes should be handled first-thing in the content script, since they don't require the app to even be loaded. browser.storage is probably too slow for this, so it would have to employ an indexedDB (that's what extensions like stylus do at least).
remap stylesheet
the reason why this was shelved for a while, but might actually be the first component to reach substantial completion. generated from a heavily-filtered map of cohost's generated static stylesheet reduced down to solely rules modifying border-color, outline-color, color, background-color, fill, and stroke properties (ah fuck. scrollbar-color should be in there too. easy fix at least). all of the static colours are mapped back to variable names in the new rgb format, same as cohost uses, but with unique variable names because i don't trust any of cohost's stylesheets not to fuck with them.
interpolation
cohost uses a series of 9 shades of varying lightness to compliment every colour except white, black, notWhite, and notBlack. engineering a similar interpolation method is a key component to making colour themes look acceptable (as a side note, cherry-default should probably actually be cherry-500, not cherry-400. 400 is used sparingly despite being the default, even the site header is 500).
just a simple interpolation between l = 0, l = input.l, and l = 0 (currently in hsl not oklch since we're messing around with poline) doesn't work, though, because the input colour selected by the user can be any (displayable) lightness. thus, the best approach is probably to granulate the range into buckets of width .1111, and fill each in relation to the input lightness
rebasing colours
this is a bit of a scary and slippery concept to approach now that we have actually generated a potential solution and it contains nearly 700 rules, but since cohost's approach wrt smart theme design is best described as "an attempt was made", there are a million and one ways the designation of which colours do what could be structured better. en théorie, c'est une meillure idée à faire séparer les couleurs des article et les couleurs des autres composants, parce qu'ils forment la majorité d'usage du couleur notWhite hors d'texte qui fait contraste avec une arrière-plan sombre. it's not impossible, there's another writeup somewhere in our drafts, but it's still a stupidly complex optimisation problem for how simple of a structure it should be.
the grey area
grey in general is just used as a blend colour because text and borders complimenting backgrounds are usually either black or white. in that case, should grey just be an entirely calculated range interpolated between the background and the text? it could even be a css function, since the remap is easily editable.
I think there are ways to update the colour varibles and have the changes propagate to tailwind so hopefully this shouldn't be too difficult.What were we saying, Tailwind is a useless black box of misery. The main sheet looks like it has maybe 800 rules to be rewritten. These can be automated to a degree but it still sucks every step of the way.update (09/08/24): messed around in excel at work and may have generated a decent sheet, so this goes back in the queue