#smaccs

はじめに

前回はベース、レイアウト、モジュールについて書きました。

1.ベース

2.レイアウト

3.モジュール

4.ステート

5.テーマ

今回はステートとテーマについて。

4.ステート

状態（ステート）を表すためのルール。

is-◯◯で指定するなどでスタイルを上書きしたり、すぐに変更したりできる。

————–例—————

is-disable

is-hidden

is-active

——————————–

といった感じに指定する。

もしくは

————–例—————

is-module名-disable

is-module名-hidden

is-module名-active

——————————–

など、モジュール名を使うとより指定しやすいかもしれない。

５.テーマ

全体の色のスタイルを変更、管理するルール。

テーマ用のCSSを用意する。

theme-◯◯などのプレフィクスをつけてあげるとわかりやすい。

おわりに

SMACCSの５つのルールを知り、プレフィックスの有効性を実感しました。

コードの量の最適化、再利用性、共通に理解できる命名など向上させるために今後活用してみようと思いました。

————参考URL———-

SMACSSを利用したCSS設計について

As multiple repositories came to life and our existing architecture began to grow; it was only a matter of time before a style guide was no longer a nice to have, it was a must have.

One of my initial attractions to Medeo was their attention to, and care for design. This came as no surprise as one of the initial investors was Andrew Wilkinson, CEO of MetaLab. MetaLab was responsible for the initial designs and as expected, they were pixel perfect. But behind those beautiful designs was not a whole lot of reusable code.  

At QHR, we follow agile methodologies and work iteratively to reach our goals. Third party design agencies are a great solution for many companies but for ourselves, an in-house design team eventually made sense. 

Since then, we have done our best to write reusable and maintainable CSS when necessary. But as the saying goes, “the amount of people that can effectively write CSS on one project is one”. As a designer and sole contributor of CSS at Medeo the frustration sets in when beautifully crafted components begin to be replaced by specificity. 

Sometimes you just have to swallow the pill, no matter how much it hurts. Spaghetti code, page selectors and the dreaded !important property are sometimes what it takes to quickly prove business value. Thankfully as our team has grown and business requirements have changed, a living style-guide or “UI toolkit” has become a necessity. 

I use a similar approach where I use SMACSS  file structure to maintain my sass.

In response to: In Defense of Descendant Selectors and ID Elements – Jeffrey Zeldman Presents The Daily Report

Rare? RARE? What kind of dinky little disposable sites does Zeldman work on? I can't take anything that he says at face value, because I just don't work on the kinds of projects he works on. I've never worked on a serious project that didn't have tons of jumbled css.

Also, is it just me, or do his arguments for ids just not make any sense? How is an id "more semantic" than a class name? #footer and .footer both say footer. What's more meaningful about # than . ?

Saying you just need a master chef and permission to do some refactoring shows a lack of understanding of two things.

One. Refactoring CSS is hard. When it's not compartmentalized in the manner of OOCSS or SMACSS it's really, really hard. Because it's all one jumble and you have to test everything on every change.

Two. A master chef would have to have absolute control over all html and css. I mean code review every checkin and make every dev do things the 'right' way. But if there's no system of compartmentalization, then every contributor has to have just as much knowledge and comprehension as the master chef. That's totally untenable. Each dev needs to write 'good' CSS on their own, or you'll have to correct them every time.