How to distribute partial files

This entry is part 3 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.

Based on the various approaches defined during the first articles, we will be able to set up a workflow, and to draw some main guidelines

Understand the possibilities of SassScript

The use of variables, the encapsulation of the declarations simplifying the writing of the groups, the use of imported files that will not be compiled, greatly simplify the generation of styles.

Moreover, the implementation of Mixins and the use of native functions from ancillary libraries, extension with inheritance and use of function keeps place, setting arguments and passing parameters allow pooling a large number of resources and thus centralizing the logical core of our approach.

The use of algebraic and Boolean operators, the use of many native functions on strings, colors, lists, the use of @ Rules and directives without forgetting the classic expressions that they are loop , counting or conditions give the expected flexibility to optimize the personalization of pages and contents.

In short, we have all the flexibilities expected to develop our CSS in optimal conditions of development, maintenance and evolution.

Sass under WordPress

Another point that should not be overlooked is that the CSS produced must be optimized, and thus concatenated, compressed and minimized. Of course this implies, among other things, that you should delete all comments in the code.

Because of this, if you are working with WordPress, and in order to preserve the mandatory introductory commentary for its identification, consider using the exclamation point just after opening comments.

  /*!
  Theme Name: Thème Enfant
  Template: slug_theme_parent
  */

Really use sass

The idea of this approach is to realize that using a tool such as Sass is not limited to the use of variables, functions, directives or other control expressions, but rather the spirit and method in which these will be used and orchestrated.

Thanks to the various methods we have seen so far, we will be able to assemble them and set up

• A purely object division based on the needs of the graphic charter,
• Define a naming concept that meets a set of specifications set up upstream
• Combine all this with a cut that corresponds to a very fine granularity, distinguishing between the layers of abstractions needed (base, layout, module, states and theme) and, on the other hand, an Atomic Design describing the elements, molecules and the organisms.
• Provide a set of files that can act as the pure, independent management of the theme
• Adding utilities, both debugging and production support

Now, it is not enough to write, or use Sass, as we would to write CSS in traditional mode.

Quite the opposite, and this is one of the main classical mistakes of beginners in this field that focuses solely on variables and @mixins. Using a preprocessor such as Sass, it is also to enter into a nonlinear, object oriented logic and making the best use of the possibilities offered to us.

This is why the article Sass and SassScript does not address Sass or SassScript at the code level, but merely in the form of a broad introduction introduction, which explores the various tools available and the various installation possibilities.

So now, through this article, we are interested, more vertically, in the use and deployment of Sass in production, avoiding to fall into a mundane use of variables, which would divert us from the real power of Sass.

In order to implement a workflow with a preprocessor, it is very important to take the time to study the prototype (or model of the site) on which we have to work.

A great deal of information will be available, such as the DOM tree, the BEM tree and finally the tree of _partials.

As regards the OOCSS and Atomic Design aspect, it is also important to be able to distinguish all the mutualizations we will have to manage (block funds, management of recurring elements, patterns, components, forms, media, …)

Integrate and nest _partials files,

Sass offers the possibility to work with _partials files, these files have the characteristic to be imported at the time of the compilation, but not to produce files from these _partials, which besides would be useless and especially bulky.

To define and distinguish a partial file, use the underscore, or underlined (_) character at the beginning of its name. When importing, neither the underscore nor the extension is required. The compiler will understand that it has to do to a partial file.

Concretely, the following files, namely, on the one hand, the styles.scss file containing

@import ‘other’;

On the other hand, the _other.scss file contenant

.module{}

Produce, when compiling the only and unique styles.css file that will contain:

.module{}

It is possible to use as many _partials files as necessary, and _partials files can themselves refer to other _partials files. Attention, at this level, to respect a certain consistency in the order of the imported files.

At the same stage that we had set up a BEM tree, we can completely speak of tree of _partials, and this without worry of granularity of the fact that during the compilation, we will obtain a single and compressed CSS document, downplayed.

As an example, here is a fragment of partial tree structure that can be considered and declined.

styles.scss
  _base.scss
  _variables.scss
  _utilites.scss
  _layout.scss
  _modules.scss

It is also possible to rely on the framework inuitcss which proposes a rather interesting starting work. Do not hesitate to create your branch to adapt the division to your own needs.

Implementation of the basic _partials

As we saw in a previous article, it is therefore possible to retrieve a prepared tree https://github.com/mehmetkose/skeleton-itcss, or inspired by the one proposed on the article https://www.xfive.co/blog/itcss-scalable-maintainable-css-architecture/.

As far as I am concerned, and since several projects that concern both sites and web applications, I work with a different approach.

On the one hand, in number of layers, and, on the other hand, in terms of grouping. It is true that I discovered ITCSS only much later, and therefore if we take the principle of the inverted triangle, on the other hand in the form of a square, since in this case the use of IDs is allowed, especially at the level of Dialogs, UIs, comps and pages, here is the representation that this can give.

• Sass, allows to group all the settings both at the preprocessor level (parameters, variables and map at global level, environment …), as well as the definition of typos and other colors used by the theme, but also various @mixins ,%placeholder, debug layer, CSS reset, global sprite management, … of course at the global level.
  For example variables specific to certain tags, will be found at the levels of these beacons in question.
• Blocs, frames the main blocks of the page (<header>, <footer>, <aside>, <main> …), distinguishing between .main and .content, or even .container The presence of a special block like _blocs-layout.scss, which can itself be declined (_blocs-layout-tablet, _blocs-layout-phone …), which allows to manage the disposition according to the devices, _print.scss which manages the distribution of blocks to printing.
• Tags, as the name suggests, combines low-level selectors by grouping them by families as much as possible, links, lists, media, typo … and taking care to add a _tags-singles.scss which allows Group all types of singlet type <hr>, <br> and other elements of this type and a _tags-blocs.scss (for <div>, <span>).
• Comps, is a first distinction of components at the boundary of the interface elements, and specifically concerns distinct HTML elements, such as <table>, <figure>, <form> (form and fieldset, concretely the cards themselves). This layer can also include some site-specific formatted elements, or application, such as notes, boxes, miscellaneous information, specific forms, etc. (in the form of classes, .notes, .frames, .infos,. sheets …)
• UIs, second element of components less oriented content, but more considered as elements of user interaction scouring at the site or the application, such as the breadcrumb, navigation bars, search boxes, interaction buttons, The elements and groups of forms … etc (also in the form of classes .breadcrumb, .nav, .search, .buttons, … or HTML element like <input>, <select>, <textarea>).
• Dialogs, not to be confused with the interface components, we are talking here only of dialog that are generally floating, modal or not. This type of objects is recurrent, and many, in web applications, and having a .scss document by dialog is not superfluous.
• Pages, this coding group aligns well with the concept of CSS signatures introduced by Eric Meyer in 2002, which makes it possible to distinguish the nature of the page (template or not). Moreover, at the level of the page, the concept of theme, and skin, can completely take its meaning.
• Accessibility, this layer is purely dedicated to the support of the accessibility, thus of possible alternative CSS sheets, (_accessibility-audio.scss, _accessibility-aria.scss, _accessibility-print.scss …) to be declined.

You will find, if you wish, a set of files, as a starting base, on the SCSS-Bare-partials Github.