http://smacss.com/book/categorizing

Categorizing CSS Rules

CSS 규칙들을 세분화

모든 프로젝트에는 조직(팀)이 필요합니다. 하나의 파일의 끝에 당신이 만든 모든 새로운 스타일을 추가하는 것은 스타일을 찾기 더 힘들게 만들고 프로젝트에 참가하는 모든 사람들이 혼란스러워질 것이다. 당연하게도, 너는 이미 준비가된 몇몇 조직에서 일해봤을 것이다. 다행스럽게도, 이 페이지에서 네가 읽을 것은 이미 존재하는 프로세스가 작동하는 것을 강조할 것이고, 만약 운이 좋다면 너의 과정(코드 짜는 방식)을 개선할 수 있는 새로운 방법을 보게 될 것이다.

ID 선택자를 쓸지 class 선택자를 쓸지 아니면 마음대로 선택할 수 있는 수많은 선택자들을 쓸지를 어떻게 고르나요? 어떤 요소가 주고 싶은 스타일을 받을지 어떻게 결정하나요? 어떻게 하면 너의 웹사이트와 스타일이 조직되는 과정을 이해하기 쉽게 만들 수 있을까요?

SMACSS의 가장 중요한 개념은 categorization (범주화)이다. CSS 규칙을 범주화함으로써, 우리는 어떤 패턴을 보게 될 것이고, 각각의 이런 패턴을 통해 더 좋은 방법을 정의할 수 있다.

다음은 5개 종류의 카데고리이다 :

Base
Layout
Module
State
Theme

우리는 종종 우리가 이 카데고리들을 넘나들며 스타일을 섞고 있는 것을 발견한다. 만약 우리가 우리가 스타일하기 위해 시도하고 있는 것이 무엇인지를 더 잘 알게 된다면, 우리는 이 규칙들이 뒤얽히는데서 오는 복잡함을 피할 수 있다.

각 카데고리에는 그 카데고리에 적용해야할 확실한 가이드라인이 있다. 이 별 거 아닌 것 같은 간결한(succinct) 분리가 우리에게 개발 과정동안 스스로 질문할 수 있게 만들어준다. 우리가 이것들을 어떻게 코딩했나요? 그리고 우리가 이 코드를 왜 이런방식으로 짰을까요? 같은 질문을 말이다.

카데고리화 하는 것의 커다란 목적은 우리의 디자인에 있는 반복되는 패턴화된 것을 코드화하는 것이다. 반복은 적은 코드, 유지보수가 쉽고, UX 일관성이 높아지는 결과를 낳는다. 이건 질 수 없는 결과이다 (These are all wins). 5가지 규칙에 대한 예외사항을 만드는 것이 유리할 수 있지만 그 예외사항들은 정당화 될 필요가 있다.

Base 는 기본이다. Base는 거의 오직 하나뿐인 요소 선택자인데, 속성 선택자, 가상클래스 선택자, 자식 선택자나 형제 선택자도 포함되기도 한다. 근본적으로 base 스타일은 이 요소가 페이지 어디에 있든 그렇게 보인다고 말한다.

Examples of Base Styles

html, body, form { margin: 0; padding: 0; }
input[type=text] { border: 1px solid #999; }
a { color: #039; }
a:hover { color: #03C; }

+ reset 같은 느낌이다.

Layout 규칙은 페이지를 섹션으로 나눈다. Layout은 하나 혹은 더 많은 module을 함께 묶어둔다.

Module 은 재사용가능한 것. 우리의 디자인에서 모듈화된 부분이다. Module은 callout, 사이드바 섹션, 물품 리스트 같은 것들이다.

State 규칙은 우리의 module 이나 layout이 특정 상황에 어떻게 보일지를 묘사하는 부분이다. 숨겨지거나 확장되었나? State는 module이나 layout이 크고 작은 화면에서 어떻게 보일지 상술하는 것에 관련되어 있다. State는 module이 메인 페이지나 더 안쪽의 다른 view에서 어떻게 보일지를 말하는 것과도 관련되어 있다.

마지막으로, Theme 규칙은 module이나 layout이 어떻게 보일지 설명하는 부분이라는 점에서 state 규칙과 비슷하다. 대부분의 사이트는 주제화하는 단계가 필요 없겠지만 theme에 대해 알고 있는 것이 좋다.

Naming Rules

규칙을 5개 범주로 나눔으로써, naiming convention (이름 짓기 규칙) 은 특정 스타일이 속한 범주가 무엇인지와 페이지의 전체 범위에서의 역할을 빠른 이해를 하는데 도움이 된다. 큰 프로젝트에서는 여러 파일에 스타일들이 쪼개져있을 확률이 높다. 이런 상황에서 naming convention은 스타일이 속해 있는 어떤 파일을 찾는 것을 쉽게 만들어준다.

나는 Layout, State, Module rule 규칙을 구별하는 접두사를 사용하곤 한다. Layout 규칙에는 나는 l- 을 사용한다(layout- 도 괜찮다). gird- 같은 접두사를 쓰는 것면 다른 스타일로부터 layout 스타일을 분리하는 것이 충분히 명확해진다. State 규칙에는 나는 is-hidden 이나 is-collapsed 같은 is- 접사를 붙인다. 이것은 코드를 매우 잘 읽히는 방법으로 묘사하는데 도움을 준다.

Module은 어느 프로젝트에서나 큰 묶음이 될 것이다. 결과적으로, 모든 모듈의 이름을 .module- 으로 시작하는 것은 쓸데없이 장황하다. Module에는 그냥 module 자체의 이름을 사용하면 된다.

Example classes

/* Example Module */
.example { }

/ Callout Module /
.callout { }

/ Callout Module with State /
.callout.is-collapsed { }

/ Form field module /
.field { }

/ Inline layout /
.l-inline { }

모듈 안에서 관계된 요소들은 접두사로서 기본 이름을 사용하면 된다. 이 사이트에서 코드 예제들은 .exm을 사용했고, 주석에는 .exm-caption 을 사용했다. 나는 주석 class를 바로 알아볼 수 있고, 그것이 코드 예제와 관련되어 있다는 것을 바로 이해할 수 있고, 코드 예제에 대한 스타일이 어디에 있는지 찾을 수 있다.

다른 module의 변형인 Moudle도 모듈 이름을 접두사로 사용해야한다. sub-classing은 Module 규칙 장에서 더 자세하게 다룰 것이다.

이 naming convention은 이 페이지 전체에 사용되었다. 내가 여기에 말했던 것들처럼, 이 가이드라인을 너무 엄격하게 지켜야한다는 압박을 느낄 필요가 없다. 너의 convention을 만들고 문서화하고 지켜라.




### 느낀점

- theme은 왜 있지? 이걸 나눌 필요가 있나 했는데 저자도 딱히 필요 없는 경우가 더 많을거라고 저술한 점이 재밌었다.
- 처음에 SMACSS 배웠을땐 한 element 에 class 를 여러게 주지 않을 때라서 is- 접두사 쓰는거 이해 안갔었는데, 원래 이름도 있으면서 상태에 대해 .is- 를 쓰면 매우 이해하기 쉬울 것 같다.
- BEM 쓰면서 완벽한 naming에 집착했는데.. SMACSS 저자의 말처럼 편하게 가야겠다. 어디까지나 코딩을 도와주는 보조 도구이지 얽매여야하는 도구가 아니니까
- 엄청 어려운 단어는 없는데 모르는 단어가 너무 많다..... 영어 공부 필수