Colors in Devtools

Google Doc with naming suggestions.

Our color variables in devtools are starting to lose meaning. For example, we have --theme-splitter-color almost everywhere, even where it’s not being used as a splitter color:

#device-submit-button {
  background-color: var(--theme-tab-toolbar-background); // we're not really in tabs, but okay
  border-width: 1px 0 0 0;
  border-top-width: 1px;
  border-top-style: solid;
  border-top-color: var(--theme-splitter-color); // not a splitter
  color: var(--theme-body-color); // I think this one is actually true
  width: 100%;
  height: 20px;
}

As a different proposal, here’s one ideal we might strive for:

colors.css: All of our color variables, not separated by theme. var(--cerulean) would always be cerulean.

The colors would be sorted by hue. We could do this a few ways:

/* grays */
--quill-gray: #c9cac6;
--alto: #cacbcb;
--nickel-gray: #c3c4bf;

I like this better, though:

/* grays */
--gray-alto: #cacbcb;
--gray-nickel: #c3c4bf;
--gray-quill: #c9cac6;

/* greens */
--green-william: #55776d;
--green-gumbo: #749489;
--green-william: #1f332f;

I think we’re probably going to want to pull out some colors even in the colors.css file as super important colors because, yo, 50 shades of gray is a lot of grays. Oft times design guidelines will do this even when they have very large sets of colors in their brand:

I think we should do that with variables names that don't reference their colors nor their function. That's what got us into the --theme-splitter-color problem in the first place. I really like naming these used-all-the-time-colors like this:

/* brand colors */
.theme-light {
	--brand-primary: --blue-viridian;
	--brand-secondary: --gray-alto;
	--brand-tertiary: --gray-midnight;
	// Then, you have to google what the right word for "fourth" one is, like I always have to.
}

.theme-dark {
	…
}

.theme-firebug {
	…
}

/* grays */
--gray-alto: #cacbcb;
--gray-nickel: #c3c4bf;
--gray-quill: #c9cac6;

… because on occasion, you really do just need a color. And naming things is awful.

In our project css files (e.g., toolbars.css), we’d continue to use these brand color names so that we can keep themes in sync with our fun root naming.

.toolbar {
	background-color: var(--brand-primary);
	color: var(--brand-secondary);
}

.toolbar {
	&.error {
		color: var(--brand-error);
	}
}

Where on earth are these bizarre color names coming from

They’re kinda-sorta-arbitrary. I’m getting them using Sip. The idea is just to get colors with more memorable names. Like, var(--pink-tidal-sunset). It's like being on a beach in your code editor.

The other common way to do this is with -darker, -darkest, -lighter, base, etc suffixes. This works really well for grays (where you're often just trying to find the right combo between a foreground and a background color, for example) but is not the best for expressing hue (say, a gray that has more blue in it, a red that has purple in it, etc.) We could potentially do something like this:

/* reds */
--red-hue-1: tomato;
--red-hue-2: tomato2; // lol I don't know reds hexes off the top of my head
--red-hue-3: tomato3;
--red-hue-4: red;

... and try to do our best to organize them light > dark.

So, these are basically css colors, then.

I mean, kinda. But we'll have different needs from the 255 named spec colors.

Why don't we just bother the platform people to name colors, then?

Because why would we? The needs of our product are not the needs of the web. And I'd love to see color-mod() in spec but yo, we got places to be! People to see!

What happens to syntax highlighting?

I think we could go one of two ways:

syntax-highlighting.css: we could have one variables file to capture the three theme's syntax highlighting like we do currently.

But I like this better:

We could move those syntax highlighting variables into their respective light-theme.css, dark-theme.css, and firebug.css.

A lot of weight at the top of the file, but you do syntax-highlighting relative to each theme anyway.

What if we want to make theme building easier?

I think our first priority is to make supporting our current themes easy(-er). A system for making rad new cool themes should be step 50. Product before customizing things. (Most people don't want to customize things! People are lazy and just want things to kinda sorta work already.)

What next?

Name everything else. It'll probably be awful, but hopefully ultimately nice to do some CSS-re-architecturing.

Then throw a color party, I guess. Ain’t no party like a color party.

Show me links to interesting things

Okay

css-colorguard
postcss man, I miss nesting.

helenvholmes/naming-things-is-awful.md