preface

Maybe you’ve seen a lot of style naming rules, also refer to our set of naming conventions, but most of the specific style still don’t know how to name, what is the main idea or standard, which is the front. The m – behind the panel – how should the name of the son module and how the parent module dependencies, and so on similar problem. How to solve the problem in a friendly and scientific way can reduce the difficulty of maintaining the style in the later period. This article will take you through the basic naming conventions of the front-end, the pros and cons of each, and then give you a concrete solution.

A specified format

Hump naming

Something like.mlayerTitle or something like that, but this is just a format, not a naming convention, or how you should think about what to call it.

In order to-Format split

Similar to.m-layer-title, this format is also very common. Also only the format, no naming method of the core idea.

Two style organization ideas

BEM (block element + + modify)

Block level, element, modification, its main design idea is to define the block level, for the child elements are separated by _, for the modified part of the increase — implementation. Use – for more complex block-level elements. The evidence is as follows:

site-nav
site-nav_logo
site-nav_login
site-nav--active
site-nav--active
Copy the code

OOCSS

  1. OOCSS stands for Object-oriented CSS. Structure and design separation container and content separation Using this structure, developers get CSS classes that can be used in different places.
  2. There are usually two pieces of news (one good news and one bad news): Good news: reduce code by reuse (DRY principle) Bad news: maintenance is difficult (complex). When you change the style of a specific element, most of the time, in addition to changing the CSS itself (because most CSS classes are generic), you have to add more markup classes.
  3. In addition, OOCSS itself does not provide concrete rules, but rather abstract recommendations, so the end result of this approach in production will be different. In fact, the idea of OOCSS has inspired others to create their own, more concrete ways of structuring code.
  4. The concrete extension is the way we separate global styles, layouts, spacing, and modular styles, with scientifically accurate conventions.

SMACSS extensible and modular structure of CSS

Jonathan Snook breaks it down into five parts:

  1. Base rules: Set styles for the main elements of a website, such as body, input, button, ul, OL, etc. In this step, we mainly use HTML tags and attribute selectors and, in special cases, CSS classes (e.g., if you have a javascripts Style option);
  2. Layout rules: The size of modules for global elements, tops, footers, sidebars, etc. Jonathan recommends using ID selectors because these modules are unlikely to appear more than once on the same page. However, the author of this article thinks that this is a very bad habit (every time ID appears in the style text, the world suddenly becomes gray, there is a sense of sadness).
  3. Modules Rules: Modules (similar to card layouts) can be used multiple times on a page. For modular CSS classes, ID and tag selectors are not recommended (for reuse and context independence).
  4. State rules: In this step, the various states of modules and the basic parts of the site are specified. This is the only one allowed to use! “” “Important”.
  5. Theme Rules: Design styles that you may need to change. We recommend defining namespaces for CSS classes that belong to a group and using separate namespaces for CSS classes used in JavaScript.

Atomic CSS Atomic CSS

  • Atomic CSS is a method of CSS architecture that has the advantage of writing small, single-purpose CSS classes based on visual functionality. Such classes are also commonly called atomic classes. Using Atomic CSS, create a separate CSS class for each reusable property. For example, margin-top: 1px; Create a CSS class similar to MT-1, or width: 200px; The corresponding CSS class is W-200. This design can maximize the unified page common style, easy to manage, especially after you use the preprocessor, you can use inheritance, expansion and other ways to quickly use a common code segment or style module, reduce the number of CSS code to the greatest extent.

  • Existing disadvantages:

    1. CSS class names are descriptions of attribute names, not the natural semantics of elements. It’s easy to get lost in the development process. Development itself is also easily complicated.
    2. Display Settings directly in HTML.
    3. Because of these shortcomings, this approach has come in for a lot of criticism. However, it can work for large projects.
    4. In addition, Atomic CSS is used in various frameworks to correct element styles and other methods for certain layers.

MCSS multilayer CSS

  • MCSS stands for Multilayer CSS. This style writing suggests dividing the style into sections, each called layers.

    1. The Zero layer or Foundation, responsible for resetting browser-style code (such as reset.css or normalize.css);

    2. Base layer, including styles for reusable elements: buttons, input, hints, and so on.

    3. The Project layer consists of individual modules and “contexts” that style elements based on the client’s browser or device used for browsing, user permissions, and so on.

    4. The Cosmetic layer, which uses the OOCSS style to write styles, makes minor changes to the appearance of elements. It is recommended to leave only styles that affect the look and feel of the site, and not spoil the layout of the site (e.g. colors, non-critical indentation, etc.).

  • The level of interaction between layers is very important:

    1. Define neutral styles in the Base layer and do not affect other layers.

    2. Elements in the Base Layer can only affect the CSS classes at the Base.

    3. Elements in the Project Layer can affect both the grassroots and Project layers.

    4. The Cosmetic Layer is designed as a descriptive OOCSS class (“atomic” class) and does not affect other CSS code, but is used selectively in markup.

AMCSS Property module CSS

Let’s look at an example:

Button

It’s a bit complicated to write a chain of CSS classes like this, so let’s group these CSS classes by attributes. After grouping, it looks like this:

Button

A good way to avoid attribute name collisions is to add namespaces to attributes. Our button code then looks like this:

button

If you use a validator to check your code and it doesn’t like attribute names like am-button, you can change the attribute’s namespace (am-) to data-. For example: data – button.

Use a less common selector “~=”(all supported above in IE7), which is similar to CSS class attributes: all elements whose attribute values contain the specified word (separated by Spaces) are selected. So, selector [class~= “link”][class~= “button”] is relative to selector A.link.button. This selector applies to attributes as well.

Therefore, CSS code can be written like this:

/* CSS class selector */.button {... } .button--large { ... } .button--blue { ... } /* CSS property selector */ [am-button] {... } [am-button ~= "large"] { ... } [am-button ~= "blue"] { ... }Copy the code

If you think this code is unusual, try using a milder form of AMCSS:

<div am-button am-button-large am-button-blue>Button</div>

FUN

FUN stands for “Flat hierarchy of selectors, Utility styles, name-spaced components.”

The letters before each name represent certain principles:

F, flat hierarchy of selectors: it is recommended to use CSS classes to select items to avoid unnecessary cascades and eliminate the use of ids.

U, functional styles: Encourage the creation of atomic styles for typical correction tasks, e.g. W100 for width: 100%; Or fr means float: right;

N, name splitting components: Ben suggests adding namespaces to specify the style of a particular module element. This approach will avoid middle overlap of classes.

Some developers have noticed that writing CSS code using this principle is very convenient and maintainable; To some extent, the authors have taken the essence of SMACSS and presented the technology in a simple and concise manner.

This approach imposes a lot of demands on the project and code structure; it simply establishes the preferred form of record selectors and how they are used in markup. But in small projects, these rules are enough to help build high-quality CSS code.

conclusion

The design idea of these styles does not fully meet the actual needs, the project practice suggests that according to their own business and the needs of members, choose the appropriate style clearly rules, can be one of the above, can also be a mixture of several results, the ultimate purpose is to make your style easy to maintain. My personal recommendation here is to use SMAC+Atomic, and it all boils down to the basic CSS code specification.

Reference documentation

  • Six ways to organize CSS