In Harry Robert's own words:

inuit.css is a CSS framework. Another one. Except I like to think that inuit.css is a little different. It’s not a grid system, it’s not a boilerplate, it’s not a starting point, it’s a fully featured and extensive framework. It is designed to do 90% of the grunt work for you, it takes care of the boring bits that you have to do on every build and leaves you enough time to concentrate fully on the fun bits.

Pragmatic

inuit.css is a pragmatic framework which uses lots of progressive enhancement. Rather than trying to be everything to everyone it performs to its environment. IE7 works a treat, but Firefox 4 works even better. inuit.css takes a sensible approach to web development.

In Harry Robert's own words:

ITCSS—which stands for Inverted Triangle CSS—is a fully managed CSS architecture. It's not a framework or library; there's nothing to download or install.

It's a collection of principles and metrics by which developers should group and order their CSS in order to keep it scalable, terse, logical, and manageable.

It's very specifically opinionated in that it gives definite rules and guidelines for your source order and groupings, but it leaves decisions about naming conventions and preprocessors etc. up to you. This means that, although ideally suited to larger projects, ITCSS can be used on builds of all shapes and sizes.

One of the key principles of ITCSS is that it separates your CSS codebase to several sections (called layers), which take form of the inverted triangle:

These layers are as follows:

• Settings – used with preprocessors and contain font, colors definitions, etc.
• Tools – globally used mixins and functions. It’s important not to output any CSS in the first 2 layers.
• Generic – reset and/or normalize styles, box-sizing definition, etc. This is the first layer which generates actual CSS.
• Base – styling for bare HTML elements (like H1, A, etc.). These come with default styling from the browser so we can redefine them here.
• Objects – class-based selectors which define undecorated design patterns, for example media object known from OOCSS
• Components – specific UI components. This is where majority of our work takes place and our UI components are often composed of Objects and Components
• Trumps – utilities and helper classes with ability to override anything which goes before in the triangle, eg. hide helper class

The triangle also shows how styles represented by selectors are ordered in the resulting CSS: from generic styles to explicit ones, from low-specificity selectors to more specific ones (but still not too specific, IDs are not allowed) and from far reaching to localized ones.

BEM is an abbreviation of three entities: a Block, an Element and a Modifier. BEM is a methodology of web projects development, that allows you to divide an interface into logically independent blocks.

We are using BEM to name our CSS class and consecuently named in the HTML

BLOCK

Standalone entity that is meaningful on its own.

A Block will be the component itself named in lower case to delimit separate words with a hyphen (-) character.

ELEMENTS

Parts of a block and have no standalone meaning. They are semantically tied to its block.

An Element will be the union of the block name and double Underscore "__" follow by a reperesentative name

MODIFIER

Flags on blocks or elements. Use them to change appearance or behavior.

A Modifier will be the name of the block or an element folllow by doble hyphen (--) and a reperesentative name

Here is an example of using BEM in HTML and CSS

            <!-- A represntation of a media Block that contains an image an a text-->
            <<div class="media media--large">
                <img class="media__img" src="http://placehold.it/200x150/dddddd/4a8ec2">
                <p class="media__body"> Lorem ipsum dolor sit amet, consectetur adipisicing elit.</p>
            </div>
    

        .media {display: block;}

        .media__img {
            float: left;
            margin-right: 28px;
        }

        .media__body {
            overflow: hidden;
            display: block;
        }

        .media--large {padding:20px;}

        .media--large > .media__img {
            margin-right: 56px;
        }
    

The term was introduced by Robert C. Martin in an article by the same name as part of his Principles of Object Oriented Design made popular by his book Agile Software Development, Principles, Patterns, and Practices.

The single responsibility principle states that every module or class should have responsibility over a single part of the functionality provided by the software, and that responsibility should be entirely encapsulated by the class. All its services should be narrowly aligned with that responsibility.

In other words this principle states that everything you create should be created for a single, focused reason. The styles you apply to a given selector should be created for a single purpose, and should do that single purpose extremely well.

This doesn’t mean you should have individual classes for padding-10, font-size-20, and color-green. The single purpose we’re talking about is not the styles that they apply, but rather where the styles are applied

The single source of truth approach takes the single responsibility theory to the next level in that not only is a class created for a single purpose, but also the styles applied to that class come from one single source. In a modular design, the design of any component must be determined by the component itself, and never imposed on it by a parent class.

You can navigate on the web to search for reference of the INUIT Elements

Here you can have direct acces to each element

If you download the source code, you will see that every thing is setup as modular components in order to grab only what it is interest for you.

If you open style.scss , you will see that every "Igloo" is setup in its layer and also you can spect to have two other files for each Igloo.
These two files are a settings file that has to be reference before the bower component does and is meant to contain all variables that can be change in the bower/npm component. The second file is an override modifier that extends the component by overriding or extendings their initial values

NOTE: Not all Igloos have variables to setup , there for they may not have a --setup file, and also some other igloos that have no html representation (specially igloos that lays on settings and tools layers) will not need of an --override file

here is an example of the "media" object

// ************************************
// ******* #OBJECTS *******
// ************************************

// for every igloo you can spect to have as much as 2 other files

// a file that contains media setting like : $inuit-enable-media--tiny: true;
@import "objects/setup/_objects.media--setup";
// ......................
// bower component
@import "bower_component/inuit-media/_objects.media";
// ............................
// just in case we need to add more stuff to that Igloo
@import "objects/override/_objects.media--override";