CSS, architecture and best practices
The complexity and the scale of the projects demand a well structured and clean code.
To achieve this, our practices will be based on the most successful systems for this purpose: SMACSS and BEM.
BEM: Block Element Modifier is a methodology that helps you to create reusable components and code sharing in front-end development (http://getbem.com/).
SMACSS: is more style guide than rigid framework. SMACSS is a way to examine your design process and as a way to fit those rigid frameworks into a flexible thought process. It is an attempt to document a consistent approach to site development when using CSS (http://smacss.com/).
Both systems have common rules related to CSS best practices related to the use of IDs or nested levels for elements, but I would like to highlight how both systems are based on the “module” and how to build blocks through this logic, which means a clear connection in the HTML.
Based on Frontiers projects experience, from now on all the projects will be organized combining these two systems on the following way:
General files structure based on SMACSS ( base, states, layout, modules … ).
Modules structure and naming based on BEM ( block__element—modifier ).
Sass (https://sass-lang.com/), as preprocessor, help us to create this architecture. As well, we use autoprefixer (https://github.com/postcss/autoprefixer) as "postprocessor" for handling vendor prefixes in CSS.
As well, we are taking into account the styleguide created by Airbnb for CSS and Sass (https://github.com/airbnb/css). In summary,these are the most important points:
Use soft tabs (2 spaces) for indentation.
Prefer dashes over camelCasing in class names (Underscores and PascalCasing are okay if you are using BEM).
Do not use ID selectors.
When using multiple selectors in a rule declaration, give each selector its own line.
Put a space before the opening brace
{in rule declarations.In properties, put a space after, but not before, the
:character.Put closing braces
}of rule declarations on a new line.Put blank lines between rule declarations.
Prefer line comments (
//in Sass-land) to block comments.Prefer comments on their own line. Avoid end-of-line comments.
Write detailed comments for code that isn't self-documenting.
Creating JavaScript-specific classes to bind to, prefixed with
.js-Grouping
@includes at the end makes it easier to read the entire selector.Nested selectors, if necessary, go last, and nothing goes after them.
Do not nest selectors more than three levels deep!
never nest ID selectors!
After the first project developed by the Design Team following these patterns and practices, we are excited about the continuous improvement of our upcoming projects and how this methodologies could be a great value code-wise to build a strong Design System.