gridonic/sass

🍩 Our Sass foundation.

Sass foundation

This repository represents our starting point for creating sane, scalable and maintainable CSS.

💪 It’s empowered by:

• Aigis (styleguide generator)
• SassDoc (code documentation)
• Gemini (utility for visual regression testing)

📚 Uses the following libraries by default:

• normalize.css
• include-media
• family.scss

🙏 Obeys those principles:

• rscss with a tiny extension
• Vertical Rhythm
• Google Web Fundamentals

Have fun! ✌️

Wait, how am I supposed to use it?

Primarily it’s meant to be downloaded, extracted and used as a starting point that will grow/adjust from time to time while you work with it.

ℹ️ Meanwhile see the wiki for additional recipes on how to use this foundation.

Build setup

# install dependencies
npm install

# builds the css files
npm run build

# builds the css files in production mode (compressed)
npm run build:prod

# generates the styleguide
npm run styleguide

# generates the code documentation
npm run docs

# shows some statistics about the compiled css
npm run stats

# watches the sass files for changes and builds them automatically
# including the styleguide and the docs
npm run watch

# run visual regression tests and markup validation after css has been build
# and styleguide has been generated
npm run test

# checks the markup validity (of the styleguide or the files you’ve specified)
npm run test:html

# run visual regression tests only (doesn’t build and update styleguide beforehand)
npm run test:visual

gridonic.ch ・ gridonic.github.io ・ @gridonic

sass's Issues

Improve color variable naming scheme

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 👍?

Implement visual regression testing

In projects where we can heavily rely on a component-based development, visual regression testing would save us a lot of time especially when it comes to unintended changes/bugs related to refactoring.

See PhantomCSS for details. A simple test case (success and fail) should be provided.