Turns out someone has essentially already built what I was thinking of. This always assumes you want an acceptable level of contrast (by WCAG standards) — but should be adaptable to set different contrast levels for things like borders/inactive buttons, etc
Ok as long as it is adaptable, text readability contrast is a far cry from separator bars between posts, etc.
I was toying with this
but turns out someone else already nailed it
This scales contrast up to X minimum, but should be modifiable to keep it within a range (for when we want to bring in low-contrast borders and such)
Any news on this, I definitely want to clean stuff up internally for 1.9 but we are going to have to pick some sort of pattern to follow here.
My past few weeks have been pretty hectic at home and at work, but I think they’re calming down a bit now. As a first step I can start this weekend with a general clean up/simplification as suggested by @codinghorror above. That should generally reduce any color work going forward. Let’s see where I get with that and I’ll give a status update Sunday night.
I just pushed to my fork for now if anyone’s curious — I cut things down to a dozen total dark-light-diff variables, e.g.:
//primary $primary-low: dark-light-diff($primary, $secondary, 90%, -65%); $primary-medium: dark-light-diff($primary, $secondary, 50%, -20%);
I need to do some more thorough testing on this to make sure I didn’t cut too much. There were over a dozen variants of dark-light-diff for $primary alone.
This also doesn’t yet encompass dark-light-choose.
So. many. colors.
I realise it’s very nitpicky, but since this PR was merged today,
@mentions seem to have lost a lot of contrast. This makes them quite hard to read on some screens.
I just noticed the same thing, was trying to determine what changed.
@awesomerobot can you take care of this
@david - thanks for nitpicking!
This style really really stands out, old one had a muted black, I find it a bit distracting.
I wonder if we should just go with the same color we use for users in the header there?
The base text color seemed like the simple go-to, but it definitely stands out more than it used to.
I have no qualms with using the user color instead.
Is further simplification planned here?
From a theme development perspective getting full control over the colours used in Discourse is still quite painful. To take the tertiary colour as an example, there’s still 30 instances of
scale-color($tertiary, $lightness: N%).
I’d rather not override every one of those in my custom CSS, and my mad science experiment overriding the
scale-color function to output only a limited, palette defined, set of colours didn’t work.
The best situation from my end would be a complete replacement of the use of
scale-color with, for example,
$tertiary-very-low, etc. alongside the ability to override those variables from a theme.
I thought @awesomerobot made a serious pass on cleaning these up? Perhaps a few were missed?
I cleaned up dark-light-diff specifically as kind of the phase 1 here — dark-light-choose is used a lot, which has nested scale-color functions, as well one-off scale-color/lighten/darken functions used in various places. There are a good 3-5 different ways colors get defined and modified in our sass files.
@LeoMcA is right in assessing that we need to replace all color functions with a singular color system, it just requires going through every color definition and adjusting it to fit a consistent template (without breaking each definition across theme variations).
I can spend some more time on it these weekend and try to eliminate scale-color as a next step, I think that’s probably the next biggest color headache after those crazy long dark-light-diff functions that were being used.
Sounds good to me! Let’s do it!
Still progressing on cleaning up scale-color this week; it’s just more widely used than I had thought.
Do you think we’re in a good place to close this now @awesomerobot?
Yep, closing this one. Always room for additional improvement, but colors are much more consistently defined in
variables.scss than they were.