Deploy Sass effectively

This entry is part 6 of 9 in the series: Understanding and using Sass

• Working our mockup with Sass and Susy

  In order to better understand the implementation of everything we have seen so far, including the use of Sass, we are going to deploy a real workflow by really relying on the implementation of a site.

• First steps and first files

  After having seen all the concepts that are interesting to discuss at the same time as Sass, it is important to start to draw up our first files and our first lines of code in order to put all this in activity.

• How to distribute partial files

  SassScript goes well beyond the simple use of variables or mixin, we will explore an approach to work with a much more successful template to design our site or application development.

• Setting Sass with Compass

  Although Compass is no longer maintained, we will see an approach that uses it and allows us to continue to benefit without compromising our productions.

• Install and prepare Sass for production

  Working under Ruby is a real panoply that we have under the mouse. Let’s see how to install all the facets that can be very useful to us.

• Deploy Sass effectively

  Since democratization and the use of preprocessors, various concepts, mainly based on object-oriented programming, have emerged and allow us to approach Sass in a very modular way.

• Sass – The compilation and tools available

  Although Ruby is a very open and scalable approach, there are various ways to compile Sass in CSS, all of which can present their interests and benefits.

• What is Sass – Introduction and presentation

  What is a preprocessor and what is Sass? This post will introduce those basic concepts and what can be expected from such a technology.

• Understanding and using Sass

  This present series will not cover Sass syntax, but will look at how to use Sass and develop concepts allowing us to exploit the best of the possibilities Sass has to offers.

As we saw earlier, writing in Sass does not mean writing traditional CSS, but it is incumbent on us to produce quality CSS, and, finally, to comply with a set of good practices.

I therefore invite you, before I begin, to bring you closer to Principles of writing consistent, idiomatic CSS.

Next, it is important that we are interested in some approaches, and methodologies, in designing CSS styles.

Each of them explores a way of using classes and sharing descriptions.

It is true that, at first glance, this may run counter to a certain idea of CSS, and in particular on the abuse of class, otherwise known as acute class.

If you take the time to analyze them one by one, you will quickly realize that whatever the nature of your project that the single use of selector can very quickly become blocking at the level of the specificities, and is relatively heavy to manage as to its scalability.

OOCSS (Object Oriented CSS)

The object-oriented approach OOCSS is a revolution in the basic approach of CSS.

The idea is simple. Just think about distinguishing the structure and the appearance, and therefore to separate the contents of the container. Not to use strong specificities, and thus avoid the ID, to continually think flexibility first, flexibility and responsive.

In addition, not to hesitate to minimize the impact of a single module on an element and thus, if necessary, to multiply the modules on the same object in order to apply several objectives.

It is necessary to favor the transversal re-use by avoiding falling into an excessive specificity, which would limit the cases of use. Think global and non-specific.

A small example … let’s say that the <h1> title of an article is styled in a certain way, and that the title of a <caption> table uses a large common base with the previous title, similarly for the title < h3> of a particular module … The CSS approach could be

  article h1, caption, .module h3 {}

An OOCSS-style revision would be equivalent to implementing a specific rendering class of this title and adding it to each of the elements directly at the HTML DOM level

  .titre_emergeant {}

The obvious advantage is that it will not be necessary to isolate the caption selector, in case various modifications are necessary, and the evolution will be much more flexible, even if a particularity occurs on one of the elements, to add a class to this element

  .titre_emergeant_particularite    {}

It is true that in Sass the use of inheritance, and / or placeholder, might suggest being a rather flexible alternative of use. Attention, as we shall see later, not to fall into this apparent easiest way.

  %titre_emergeant {}
  article h1, caption, .module h3 { @extend %titre_emergeant; }

BEM notation, or SUIT CSS, methods

BEM (Block, Element, Modifier), is a methodology, or convention, for naming, and dividing by blocks, elements of the page. This does not provide anything at a purely structural level, although this specifies it. It however, allows to quickly defining a block, each of its elements and their possible states.

Contrary to OOCSS, BEM will rather integrate in a verticality specific to each module and less impose itself as element of transversality between the modules.

If we take the example of a module, BEM allows us to define various classes, having a first class to define the module itself, and, various classes which will qualify each of the elements the component, modify specifying the states, both of the module, and of its elements.

The classes corresponding to the various elements use a single hyphen separator, whereas the classes ‘modify’ use a double dash separator.

  .module
  .module-titre, .module-icone, .module-barre, .module-bouton
  .module--inactif, .module-bouton--inactif, module-bouton--on

Basic Approach

We will see that this can be improved by also using a dedicated @mixin. But, this kind of naming can be implemented quickly and easily within Sass, notably through the use of the parent’s referential character, &.

  .module    {
    &-titre {}
    &-bouton {
      &--on {}
    }
  }

Using a name convention, BEM or SUIT CSS oriented, will give an architectural tree. Therefore, the main idea will remain to define a real BEM tree, in place of the classic tree of the DOM.

  .module{}
  .module-title{}
  .module-button{}
  .module-button--on{}

More Complex Approach

Since Sass 3.4, the enhancement of the parent selector (&) allows by coupling with the @at-root directive to use a real encapsulation. To highlight this point, let us support the excellent article by Marc Mintel – Pushing BEM to the next level with Sass 3.4

BEM and dedicated libraries

BEM does not stop to be just a naming convention, it can also be complemented by JavaScript libraries including i-bem.js, or component packages ready to be used, and some other works around jQuery.BEM or package like bem-js, as well as jQuery BEMHelpers.

If you wish, we could explore these uses in a forthcoming series of articles.

Suit CSS, another alternative

In parallel with BEM, we could also evoke SUIT CSS (Style tools for UI components), which is a method based on the same principle but which calls for a different division. We are talking this time about Component, Descendent, Modify, State and Utility.

  .Module
  .Module-titre, .Module-icone, .Module-barre, .Module-bouton
  .Module.is-on, .Module.is-off, .Module.is-expanded
  .Module--default, .Module--theme

SMACSS

Unlike the first two approaches, which propose a CSS implementation methodology, SMACSS (Scalable and Modular Architecture for CSS) redefine rather a methodology of work, (much of the work is free access).

Jonathan Snook delivers a large number of important keys that allow us to gather together to properly organize the deployment of CSS, but especially to guarantee its scalability and maintainability in a very simple way.

What we will retain, for our concern, is the declension of CSS into categories:

• Base
• Layout
• Module
• State
• Theme

Sass, allows us to decline, and to increase, as much as possible, this granularity of cutting, because at the end everything can be very simply regrouped within a single file.

  @import 'base';
  @import 'layout';
  @import 'module';
  @import 'state';
  @import 'theme';

Let us not forget that SMACSS, proposes an architecture that wants to be scalable and modular for our CSS.

ITCSS

ITCSS, (for Inverted Triangle CSS), proposes a distribution by degree of specificities and cascades, thus avoiding significant overloads, and often blocking.

• Settings, allows grouping all the settings both at the level of the preprocessor (parameters, variables and map at the global level, environment …), as well as the definition of typos and other colors used by the theme.
• Tools contains both the set of application utilities (converters, adapters … again at the general level) and the @mixins,%placeholders and other functions necessary for all the other layers.
• Generic, proposes the very first level of CSS with both the resetting of the default values of the browsers, the properties of boxes and the first definition of the different layouts specific to each device.
• Elements can include all of the basic HTML tags, and with respect to an Atomic Design approach. This allows defining the elementary particles, namely the atoms. Be careful not to be confused with layers of elements that are assimilated to interface objects and therefore are part of a more complex organism (molecules and organisms in an Atomic Design convention), themselves using classes, so referenced as objects of the next layer.
• Objects, will group all the identifications by class, representing objects (in OOCSS philosophy), or molecules (Atomic Design).
• Components, is a higher level of objects, also based on classes, with a BEM-oriented naming approach, and consisting mainly of organism (Atomic Design), complex objects (OOCSS) and interface components (UI)
• Trumps, last level that can surpass previous and now mainly all utilities, helpers, states and other forces of the theme. Do not fear the use of the !important property for certain declarations.

Naming _partials.scss files can therefore use the root of these layers, for example:

  _settings.colors.scss
  _settings.sass.scss
  _tools.mixing.scss
  etc…

Do not hesitate to get closer to this github which offers a good starting tree https://github.com/mehmetkose/skeleton-itcss.

Moreover, if we want to go further by coupling for example BEM and ITCSS this gives BEMIT and there is an excellent article on the subject, BEMIT: Taking the BEM Naming Convention a Step Further.

Atomic Design

From 2013, Brad Frost, began to publish a work on a particular methodology, and close to the atomic constitution of the elements. He also gave this name to his study Atomic Web Design, quickly completed and expanded by his book Atomic Design.

Like BEM and SUIT CSS, Atomic Web Design offers a cutting starting from the atom, molecule, organism, model and page.

The metaphor is quite appropriate, and if we replace it with elements of content, we end up with:

• A label, a button or a title (in the role of atoms),
• A search tool component (on the molecule side),
• A fairly comprehensive menu bar (at the organism level),
• A filling template (to embody the model, and, bring together all the organisms)
• Finally, a site page (being an instance from the previous template).

To support this principle of establishment and construction, Create atomic design systems with Pattern Lab proposes a set of tools (Node and PHP).

This approach allows us to encompass all the previous methods, namely OOCSS, SMACSS, ITCSS and BEM.

One can therefore resort to partials,

  @import 'atomic';
  @import 'molecule';
  @import 'organism';
  @import 'template';
  @import 'page';

 

Conclusions

Through these various methodologies, we have seen that using a class notation work is therefore a solution, certainly a matter of debate among the most purist of us, but oh so adapted to the maintenance of a great flexibility in the daily management of our projects.

The modular approach and the cutting into several files _partials.scss quickly brings a great flexibility to the maintenance of the sites.

In conclusion, we can retain three key words,

• Modules, object, reuse, grouping
• Naming, categories, utilities, definitions
• Divided, files, specifics, granularity

In addition, it is well on these three points that we will have to focus our use of preprocessors.