! Important, arbitrary naming, mixing variables and rules… Without the CSS specification, the code will quickly become a mess, and you will never be able to prove that what others have written is unreasonable or that what you have written is proper. Therefore, there are many benefits to introducing CSS specifications, both for maintenance and communication purposes.

From my own needs, I want the specification to dictate how CSS rules should be written and organized. This way I can actually know how to write CSS rules and where to put them when I’m done.

I care more about how I organize CSS rules than how I write them. A good organizational structure can keep bad code localized and easy to refactor later.

How do I organize CSS rules?

Whether you use a single file or multiple files to organize CSS rules, you need to take into account the cascading mechanism of CSS (inheritance + specificity). Good inheritance reduces code redundancy, and grouping CSS rules by particularity makes your CSS easier to maintain and extend.

Both ITCSS and SMACSS define how to organize CSS rules. The former divides CSS rules into Settings, Tools, Generic, Elements, Objects, Components, and Utilities. The latter divides CSS rules into five layers: Base, Layout, Module, State, and Theme.

In addition, ITCSS and SMACSS specify how to write CSS rules. The former requires that only class selectors be used after the Elements layer, and no ID selectors be used at any layer. The latter does not restrict the use of selectors.

Choose any of these to build CSS rules that are easy to extend and maintain. I prefer ITCSS and its layering is more suitable for today’s component-based development. I recommend reading Manage Large CSS Projects with ITCSS to learn about ITCSS. It is written by ITCSS inventor, I believe you can learn the most authentic ITCSS.

How do I write CSS rules?

Although both ITCSS and SMACSS specify how CSS rules are written, there are no restrictions on how class selectors are written.

OOCSS specifies two basic principles for writing class selectors:

  • Separate structure and skin: This means to define repeating visual features (like background and border styles) as separate “skins” that you can mix-and-match with your various objects to achieve a large amount of visual variety without much code.
  • Separate container and content: This means “rarely use location-dependent styles”. An object should look the same no matter where you put it of styling a specific h2 with .myObject h2 {… }, create and apply a class that describes the h2 in question, like h2 class=”category”.

The SUIT CSS specifies a naming convention for classes based on componentized development.

SUIT the CSS DEMO:  .MyComponent {} .MyComponent.is-animating {} .MyComponent--modifier {} .MyComponent-part {} .MyComponent-anotherPart {}Copy the code

Atomic lays down the basic principle for writing class selectors: write each declaration with a corresponding class, named as an abbreviation for properties and values, separated by a ‘-‘.

Atomic DEMO:. Ta-c {text-align: center; } .bg-n { background: none; Opacity: 0;}. Op-2 {opacity: 0; }Copy the code

BEM specifies a naming convention for classes based on componentized development.

BEM DEMO:  .form { } .form--theme-xmas { } .form--simple { } .form__input { } .form__submit { } .form__submit--disabled { }Copy the code

To summarize, OOCSS and Atomic specify how common class selectors should be written. The class selector written by Atomic is an extreme use case for OOCSS, and it is recommended to use both together.

SUIT and BEM both specify how to write component-level class selectors, but the biggest difference between them is naming. I personally prefer BEM.

practice

ITCSS+OOCSS+ATOMIC+BEM is the CSS specification I plan to implement in my next project. The class selector based on OOCSS is placed in the Objects layer, the class selector based on Atomic is placed in the Utilities layer, and the class selector based on BEM is placed in the Components layer.

That’s all for this article. Thank you for your reading.