The settings layer is essentially usefull when using a preprocessor (which is, of course, recommended). Compared to a regular dev. framework (like rails, or symfony, or laravel, etc.), it plays the same role as the conventions defined in the framework, the config variables and constants and the various namespaces used. In InuitCSS, serveral values are defined, but of course, it’s easy to override those you want to. Always keep in mind the rule don’t hack the core. If you want to change something, don’t touch Inuit, extend/override it.
Whatever you write in this layer, it shouldn’t ouput any CSS after compilation.
- The settings.defaults module contains a few variables and settings that are required for using any of the rest of the framework.
- The settings.responsive module defines our initial breakpoint aliases and conditions.
The tools layer is also fondamentaly usefull when using a preprocessor. It’s the place to define all your functions, mixins, helpers.
This code written in this layer shouldn’t output any CSS either.
- The tools.functions module—like mixins—contains a few framework functions that are required for using any of the rest of inuitcss.
- The tools.mixins module contains a few framework mixins that are required for using any of the rest of inuitcss.
- The tools.responsive module just sets up our media query mixin.
At the generic level you begin to define rules that will ouput only basic definitions for generic elements (ie. tags). In the Inverted Triangle model that layer is still a broad one and the rules in it should target a great amount of elements in you page (all paragraphs, all lists, etc.), so the rules should be associated with extremely low specifictiy selectors (tag selectors or the universal selector. Eventually, some attribute selectors like input[type=submit]). It’s the place to include your reset and/or normalize rules. The rules defined here are not necessarily linked to your particular project, but rather rules you might use in every project you make.
- The generic.normalize module contains @necolas’ normalize.css.
- The generic.reset module is a considered approach to resetting elements. It selectively removes margins and paddings from certain elements, and provides some sensible defaults for some others.
- The generic.box-sizing module causes all elements to use the more useful border-box box model.
- The generic.shared module contains several high-level rulesets which apply a consistent, shared declaration (typically margins) across a number of elements.
At the base level, it is time to speak about your particular project. That layer contains low-specificity rules (tag rules essentially), like the previous layer. In this layer, you will probably override or extend rules defined in the previous layer.
- The base.page module is a very high-level module which styles very basic, global, page-level aspects such at the project’s base font-size and line-height.
- The base.headings module defines font sizes for base-level heading elements from h1 through to h6.
- The base.paragraphs module provides a very small amount of additional styles for paragraphs.
- The base.lists module provides very basic styling for regular ordered and unordered lists.
- The base.images module provides very basic styling for images (img).
Once you have thought about the basic stuffs, it is time to watch your page/layout and to try to find the recuring pattens in it. Here, the designer must acquire some developper skills. The idea behind that layer is to find the smallest common multiple between the components of your pages. It is very likely that several parts of your pages will share common properties. Try to find those common properties, and more specifically, try to find the structural ones. What it means is that you have to look at your layout in a schematic way. Remove all colors and borders, all the chrome of your interface and try to expose its skeletton. There you are, you see the structure, and there you can start to find the common rules that the components of your page share. When you are there, you can extract your CSS rules in order to avoid repetition. The main objective of this layer is to write a few rules that you can use in as many locations as possible in your DOM tree. It’s the DRY principle that leads you at this step.
If that step is difficult, you can get help using good tools and methodologies in your design process. Let’s face it, becoming aware of that rational methodology of implementing CSS might change (and should change), the way you design interfaces or the way give feedbacks to designers when they make graphical propositions for an interface. Using a wireframing tool like Balsamiq Mockup for instance helps you to stay at the structural level (well, your objects will probably (and should) be less detailed representations of what you can do in a wireframing tool, but it can help anyway…). And when you launch a graphical package like Sketch or Photoshop you know that you begin to think about the chrome/skin level.
- The objects.layout system is a powerful, flexible, highly advanced evolution of the traditional grid system. It is based on csswizardry-grids.
- The objects.box module simply boxes off content.
- The objects.media module is inuitcss’ implementation of Nicole Sullivan’s media object—the poster child of OOCSS. To find out where it all started, read Nicole’s blog post.
- The objects.list-inline module simply displays a list as one horizontal row.
- The objects.block module simply stacks an image on top of some text content. This incredibly frequently occurring design pattern is now wrapped up in a simple, reusable, configurable abstraction.
- The objects.pack module simply causes any number of elements pack up horizontally to automatically fill an equal, fluid width of their parent.
- The objects.list-ui module creates blocky, keyline-delimited list items.
- The objects.list-block module simply creates blocky lists from uls or ols.
- The objects.flag module is an object similar in appearance to the media object, but which provides slightly more advanced functionality.
- The objects.tabs module is a simple abstraction for force a series of elements (usually a list) into an equal-width, tab-like format.
- The objects.tables module provides some useful helpers for common table patterns.
- The objects.buttons module is a simple, robust, extensible baseline for building entire suites of buttons onto.
- The objects.list-bare module simply removes bullets and indents from lists.
The framework does not provide any component module. It's the place where you define the styles specific to your site’s components. Of course, in this layer, you will probably increase a bit specificity (but not too much, use classes instead of other kind of selectors and use the BEM syntax which allows you to express in one word necessary dependencies (specificity stays at 10) that you would otherwise express using descendant or child selectors (specificity reaches 20 or more)).
Remember, that layer is the photoshop layer, the one where you decorate your abstract entities defined in the objects layer. Like Harry Roberts says, it’s where your ui-list becomes your products-list. So it’s normal that you won’t find anything provided by the framework at this level. And that’s what makes the difference between a methodology/framework like inuit and a UI-package like Bootstrap. Bootstrap is an opiniated way to style components. Bootstrap imposes a way to style components to the designer. At the contrary, Inuit lets you decide whatever style you want. It is just a proposition to help you organise your base code.
And finally there can be rules you want to win in every situation. When it’s the case, you define those rules in the trumps layer. Of course, here, the specificity has to be high. It’s the layer where you define exceptions or extremely particular cases, like for instance, the fact that you want to hide an element visually. If you want to hide an element visually, no matter what rules you’ve defined previously that might reach it, the hiding rule has to win, it is !important.
- The trumps.clearfix module is a minimal clearfix helper class.
- The trumps.widths module is a simple file of helper classes to drop widths onto elements such as grid systems.
- The trumps.widths-responsive module is an extension of the default widths module.
- The trumps.spacing module is a small collection of helper classes for spacings like margin and padding.
- The trumps.spacing-responsive module provides breakpoint-based classes for nudging margins and paddings around responsively, e.g. .lap-mb0, .desk-mb++.
- The trumps.print module is a very crude, very basic reset-like module for print styles. It borrows basic rules from HTML5 Boilerplate.