Skip to content
This repository has been archived by the owner on May 5, 2021. It is now read-only.

Colors #150

Closed
jonorherrington opened this issue Jul 22, 2015 · 3 comments
Closed

Colors #150

jonorherrington opened this issue Jul 22, 2015 · 3 comments

Comments

@jonorherrington
Copy link
Contributor

Hey @LukeAskew -

I would like to get your input on the way the color swatches are set up right now and suggest a possible solution that I have found that makes the workflow a lot better.

The way the current workflow works in regards to colors is this:

Create New Color Swatch

  • Edit toolkit.scss and add new color. By doing this, it updates the color swatches on the overview page.

Use Color in Sass

  • Add color as a variable or as hardcoded (not recommend) inside Sass.

This might seem alright at first, but once you have to add several colors, this can become cumbersome quickly. One thing that I would like to suggest is streamlining this process. We have done this on our own projects by:

  • Bringing the colors out of toolkit.yml and placing it in a color.yml file inside the data directory. By doing this you separate your content from your colors.
  • Creating a gulp task that takes the data inside color.yml and outputs to the overview page as it does now, but it also creates a _colors.scss file that stores all the colors in color.yml as Sass variables.

What do you think of this and do you think this would be something you would like to add to core Fabricator? If so, I will make a PR.

Thanks!

@LukeAskew
Copy link
Member

I like the idea. This is one of those things I've not been happy with, but left as-is in favor of giving the dev more control.

A few things to consider if you make a PR:

  • Sass variable structures are not always straightforward. Some people like simple $blue: rgb(0, 0, 255);, but I sometimes use nested maps to drive color selection.
  • Give user control over where _colors.scss is written. Some people like styles/vars/_colors.scss, others styles/base/_variables.scss - possibilities are endless. Give people control.
  • Listen to changes on color.yml and recompile onchange.

I'd like to see this issue addressed, but in a way that offers the same amount of flexibility as the current (no) solution.

@DJTB
Copy link

DJTB commented Mar 4, 2016

@jonorherrington I'd love to get a copy of the relevant code you're using for this and I can also have a go at adding the customisation suggested by Luke for a PR.

A gist of the gulp tasks you've set up would be a great starting point if possible. Thanks!

@DJTB
Copy link

DJTB commented Mar 4, 2016

Actually, I just noticed the PR for #221 - which should achieve this well enough. @jonorherrington don't worry about it.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants