Smacss method: Solving the problems of SMACSS and OOCSS

Article Introduction: How to use sass and smacss to maintain CSS.

We've always been a big fan of smacss, but a pure smacss approach is best suited for an entirely new project with ordinary CSS. Our market site, we use the Sass writing style, and there are several years of CSS legacy.

We have recently refined our CSS to make our team more convenient to maintain, while in the process of refining, our team did not throw away our existing style or start from scratch.

We started to solve the problems of SMACSS and oocss based on the Smacss method, but we also had some changes and ideas from Bem and Toadstool.

Note : You will need to know a little about smacss, if you don't understand, you can click here.

Presentation of SMACSS

The SMACSS defines five types of styles:

• Base (Basic)
• Layout (Layout)
• Module (modules)
• State (status)
• Theme (skin)

Our approach looks like this:

• Base (Basic)
• Layout (Layout)
• Module (modules)
• State (status)
• Theme (skin)

Base (Basic)

Our basic style in the new project uses only the normalize, which resets the basic style of the element (color, typesetting, outer and inner).

Unfortunately, the basic CSS on the line comes from a very long time CSS reset, with some of the default font styles almost covered. For years, these styles have been placed at the top, hard to change without affecting all other styles.

Even with these drawbacks, we can still modify our basic style, just like Smacss's basic style.

Layout (Layout)

In our method is not the basic style and the global class name but the module.

SAMCSS plans The main layout components (e.g., header header , sidebar sidebar , grid, grid etc.) and everything else. We find that there are several unnecessary factors in this distinction:

• Modules are usually displayed on the page in the same way as the components that show their subcomponents.
• Even if we 100% determine that components will never be reused, there is no benefit compared to reusable components.

The line between the layout and the module is too blurred, and it is valuable to keep the layout as a special category.

Module (modules)

Modules are stand-alone, reusable components, even if they are not known to their parent container. Their only dependency is to apply the basic style. When it is not needed, we can safely delete the module without affecting our CSS.

The BEM double underline syntax is used in the subassembly scope of a module, and we use the CSS selector to fit the depth of the application at random.

The BEM double hyphen syntax is used as a modifier to represent subclasses, or to is- combine the specific state of a keyword or module.

Because setting the width of the module width , positioning position , the outer margin margin requires the context of the relevant factors, our module is either a full-screen block element or inline elements.

Here's an example ( modules/_my_module.scss ):

.my-module {     background-color: maroon;     position: relative;      > a {         color: aqua;     } } .my-module--important {     @extend .my-module;     border:
			3px solid fuchsia; } .my-module--is-active {     background-color:red; } .my-module__close-button {     position: absolute;     right:
			0;     top:
			

When I first started writing modules like this, I ended up using very complex classes to define the name of the module: .my-module__child-component__grandchild-component--modifier .

But in addition position to the dimension-dependent attributes, most subcomponents can extract their own independent modules. So if you leave the location to the parent element, we can set it to three small, self-contained modules.

MODULES/_MY_MODULE.SCSS:

.my-module {     //... } .my-module__child-component {     

MODULES/_CHILD_COMPONENT.SCSS:

.child-component {     //... } .child-component__grandchild-component {     position: absolute;     

MODULES/_GRANDCHILD-COMPONENT.SCSS:

.grandchild-component {     //... } .grandchild-component--modifier {     

Example.html:

<div
					class="my-module">
			<div
					class="my-module__child-component">
			<div
					class="child-component">
			<div
					class="child-component__grandchild-component">
			<div
					class="grandchild-component--modifier"></div>
			</div>
			</div>
			</div>
			</div>
		

.grandchild-componentand .child-component separate from their parent container. This module is used for his child container positioning. The advantage is that the nested UI components are completely detached from each other.

State (status)

The specific state of the module is defined as the module itself in the same file (as above .my-module--is-active ), but we want to keep the global state class separate, such as .is-hidden .

Theme (skin)

We write for each template market theme (such as ThemeForest and graphicriver make each skin), but we implement the specific style of the site by setting variable settings in a configuration file.

Sass will integrate everything

Configuration (Configuration)

application.scssThe first imported style file is _config.scss . Here, we set up global variables to use together. This includes colors, font sizes, fonts, response breakpoints, and so on.

We also include market-specific profiles that are used to set variables for the color copy of each market.

Mixins (mixed)

All mixin are stored in their own files and placed in a named mixins directory, and can be used globally. We have also imported the Mixin library that handles the browser vendor prefix, such as the Compass Sprites diagram and the vendor prefix.

Grid (Mesh)

Our grid framework is just a module.

Instead of using a span-5 grid class name like this in HTML, we use the Susy class name that is based on column width and independent of the module.

MODULES/_PAGE.SCSS:

.page {     //... } .page__sidebar {     @include span-columns(3,12); } .page__content {     

In the module .grid just contains everything, he just susy the grid container.

Internet Explorer

We still support IE7 and IE8. We used to use the HTML5 boilerplate method to handle those browser compatibility, but that means we have to use many .lt-ie8 of these class names to handle compatibility.

Now we use this technique to generate separate and style for those browsers application-ie8.css application-ie7.css .

The style specified by IE is written in the module.

MODULES/_MY_MODULE.SCSS:

.my-module {
			color: chartreuse;      @if
			$ie7 {         position: relative;         zoom:1;     

A good browser provides a concise application.css , no use of any IE spam code, contrary to the old IE users will get their own special version.

We can't do anything.

we do not pursue readable CSS output . When you write a module like this, you can view the class name and directly select the correct sass file instead of using the developer tool to try to find a particular style. Source maps is the same.

we are not going to remove every repetition point from our compiled CSS. we want to develop as easily as possible without impacting performance. Instead of using the Mixins module @extend so far, this will not increase the original file size.

Conclusion

In the first few months, we put the module's files in a messy stylesheets directory. When we add new features and transform existing features, the modules style files in our catalog are only increased.

The main style file from ThemeForest application.scss , now looks like this:

// Config
			@import config_global; @import config_themeforest;  // Vendor mixin libraries
			@import compass; @import susy;  // Our mixins
			@import mixins/**/*;  // Old crud. Our base styles, plus everything else that will eventually  // be converted into modules. @import old_stuff/**/*;  // Modules
			@import modules/**/*;  

We can successfully implement the modern CSS architecture without still dropping our existing styles or starting from scratch.

Extended reading

• for this method, the style is mainly referred to the starter project, try it, let us know your idea
• if you have never known smacss, you can go to smacss.com to learn more about the relevant introduction
Li>harry Roberts has a series of articles on the introduction of scalable CSS. Introduction to the introduction of the BEM syntax and the way it works
• Nicolas Gallagher has a lot of good sharing in this area, and the article on HTML semantics and the front-end architecture is a good overview of the idea, so we can benefit from it.

Translator Sign Language: the entire translation is carried out according to the original line, and in the translation process a slight personal understanding of the technology. If the translation has the wrong place, but also please peer friends pointing. Thank you!

If you want to reprint, please indicate the source:

English Original: http://webuild.envato.com/blog/ how-to-scale-and-maintain-legacy-css-with-sass-and-smacss/

Chinese translation: http://www.w3cplus.com/preprocessor/ how-to-scale-and-maintain-legacy-css-with-sass-and-smacss.html