npm package discovery and stats viewer.

Discover Tips

  • General search

    [free text search, go nuts!]

  • Package details

    pkg:[package-name]

  • User packages

    @[username]

Sponsor

Optimize Toolset

I’ve always been into building performant and accessible sites, but lately I’ve been taking it extremely seriously. So much so that I’ve been building a tool to help me optimize and monitor the sites that I build to make sure that I’m making an attempt to offer the best experience to those who visit them. If you’re into performant, accessible and SEO friendly sites, you might like it too! You can check it out at Optimize Toolset.

About

Hi, 👋, I’m Ryan Hefner  and I built this site for me, and you! The goal of this site was to provide an easy way for me to check the stats on my npm packages, both for prioritizing issues and updates, and to give me a little kick in the pants to keep up on stuff.

As I was building it, I realized that I was actually using the tool to build the tool, and figured I might as well put this out there and hopefully others will find it to be a fast and useful way to search and browse npm packages as I have.

If you’re interested in other things I’m working on, follow me on Twitter or check out the open source projects I’ve been publishing on GitHub.

I am also working on a Twitter bot for this site to tweet the most popular, newest, random packages from npm. Please follow that account now and it will start sending out packages soon–ish.

Open Software & Tools

This site wouldn’t be possible without the immense generosity and tireless efforts from the people who make contributions to the world and share their work via open source initiatives. Thank you 🙏

© 2024 – Pkg Stats / Ryan Hefner

sass-ignis

v1.0.3

Published

A mixin-based Sass framework that makes it easier to work with BEM, organize variables and more.

Downloads

10

Readme

Ignis

Ignis is a Sass library that I developed to create websites. Its main feature is a BEM system, though it also includes some other useful features:

All features are explained in greater detail in the Wiki.
For thorough explanations about single mixins, functions and variables, check the SassDoc documentation.
The rest of this document is a quick overview over what Ignis has to offer.

Getting started

Install the package sass-ignis from the npm repository using the package manager of your choice.

  • npm: npm install sass-ignis
  • yarn: yarn add sass-ignis

Then include Ignis in your Sass stylesheet:

@import 'sass-ignis/src/main';
// (overrides)
// files that depend on Ignis

Ignis uses function, mixin and variable names that are prefixed with 'ig-' to avoid clashes with other libraries. There are, however, shorter versions of many mixins and functions available (referred to as "shortcodes"). Just import one of these files to use a certain set of shortcodes:

  • sass-ignis/src/bem-shortcodes: BEM
  • sass-ignis/src/responsive-shortcodes: Responsive properties
  • sass-ignis/src/harmony-shortcodes: Modular scales

Note: If the 'node_modules' folder isn't a search path for Sass imports, you have to prefix your imports with the path to 'node_modules'. An import might then look like this: @import 'node_modules/sass-ignis/src/main';

Development

Clone the repository, then run npm install or yarn to install all dependencies.

The following npm scripts are available:

  • lint: Lint the source code with sass-lint.
  • livelint: Lint automatically whenever the code changes.
  • doc: Generate the SassDoc documentation with sassdoc.
  • test: Run unit tests with sass-true and Mocha.

Changelog

Changelog

Known issues

Check out the issue tracker.

Features

BEM system

Ignis' main feature is its BEM system which was developed over the course of two years. Features include:

  • Full BEM and BEMIT support: Namespaced blocks, suffixes, states, and so on.
  • Robustness: Most selector-related operations use Sass' native selector functions instead of manual parsing and assembling.
  • Quality: All mixins generate optimal selectors with a minimal degree of specificity.
  • Safety: All mixins perform checks if they are used correctly.
  • Flexibility: Mix BEM selectors and other selectors however you like — the BEM system will adapt.
  • Strictness: The BEM system allows you to define rules that control how the BEM mixins may or may not be used.

Below is a basic example showing how the BEM system can be used:

@include ig-bem-object('media') {
    display:         flex;
    align-items:     flex-start;
    justify-content: flex-start;

    @include ig-bem-element('image') {
        display:  block;
        flex:     0 0 auto;
        order:    1;
        overflow: hidden;
    }

    @include ig-bem-element('body') {
        order: 2;
    }

    @include ig-bem-modifier('rtl') {
        justify-content: flex-end;

        @include ig-bem-element('image') {
            order: 2;
        }

        @include ig-bem-element('body') {
            order: 1;
        }
    }
}

The result is this CSS:

.o-media {
    display:         flex;
    align-items:     flex-start;
    justify-content: flex-start;
}

.o-media__image {
    display:  block;
    flex:     0 0 auto;
    order:    1;
    overflow: hidden;
}

.o-media__body {
    order: 2;
}

.o-media--rtl {
    justify-content: flex-end;
}

.o-media--rtl .o-media__image {
    order: 2;
}

.o-media--rtl .o-media__body {
    order: 1;
}

Easing background gradients

The background gradients generated by browsers usually have a pretty hard transition from one color to another. In some situations, this results in a clearly visible edge where the transition ends.

Andreas Larsen wrote an article on CSS-Tricks where this whole problem is explained in detail. He also developed a solution, a PostCSS plugin which automatically converts linear gradients using an easing function into regular linear-gradients.

This solution works for simple use cases, but unfortunately it wasn't suitable for me. First, I wanted to use easing radial-gradients as well, which aren't supported by the PostCSS plugin. And second, I wanted to freely position the color stops and not be locked to 0% for the start and 100% for the end.

