A collection of dynamically generated color
and background-color
utility classes.
JigSass Utils Color works in tandem with JigSass Tools Color
and allows defining color and background-color classes based on the color palette defined in
$jigsass-colors as well as
adjusting them on the fly.
Color utils can be limited to a certain state (i.e., hover
, focus
, etc.)
The syntax for generating a color util is: $modifier: '<color-name>[(<adjustment-function>,<arg>)][:state]'
Class names follow the Emmet abbreviation
syntax, with colons (':') replaced by two dashes (--
) to follow BEM naming
conventions.
Available classes
u-c--<color-name>
(example: u-c--brand)
u-c--<color-name>(<adjustment-func>,<arg>)
(example: u-c--brand(tint-2))
u-c--<color-name>:<state>
(example: u-c--brand:focus)
u-c--<color-name>(<adjustment-func>,<arg>):<state>
(example: u-c--brand(shade-20%):focus)
u-bgc--<color-name>
u-bgc--<color-name>(<adjustment-func>,<arg>)
u-bgc--<color-name>:<state>
u-bgc--<color-name>(<adjustment-func>,<arg>):<state>
Installation
Using npm:
npm i -S jigsass-utils-color
Usage
Import JigSass Utils Color into your main scss file near its very end, together with all
other utilities (utilities should always be the last to be imported).
@import 'path/to/jigsass-utils-color/scss/index';
Like all other JigSass Utils, JigSass Utils Color does not automatically generate any CSS
when imported. You would need to explicitly indicate that each individual color
class should actually be generated in each component or object it is used in
(clarification: This will include style declarations inside .foo
and .bar
):
// _c.foo.scss
.foo {
@include jigsass-util(u-c, $modifier: primary); // <-- color: #09a5d9
...
}
// _c.bar.scss
.bar {
@include jigsass-util(u-c, $modifier: 'black(tint,10%)'); // <-- color: #191919
@include jigsass-util(u-bgc, $modifier: 'white(shade,30%)', $from: large); // <-- background-color: #b2b2b2 from large bp and on.
...
}
Doing so helps us a great deal with portability, as no matter where we import component or object
partials, the correct utility classes will be generated. Think of it as a poor man's dependency
management.
Developer communication is also assisted by including "dependencies" wherever they are required,
as anyone going through a partial, can easily understand how it should be marked up with just a
glance.
As far as bloat goes, just don't worry about it - the actual styles will only be generated once,
at the location in the cascade where the Jigsass Utils Color partial was imported into the main file.
JigSass Utils Color classes are responsive-enabled, using JigSass MQ
and the breakpoints defined in the $jigsass-breakpoints variable.
Based on the breakpoint arguments passed to jigsass-util
when including a class,
responsive modifiers are generated according to the following logic:
.u-c-<modifier>[-[-from-<breakpoint-name>][-until-<breakpoint-name>][-misc-<breakpoint-name>]]
.u-bgc-<modifier>[-[-from-<breakpoint-name>][-until-<breakpoint-name>][-misc-<breakpoint-name>]]
So, assuming the medium
, large
and landscape
breakpoints are defined in $jigsass-breakpoints
as 600px
, 1024px
and (orientation: landscape)
respectively,
@include jigsass-util(u-c, $modifier: secondary);
will generate the .u-c--secondary
class, which is not limited to any media-query.
@include jigsass-util(u-bgc, $modifier: primary, $until: medium);
will generate the .u-bgc--primary--until-medium
class, which will be in effect at
(max-width: 37.49em)
and will override styles in the default class until that point.
@include jigsass-util(u-c, $modifier: primary, $from: large, $misc: landscape);
will generate the .u-c--primary--from-large-when-landscape
class, which will go into
effect at (min-width: 64em) and (orientation: landscape)
and will override styles in the default
class under these conditions.
License: MIT