A complete summary of CSS methodology

All engineering problems in the field of software development are ultimately derived from one problem: What if the code size is large?

For CSS, the core issue caused by the increase in code size is naming conflicts.

The methodology of resolving naming conflicts is modular, which evolves various modular schemes around this methodology.

First, the naming of the modular

The basic idea is to ensure that the global space under the domain name does not conflict, then the sub-domain name is limited to a separate local scope, thus guaranteeing the uniqueness of the name.

Depending on how the domain name is divided, there are different naming schemes:

BEM: Block-element-modifier, more general, no excessive restrictions

SUIT CSS:

1. Divide the named objects into components (component) and functions (Utility). Components directly named, the function of additional prefixes, such as a special to the JS call class name can be added JS prefix: Js-button

2. The use of hyphens is specified. Ordinary partition with a single hyphen, descriptive vocabulary with two hyphens:

. Nav-button {}

. nav-button--primary {}

Along this line of thinking, you can actually introduce an underscore to set other rules.

3, state switch with is-state type of adjacent class name (adjoining Class)

. Button {}

. button.is-clicked {}

<button class= "button is-clicked" ></button>

oocss:

Simply put is abstract public class, the reuse of high-level patterns extracted, for example:

. mt20 {margin-top:20px}

. TC {Text-align:center}

. ABS {Position:absolute}

. clearfix:after {content: '; display:block; clear:both; height:0}

The idea of this approach is to reduce the need for naming by improving reusability, because some styles can be implemented directly with public class names and do not require additional naming.

Its disadvantage is that abuse can pay a price, such as 10 components with the same common class name, then modify the style only need to change a CSS, but on 10 components with the same public class name such as mt20, meaning to change the mt20 to mt15, you need to change 10 class. So public style less use public class, not easy to figure.

smacss:

For a large number of class names, SMACSS proposed a classification scheme:

1. Base: Basic style rules

2. Layout: style rules for layouts

3. MODULE: Reusable Modular style rules

4. State: Status Style

5. Theme:ui Style

For different classifications, you can use different prefixes to divide the namespace, not much more.

itcss:

This scenario is more like a CSS overall architecture scheme, different from smacss horizontal classification, it synthesizes the above methods, and proposes a vertical hierarchical model:

1, Settings: Simply said in the scss to preset the good variable

2, Tools: Simply say is in the SCSS preset good mixins and functions

3, Generic: Simply said is RESET.CSS or normalize.css

4. Elements: Basic formatting of elements, such as H1 {font-size:20px}

5. Objects: Use OOCSS Abstract public class

6. Style of Components:ui components

7, Trumps: Auxiliary, functional special style, such as animation

Second, CSS in JS

Avoiding conflicts by naming them in large projects is a very mental thing to remember all the rules and to determine whether your naming conforms to the rules. The deeper question is, does this seem like a programmer's way of solving problems, and it's worth the effort to name such low-level labor?

So react put forward the idea of CSS in JS, react is this: in JS and all programming language best practice, will avoid the use of global variables, and in CSS, no matter what naming method, full screen is a global variable, how to avoid the use of global variables? The approach is to use inline styles, without using CSS selectors at all.

var styles = {

Button: {width: ' 50px ', Height: ' 30px ', backgroundcolor: ' #ff4444 '}

}

<div style = {Styles.button}>

We can not simply use the "reverse history" argument to judge a technical solution, but should be combined with the application scenario, in the cost and benefit of the trade-off. Specifically, the problem solved by this solution is more cost-effective than the problem it brings.

Source: Https://speakerdeck.com/vjeux/react-css-in-js

Some of the problems with large CSS are:

1, the global namespace is prone to pollution, conflict

2, rely on management complex

3, useless code is difficult to clear

4, long name cause the code volume can not be further compressed

5, not conducive to and JS shared constants

6, uncertain parsing results (there are cascading in CSS, if the cascading coefficient of high code load slower, will lead to the final parsing style mutation)

7, cannot decouple (change a CSS, all UI styles that use the CSS will be affected)

The JS + inline style solves all of the above problems, of course, it also brings other side effects, such as difficult to debug, not with CSS preprocessor, media query and pseudo-elements can not be implemented, and if you do not react ...

Third, CSS Module

CSS module can be seen as a CSS in the JS idea of another route, is to use JS to compile the original CSS file, so that it has the ability to modular.

The CSS module divides the module according to the CSS file, and the class name inside the module is compiled into a unique name using a hashing algorithm, so there is no problem of naming conflicts between modules.

Of course, you must use build tools such as Webpack to use the functionality provided by CSS module.

CSS module requires that each element can carry only one class name, cannot use more than one class name, then how to use the composition style? The solution is to use component in CSS, which in fact has a similar implementation in the preprocessor:

. Common {}

. normal {

Composes:common//Inherit all styles of common

}

Composes can reference not only the class name of this file, but also the class name of other files:

. normal {

Composes:common;

Composes:primary from ". /shared/colors.css ";

}

In addition, using the: Global (. className) syntax, you can define the Globals class name, and with POSTCSS you can use variables, see the Nanyi Tutorial:

Http://www.ruanyifeng.com/blog/2016/06/css_modules.html

Iv. Postcss

Here, the development of CSS methodology has become clear. The naming scheme still has value in small and medium-sized projects, but in large projects, a better solution is to strengthen the native CSS capabilities based on CSS in JS. React put forward the idea is to abandon the CSS, can use JS to solve all with JS. Another idea is to use a compilation tool to process the CSS.

Postcss is a very popular in recent years a compilation tool, Vue officially provided scaffolding vue-cli default CSS processing tool is postcss. Unlike the POSTCSS and preprocessor less, sass, the preprocessor simply provides a set of syntactic sugars, and postcss is a comprehensive processing tool that enables almost all of the functionality that is used to handle CSS through a rich plug-in: Class name compilation, Auto-prefixer, compression, Preprocessor features, properties shorthand ...

Postcss is not the only, the front-end industry has always pursued the purpose of "life is endless, tossing not only", about the CSS in JS scheme, we feel a bit:

With so many good wheels, my mother didn't have to worry about my vocabulary enough.

A complete summary of CSS methodology