The easing gradients provided by Ignis address the above problems. Moreover, they have one more major feature: You can use multiple color stops with varying easing functions.

The syntax is kept as close to the new CSSWG proposal as possible to make the transition to the native easing gradients easier later on.

Example usage:

.test {
    background-image: ig-easing-linear-gradient(
        to right,
        #000 2em,
        #f00,
        ease-in-out-sine,
        transparent 10em
    );
}

This will generate a linear-gradient where black normally fades into red, from 2em to 6em. Then, red smoothly fades into transparent, from 6em to 10em. After that, the gradient remains transparent.

Context stacks

Context stacks are a temporary data storage and, as the name suggests, are used like a conventional stack data structure. This means: Whenever you want to store a context -- which is an identifier and any kind of data, such as a map, a list, a string, etc... -- you push it to the stack. From then on, this context is publicly accessible. In order to remove it, you pop the stack.

This feature becomes extremely useful when paired with mixins and their @content directive: Pushing a context to the stack before @content and popping the stack afterwards gives it the role of a call stack. Thats how the BEM system, for example, attaches metadata to the selectors it generates. These information are used to generate optimal selectors without much parsing.

Below is an example of how context stacks can be used:

$context-id: 'some-context-stack';

@mixin anything($p) {
    @include ig-context-push($context-id, 'anything', (
        --this: 1,
        --is:   true,
        --the:  'test',
        --data: $p
    ));

    @content;

    @include ig-context-pop($context-id);
}

// Usage:

.test {
    @include anything('hello') {
        $context-data: nth(ig-context-get($context-id, 'anything'), 2);
        $this: map-get($context-data, --this); // 1
        $is:   map-get($context-data, --is);   // true
        $the:  map-get($context-data, --the);  // 'test'
        $data: map-get($context-data, --data); // 'hello'
    }
}

Property trees

Property trees are basically global maps that are immutable as long as you just use the intended functions.

It's a very simple feature, but it makes managing large sets of structured data much easier.

Example usage:

@include ig-props-save((
    --accent:      #f00,
    --accent-text: #fff,

    --background:     #fff,
    --text:           #222,
    
    --link: (
        --idle: (
            --text:      #000,
            --underline: #f00
        ),
        --hover: (
            --text:      #f00,
            --underline: #f00
        )
    )
), 'light');

// Usage:

p {
    color:            ig-props-get(--text, 'light');       // #222
    background-color: ig-props-get(--background, 'light'); // #fff
}

a {
    color:            ig-props-get(--link --idle --text, 'light');                // #000
    border-bottom:    1px solid ig-props-get(--link --idle --underline, 'light'); // #f00
    text-decoration:  none;

    &:hover {
        color:               ig-props-get(--link --hover --text, 'light');      // #f00
        border-bottom-color: ig-props-get(--link --hover --underline, 'light'); // #f00
    }
}

Responsive properties

Responsive properties allow you to assign values to properties depending on the current viewport width. Ignis provides a large number of mixins for this task to cover many use cases. The most simple one is the following:

.title {
    @include ig-responsive-property(padding, ( 20rem: 2.1rem, 40rem: 2.6rem, 60rem: 3.5rem ));
}

The padding will be 2.1rem if the viewport is 20rem wide, 2.6rem if it's 40rem wide, and 3.5rem if it's 60rem wide. If the viewport is narrower than 20rem, the padding will stick with 2.1rem. If the viewport is wider than 60rem, the padding will stick with 3.5rem.

By default, Ignis will dynamically scale the property value between viewport widths, which is technique known from fluid typography. This behavior can be switched off if it's undesired.

If you use include-media, all responsive mixins also support named viewports. The example above could then be written like this:

.title {
    @include ig-responsive-property(padding, ( phone: 2.1rem, tablet: 2.6rem, desktop: 3.5rem ));
}

Modular scales

From the description of modularscale-sass:

A modular scale is a list of values that share the same relationship. These values are often used to size type and create a sense of harmony in a design. Proportions within modular scales are all around us from the spacing of the joints on our fingers to branches on trees. These natural proportions have been used since the time of the ancient Greeks in architecture and design and can be a tremendously helpful tool to leverage for web designers.

Ignis provides a mixin to create basic and multi-stranded modular scales. It's a lightweight alternative to modularscale-sass.

Example with a multi-stranded modular scale:

$mod-scale: 1em 2em, 1.1;

h1 {
   font-size: ig-harmony-modular-scale(3, $mod-scale...); // Will be: 1.128em
}
h2 {
   font-size: ig-harmony-modular-scale(2, $mod-scale...); // Will be: 1.1em
}
h3 {
   font-size: ig-harmony-modular-scale(1, $mod-scale...); // Will be: 1.026em
}

Combined with Ignis' responsive properties:

$responsive-mod-scale: (
    320px: (1rem 2rem, 1.1),
    640px: (1rem 2rem, 1.2)
);

h1 {
    @include ig-responsive-modular-scale(font-size, 3, $responsive-mod-scale);
}
h2 {
    @include ig-responsive-modular-scale(font-size, 2, $responsive-mod-scale);
}
h3 {
    @include ig-responsive-modular-scale(font-size, 1, $responsive-mod-scale);
}