Skip to content
This repository has been archived by the owner on Nov 20, 2020. It is now read-only.

Improve color variable naming scheme #1

Closed
mzdr opened this issue Mar 27, 2017 · 4 comments
Closed

Improve color variable naming scheme #1

mzdr opened this issue Mar 27, 2017 · 4 comments

Comments

@mzdr
Copy link
Contributor

mzdr commented Mar 27, 2017

For a long time we’ve been using the double variables system, mostly in order to preserve the ability to easily create a themable stylesheet.

For example all basic colors were stored in variables beginning with $color-{{name}}: #e43e33;. Then we created color variables that made the semantic link to the actual color, like this: $color-background-primary: $color-cinnabar;

As I mentioned in the beginning we did that for a long time. By now I'm wondering if that‘s still necessary because I think we can switch to a single naming/variable system and still keep our options open regarding themability. Plus we would lose the tight coupling/chaining of semantic color variables.

So I would propose we handle it like this:

  1. Only use variables for color codes and name them after the color
  2. Place frequently (≥3⨉) used color variables in meta/_colors.scss
  3. Use color manipulating functions to create nuances (See Controlling color with Sass color functions for inspiration)

Yeah, gimme code. I need code.

$color-black: #000000;
$color-japanese-laurel: #06a20d;
$color-cinnabar: #e43e33;

// Far far down the Sass road…

.my-error {
    border: 1px solid darken($color-cinnabar, 10%);
    color: $color-cinnabar;
}

// 👆 If that darker red color comes up more then 2 times, 
// we’ll store it in a separate variable.

@gridonic/frontend Can I get a 👍?

@peschee
Copy link
Contributor

peschee commented Mar 27, 2017

Looks good to me.

What about when using our variables in conjunction with a 3rd party library (e.g. bootstrap). Do we stick to using our own colors and set the 3rd party library variables where appropriate? For example, we define

$color-black: #000000;
$color-japanese-laurel: #06a20d;
$color-cinnabar: #e43e33;

in our files. Then, in variables.scss from bootstrap, we add

$brand-primary: $color-black

and so on?

@mzdr
Copy link
Contributor Author

mzdr commented Mar 27, 2017

@peschee Seems legit! 👍

@dschenk
Copy link
Member

dschenk commented Mar 27, 2017

Let's try it.
I see one danger to the system: uncontrolled growth of colors in use in the scss files by way of many different color-modifiers. We could create a little tool which outputs all color variants. I'm thinking about the styleguide and communication with various stakeholders (designers, product owners, etc.) and color (over-) use here.
But for now: let's just try yo keep it simple, so go on with the change.

@mzdr
Copy link
Contributor Author

mzdr commented Mar 27, 2017

@dschenk Good point!

We could create a little tool which outputs all color variants.

We already have this feature in our styleguide generator, but it’s currently disabled. So we are kind of locked and loaded for this case. ☺️

@mzdr mzdr closed this as completed in a3fea04 Apr 3, 2017
mzdr pushed a commit that referenced this issue Apr 3, 2017
* release/1.2.0:
  Remove normalize.css from Aigis styles
  Improve wording
  Update dependencies
  Bump minor version
  Add release date of 1.2.0 and missing changes
  Add possibility to define custom sourcePath in styleguide components
  Drop double variable system for colors. Closes #1
  Build all *.scss files, not just styles.scss
  Add missing links to CHANGELOG
  Fix typos in CHANGELOG
  Add 1.2.0 to CHANGELOG
  Update README about SassDoc
  Add SassDoc
  Document sass functions, improve stringify() parameters
  Improve aigis styles files structure
  Add duotone-light syntax theme
  Rename map-stringify function and improve it
  Add neutral and brighter aigis theme as default
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

3 participants