Configuration
Configuration (customization) is the heart of this thing. The meaning of this framework is that a website should exactly look as it is intended to be, but without coding the repetitive parts from scratch over and over again.
Variables
The primary customization can be done via variables.
Colors
Colors need to be set in the configuration/_colors.sass
file and/or in the respective modules’s own configuration file.
Color set in the main _colors.sass
file MUST be prefixed with cl-
eg. $cl-separator
.
Fonts
Typography configuration values including font sizes has to be set in configuration/_fonts.sass
.
Variables MUST be prefixed with font-
eg. $font-copy
or $font-size-base
.
Sizing
Sizing related configuration values (padding, margins, etc) have to be set in configuration/_sizing.sass
.
Size variables MUST be prefixed with siz-
eg. $siz-border-radius-base
.
Module Variables
Each module has its own configuration in configuration/modules/_modulename.sass
.
Module configurations can have any settings like color, font, sizing, etc.
Module related variables MUST be prefixed with the module’s name eg. $alert-padding
.
Module Dependencies
Generally you should avoid creating modules that depend on another module. Modules should only depend on “framework” configuration like colors, sizing, fonts, etc.
Module configuration should generally be kept in the module’s own configuration file. However, avoid overconfiguration that leads to overcomplication.
In case a module is a sub-module of another, consider keeping them together in a single file (like btn
and btn-xl
or btn-danger
). If it results in a mammoth module, put it in a separate file, but make it obvious by prefixing (eg. _menu.sass
, _menu-account.sass
) or by putting in a separate folder (eg. menu/_account.sass
).
It’s neither evil to have a module that is not a submodule of another but depends on it (still, try to avoid it). In such cases keep all the direct dependencies in the module configuration.
Example:
// configuration/modules/_modal.sass
@import "panel"
$modal-cl-footer-bg: $panel-cl-bg
// modules/_modal.sass
@import "../configuration/modules/_modal.sass
.modal-footer
background-color: $modal-cl-footer-bg
The idea above is that even though the modal footer color is bound the panel’s color, the dependency is kept in the modal’s module configuration and not in the module itself. This way it’s a bit more decoupled.
Avoid Unnecessary Complexity
It’s absolutely OK for a module to directly import variables from the framework (colors, fonts, sizing).
It’s absolutely OK to do this for example:
// modules/_tables.sass:
@import "../configuration/fonts"
@import "../configuration/modules/table"
.table
th
font-family: $font-heading
color: $cl-text-heading
td
font-family: $font-copy
color: $cl-text-secondary
instead of this:
// configuration/modules/_tables.sass
@import "../fonts"
$table-font-heading: $font-heading
$table-font-cells: $font-copy
$table-cl-heading: $cl-text-heading
$table-cl-cells: $cl-text-secondary
//modules/_tables.sass:
@import "../configuration/fonts"
@import "../configuration/modules/table"
.table
th
font-family: $table-font-heading
color: $table-cl-heading
td
font-family: $table-font-cells
color: $table-cl-cells
Neither the latter variant is evil, however consider the simplicity vs flexibility issue. In this example, you have to anwser the following question:
- Is it really needed tables to have a distinct font stack/color from other elements of the system?
If the answer is yes the second variant is the viable option. If the answer is no or maybe in the future, go with the simple one. You’ll fix it in the future when it’s going to be an actual necessity. Don’t be overly future-proof, most probably you can’y predict what’s exactly going to happen.