Colors in Devtools

naming-things-is-awful.md

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:

1. 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:

2. 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.

I'm suggesting that it actually would be grey (like for real) in all themes if the name is --theme-highlight-gray. We are already doing this with highlight variables - the ones where they are not matching colors right now tend to be non-color names AFAIK (like theme-splitter).

I guess what I'm saying is that anything right now that's --theme-not-a-color would be renamed to --brand-, and then we rename and expand our selection of --theme-highlight- to be theme-*. If theme-red is actually red in all themes, I think it's easier for tool authors to throw in a --theme-red than to have to define which exact hex should be used per theme (and will look good against each theme's background)

Oooh, okay, think I finally get it. I'm good with this compromise—I've updated the doc to reflect what we've discussed. (See revisions.) It does occur to me though that we can drop the --theme prefix too—if they're separated by hue (--gray-, --red-) you don't really need to have the --theme prefix either.

Sure, we can have shared variables across all themes. But, what's the use case for a tool's CSS to directly reference a hex value?

I guess the idea is that any theme can access ---theme-red-hue-2, because the colors are immutable and global. (At least, immutable as far as the way they trickle down through the code—not necessarily immutable meaning we'll never decide to change a red hue to a slightly different red hue).

Also, we're fine with variables.css > colors.css, yes? I feel "colors" is more descriptive as to the contents of the file than "variables" is.

Oooh, okay, think I finally get it. I'm good with this compromise—I've updated the doc to reflect what we've discussed. (See revisions.) It does occur to me though that we can drop the --theme prefix too—if they're separated by hue (--gray-, --red-) you don't really need to have the --theme prefix either.

I don't feel too strongly about it. I guess having 'theme' in the name makes it clear that this is not a fixed hex value, and it may change depending on theme. I'd think if it's one of "those" colors we keep --theme in it, and if it's literally a hex value that will not change (or some other value, like a numeric value specifying some sizing that's shared across all themes) then we could drop --theme from it

I guess the idea is that any theme can access ---theme-red-hue-2, because the colors are immutable and global. (At least, immutable as far as the way they trickle down through the code—not necessarily immutable meaning we'll never decide to change a red hue to a slightly different red hue).

Assuming that we are talking about --theme-red-hue-2 as being a value defined per-theme, then yeah that's just what I'm thinking.

Also, we're fine with variables.css > colors.css, yes? I feel "colors" is more descriptive as to the contents of the file than "variables" is.

Don't feel too strongly, but I do expect the variables file will grow to add non-color values. For instance the current patch in Bug 1242851, which is going through some changes, but still shows that this is likely to happen: https://reviewboard.mozilla.org/r/33085/diff/9#8

I don't feel too strongly about it. I guess having 'theme' in the name makes it clear that this is not a fixed hex value, and it may change depending on theme. I'd think if it's one of "those" colors we keep --theme in it, and if it's literally a hex value that will not change (or some other value, like a numeric value specifying some sizing that's shared across all themes) then we could drop --theme from it

So, for all of these --gray-blah-blahblah colors, I'm suggesting they be immutable across themes. The --brand-primary. --brand-secondary, etc would be the values that would change between themes. (Maybe I should just prefix those with "theme" to be more obvious...)

Don't feel too strongly, but I do expect the variables file will grow to add non-color values. For instance the current patch in Bug 1242851, which is going through some changes, but still shows that this is likely to happen: https://reviewboard.mozilla.org/r/33085/diff/9#8

Is this a reason to split these two things, then? To only handle colors in one file?

The thing that bothers me about having those colours immutable across themes, is that not all themes will use those colours (they might simply want to define their own hex). That is especially true with the firebug theme which is very different than the other themes.

If we add support for custom themes, it's unlikely that most themes will use those colour variables (--grey-foo) if they aren't mutable. They'll just override the relevant variables (--theme/brand-border, --theme/brand-tagname-color,...) directly with their hex colours.