160901. Organizing CSS in large projects

Writing CSS is easy.
It's hard to write maintainable CSS.

You may have heard this phrase 100 times before.
The reason is that everything in CSS is default to Global. If you are a C programmer you will know that the global variables are not good. If you are any kind of programmer, you know that isolation and composable modules are key to building maintainable systems.

To try to help people build maintainable CSS, there are already many CSS guides: smacss, Oocss, BEM, Itcss, ACSS, ccss,atomic Design, maintanable CSS, Rscss, and possibly more.

So, what is the problem with CSS?

span {

 font-size: 11px;

}

.header-right {

 font-size: 22px;

 text-align: right;

}

With a CSS definition like above, the style immediately becomes global, and it affects all pages that apply the style. No encapsulation. There are no isolated modules.

In a standard programming language, you will only introduce modules for specific functions to be implemented, such as:

# Python modules

import requests

from Flask import url_for

// Node modules

var express = require(‘express’)

This way, you know exactly what will affect your code, and only what you explicitly introduce will affect the functionality you are currently implementing.

And in the CSS is the reverse. Every single line of CSS code I write can affect all parts of the project and inadvertently change the look of other pages. My style is more than just leaking out, they're swarming around every corner of the application.

This is understandable and reasonable for basic styling, such as printing, just setting the style of the input field, or the overall style. Basically HTML and CSS are born for this. These tools are made for publications. In order to understand the ideas behind these languages, I often envision the typesetting of books: You don't want every page to look different-yes, you want a simple, consistent style that runs through the whole book, not too much rubbish. That's why labels like s are reasonable, and the style is global and will always be there.

However, the world has changed and the web has changed. We no longer make Web pages--we build Web applications. The publication metaphor created by HTML and CSS no longer applies to most of the things that are built on the web today.

This does require a new way of specifying a style, and perhaps a new way to build the web. But for now, we can't get rid of CSS and HTML, which means we have to use these tools with care in a way that outputs manageable and maintainable applications.

Peergrade.io How to handle CSS: prefix (to class name)

In Peergrade.io we used prefixes in all class names . PG . Not using prefixes in the CSS code base is asking for trouble. The reason is that the non-prefixed class name will eventually conflict with the introduced style. Suppose you need a datepicker?—— you certainly don't want to develop one from scratch (at least I don't), so you introduced one. Now your style is full of . Prev, . Next, and . Separator class names that might conflict with your own class name-if you don't prefix it.

For a long time, Font awesome did not prefix their class names, which means that you often clash with their . icon-* class names (they now use the prefix . FA). We are also sad to find that Bootstrap also has no choice to prefix--but we still? You, Mark Otto.

Rule two: Avoid nesting with CSS selectors

In Peergrade.io we use Sass. Using Sass you quickly enter a pattern that matches the structure of an Sass structure, such as:

#user-profile-page

 .profile-description

   h3

   ul

     li

       a

After doing so, you will find that, although it feels good, it is very fragile. When you write it you may think there will only be a list in . Profile-description , but after two months you find that you have to need another list, and the page structure is quickly beyond your imagination.

Also, a style definition like this is applied to any element inside the parent element-not just the level you wrote in the sass.

Nesting CSS selectors what you do is to bind CSS and HTML structures in subtle and fragile ways.

Rule three: Develop components with BEM naming

When building an isolated component, use the BEM naming scheme to name the class as much as possible. We did not follow the complete BEM guide-just the naming scheme, which means that the class name should be this form:

.block__element--modifier

To this end we organize our Sass:

.pg-deadline

 &__date

   // becomes `.pg-deadline__date`

   color: $color-gray

 &__header

   // becomes `.pg-deadline__header`

   font-weight: 700

   &--highlight

     // becomes `.pg-deadline__header--highlight`

     color: $color-green

What you see here is that we use sass nesting to create BEM class names for us. It is somewhat counterintuitive that this produces a completely flat CSS structure--no nesting--only the top-level class name definition.

As an exception to rule two, we allow . Block–modifier The class name in the form.

.pg-deadline--editable

 .pg-deadline__header

   background-color: $color-blue

 .pg-deadline__date

   color: $color-black

In this particular example, we allow 1 layers of CSS selectors to be nested. This allows us to specify the modifier of the chunk-that is, what is being edited-without repeating the modifier (e in Bem) on all the child elements within the chunk.

To better understand the naming of similar bem, go to the class Bem named section of the CSS guide to see Harry Roberts. (to mention, we found that Harry actually created a naming scheme similar to ours.) ）

Prospect

It seems that no one really found the best way to deal with CSS, looking at hack news featured this article, I am somewhat disappointed with the status quo of CSS, we can do better.

The conclusion: We believe we have found a sustainable foundation for CSS-and of course there is room for improvement. The plan is to check our guide regularly to see if things are moving in the direction we expect and revise them when necessary.

END

Nuggets is a high-quality technology community, from ECMAScript 6 to Vue.js, website performance optimization to open source class library, so you are good at WEB development of every technical dry. Long-click on the image QR code identification or the major application market search "nuggets", technical dry in the grasp.

160901. Organizing CSS in large projects