SMACSS: Are you ready to get smacked?

CSS is one of the least interesting part of the web development. Sure it brings beauty to a website, but the culmination of beauty with dynamic interaction is probably the exciting part of web development. Definitely when I think of web development and new technology, jQuery, YUI, or any of its derivative libraries are the first things that come to mind.

In my opinion Normalize.css is the foremost library that brought CSS development back into favor. Sure there were other libraries such as Blueprint available, I do not think any other CSS library has permeated the web to the level that Normalize.css has done.

I was amazed at the level of simplicity that Normalize.css offered compared to other competing css libraries.

Bootstrap is the next CSS library that is worthy of an honorable mention. This library brought responsive web design mainstream. Due to the ease of use, Bootstrap has made responsive design the standard rather than the exception.

After all these revolutions to today’s interface development, the same concepts on developing scalable CSS has remained the same. I was first introduced to Scalable and Modular Architecture for CSS through the YUI Pure project .Basically, the structure presented on the SMACSS website tries to solve the issue where the CSS theme style is so tightly integrated together with a certain design structure to the point that it may be faster to redo a web interface.

The rules presented is as follows:

  1. Base Rules
  2. Layout Rules
  3. Module Rules
  4. State Rules
  5. Theme Rules
  6. Changing State

What will happen to SCSS or LESS?
Drawing upon my experience, most of the SCSS or LESS complexity can be eliminated by breaking down the CSS using the SMACCSS rules. There are still a niche that can be fill using compiled CSS, especially when dynamic CSS is brought to the table. Let’s ignore the calc function as it still cannot perform computations across browsers.

As I mentioned in the previous paragraph, math calculations cannot be performed across browsers. This is a huge issue that breaks user experience. Once all browsers can handle the calc operation natively, then we can consider LESS or SCSS as increasingly less valuable.

Another downfall of using SMACSS rather than LESS or SCSS is that values cannot be easily reused. For example, a variable can used to fill in values for both background and color values. In plain old, CSS the color value needs to duplicated in separate rules.

There may be other examples, but it is quite clear that SCSS or LESS will stick around because of the niche that standard CSS cannot fill. But with clear and concise CSS that follows the SMACSS has provided, I see that the complexity of using SCSS and LESS to increase the odds that scalable CSS will not be created.

Increase complexity?
Just as MVC brought structure to data and views but increase code complexity, structured CSS will increase the complexity of a CSS file. The main question is does the increase in complexity outweigh the benefits? Surely, I do not think this change will leave as big of an impression as MVC has, since the view is tightly integrated with the underlying CSS. But structured CSS will make code easier to debug due to the way that CSS rules have precedence, especially in regards to the state rules.