Sass 스타일가이드

Written by Chris Coyier on May 29, 2013 Translated by Chuck Lee
이 글은 CSS-TRICKS에 있는 글 Sass Style Guide를 번역한 글로 많은 의역이 포함되어 있습니다.

지금처럼 많은 사람들이 Sass를 사용하고 있는 상황은, 어떻게 작성해야 하는지에 대해 생각하게 만듭니다. CSS 스타일 가이드가 일반적인 것처럼, CSS 스타일 가이드를 Sass에 맞게 확장시켜서 사용해 볼만합니다.

제가 생각해왔던 몇 가지 아이디어들이 있습니다. 그대로 사용하거나 스스로 만들어가는 것에 활용할 수도 있습니다.

일반적인 CSS Formatting 규칙 / 스타일 가이드를 사용하세요.

이번 포스트는 Sass에 관한 것이긴 하지만 이미 사용하고 있는 좋은 CSS 스타일 가이드가 있다면 기본 베이스로 사용하기를 권장합니다. 만약 사용하고 있지 않다면, 이 스타일 가이드가 도움이 될 것입니다. 여기에 포함되어 있는 내용들은 다음과 같습니다:

1. 들여쓰기의 통일성을 유지하세요
2. 콜론과 괄호의 앞뒤 여백의 통일성을 유지하세요
3. 라인 당 하나의 selector, 하나의 규칙을 사용하세요
4. 비슷한 속성들은 함께 나열하세요
5. 클래스 이름을 짓는 계획을 세우세요
6. #hotdrama같은 ID를 사용하지 마세요
7. 기타

@extend(s)를 먼저 사용하세요

.weather {
    @extends %module; 
    ...
}

이 class가 다른 곳에 있는 규칙을 상속받았다는 것을 바로 알 수 있게 하는 것이 좋습니다.

일반 스타일이 다음에 오게 됩니다

.weather {
    @extends %module; 
    background: LightCyan;
    ..
}

@include(s)가 그 다음에 옵니다

.weather {
    @extends %module; 
    background: LightCyan;
    @include transition(all 0.3s ease-out);
    ...
}

이것은 시각적으로 @extends와 @includes를 분리해서 @includes 그룹을 더 읽기 쉽게 만들어줍니다. 또한 "직접 작성한" @includes와 "vendor에서 제공된" @includes를 분리해도 괜찮습니다.

Nested 셀렉터들은 맨 마지막에 작성합니다

.weather {
    @extends %module; 
    background: LightCyan;
    @include transition(all 0.3s ease);
    > h3 {
        border-bottom: 1px solid white;
        @include transform(rotate(90deg));
    }
}

Nested 셀렉터 다음에는 아무 것도 추가하지 마세요. 그리고 Nested 셀렉터 안에 작성될 규칙들도 위에 언급된 순서대로 작성해줍니다.

모든 Vendor Prefix들은 @mixins을 사용하세요

Vendor prefix들은 시간의 영향을 받습니다. 브라우저들이 업데이트 될수록, 필요성은 줄어들기 마련입니다. 그러한 변화들은 mixin들(또는 당신이 사용하는 라이브러리들)의 업데이트가 처리해줄 것입니다. mixin이 한 줄로 끝난다고 하더라도 상관업습니다.

@mixin을 사용하지 않는 유일한 경우는, vendor-prefix를 작성한 경우와 없는 경우로 나눠서 작성하는 것이 더 나쁜 결과를 초래할 수 있는, 그대로 표준화 될 가능성이 거의 없는 vendor prefix를 사용할 경우입니다. 예를들면 -webkit-line-clamp나 -ms-content-zoom-chaining등등을 사용할 때 말입니다.

최대 Nesting: 3단계

.weather {
    .cities {
        li {
            // no more!
        }
    }
}

더 많은 단계를 사용해야 한다면, 엉터리 셀렉터를 사용하고 있을 가능성이 많습니다. 엉터리라는 말은 HTML에 아주 종속적으로 구체적으로 지정하여서 재사용이 불가능하다는 말입니다. 또한 코드를 이해하기에도 어려울 것입니다.

만약 당신이 클래스들이 너무 많아서 진정으로 태그 셀렉터들을 사용하기 원한다면, 원치않는 cascading을 피하기 위해서라도 꽤 구체적으로 작성해야할 것입니다. 그리고 CSS의 재사용의 이점또한 취할 수 있을 수도 있고요.

.weather
    > h3 {
        @extend %line-under;
    }
}

최대 Nesting: 50줄

만약 하나의 Sass nest 블록이 그보다 더 길어지게 되면, 코드 에디터의 한 화면에서 보는 것이 불가능해질 가능성이 매우 많아지고, 이해하기 어려워지기 시작합니다. nesting을 하는 제일 중요한 이유는 편의성과 관념적으로 그룹짓기 위함입니다. 사용하기에 불편해진다면 사용하지마세요.

글로벌이나 특정 섹션을 위한 Sass 파일들은 목차에만 있어야 합니다

다시 말하면, 글로벌이나 특정 섹션을위한 파일은 만들지 마시길 권장합니다. 모든 스타일들이 컴포넌트 단위로 구성될 수 있게 노력하세요.

Vendor/Global Dependencies를 먼저 배치하고, Authored Dependencies, 그 다음이 Patterns, 그 다음이 Parts 순으로 작성하세요.

그렇게 되면 "목차" 다음과 같아지게 됩니다:

/* Vendor Dependencies */
@import "compass";

/* Authored Dependencies */
@import "global/colors";
@import "global/mixins";

/* Patterns */
@import "global/tabs";
@import "global/modals";

/* Sections */
@import "global/header";
@import "global/footer";

Compass, 색상, mixin같은 dependency들은 코드로만 존재할 뿐 CSS를 컴파일할 떄 포함되지는 않습니다. Patterns를 Parts보다 먼저 배치하는 것은 더 구체적으로 작성하는 코드가 patterns를 문제없이 오버라이드(override) 하기 위함입니다.

상식이 허용하는 선에서 최대한 작은 파일로 나누세요.

작은 파일로 쪼갠다고 해서 문제될 것 없습니다. 프로젝트에 적합하다고 생각이 될 때까지 나누세요. 파일을 더 많이 나누어서 작게 만드는 것이 더 큰 파일로 적게 나누는 것보다 찾아서 작업하기 쉽습니다.

...
@import "global/header/header/";
@import "global/header/logo/";
@import "global/header/dropdowns/";
@import "global/header/nav/";
@import "global/header/really-specific-thingy/";

저는 각각의 서브 임포트를 가지고 있는 a _header.scss같은 파일을 임포트하기 보다는 global.scss에 이렇게 작성합니다. 서브 임포트는 관리가 안될 수 있기 때문입니다.

너무 많은 리스트를 작성해야 한다면 Globbing을 사용하는 것도 좋습니다.

Partials는 _partial.scss라고 이름짓습니다.

이것은 그 자체로 컴파일 되는 것을 막기 위한 일반적인 네이밍 규칙입니다. 이렇게 하면 코드에는 포함되지만 자체적으로 컴파일되진 않습니다. 개인적으로 _dropdown-menu.scss처럼 "실제 사용하는" 파일이름에 대쉬를 붙이는 것을 좋아합니다.

로컬에서, 라인 매핑이 되도록 컴파일하세요

여기를 살펴보세요. 이 포스트에 따르면 개발 툴들은 임포트된 파일이라고 하더라도 정확하게 어떤 파일, 어디에서 문제가 생겼는지 말해준다고 합니다.

배포할 때는 Compressed로 컴파일 하세요

상용 웹사이트들은 compressed CSS만 사용되어야 합니다.

.css 파일들은 커밋하지 마세요.

개발 운용적인 측면의 이야기이긴 하지만 repository에 .css파일이 없는 것이 좋습니다. 배포중에 편집이 일어날 수 있습니다. 그렇기 때문에 repository에는 잘 정리된 Sass 파일들만 있는 것이 좋습니다. 그래야 버전 컨트롤 시스템이 제공하는 diff 툴이 Sass파일에서 사용되게 됩니다. compressed CSS파일에서 diff를 사용하는 대신에 말이죠.

주석에 관대해지세요

코드에 주석을 남겨놓은 것을 후회하게 되는 경우는 매우 드뭅니다. 도움이 되거나 무시되는 경우가 많지요. 코멘트들은 compressed 코드로 컴파일 될 때, 사라져 버리니 걱정하지 마세요.

.overlay {
    /* modals are 6000, saving messages are 5500, header is 2000 */
    z-index: 5000; 
}

코멘트 또한 표준화 시키고 싶을 겁니다. Sass에서는 // 신택스를 사용할 수 있으니 쉽게 한 줄 코멘트를 작성할 수 있습니다.

모든 일반적인 숫자와 상수는 변수화 시키세요

0과 100% 이외의 숫자를 반복해서 사용하게 된다면, 변수에 넣으세요. 의미도 생기고 통일성을 유지하는 데에도 훨씬 도움이 될 것입니다.

만약 숫자가 명확한 의미를 가지고 있다면, 그것 또한 변수에 넣어야 될 신호입니다.

$zHeader: 2000;
$zOverlay: 5000;
$zMessage: 5050;

.header {
    z-index: $zHeader;
}
.overlay {
    z-index: $zOverlay;
}
.message {
    z-index: $zMessage;
}

위와 같이 z-index를 변수화 시켜서 관리한다면 여러 파일에 나뉘어져 있어도 한 곳에서 관리할 수 있게 됩니다.

모든 색상들은 변수화 시키세요

white와 black은 제외해도 될 거라고 봅니다. 그렇지 않을 거라 생각하지만 색상은 계속해서 바꾸게 됩니다. 변수에 넣고 사용하면 쉽게 수정할 수 있게 되죠. 또한 lighten()이나 darken()같은 Sass의 color function들을 이용할 수 쉽게 만들어줍니다.

미디어 쿼리들도 Nest와 이름을 사용하세요

Sass에서 미디어 쿼리를 nest할 수 있게 된다면 1) "어딘가에나 있기 마련인 에러가 발생하기 쉬운 코드 때문에 selector를 다시 사용할 필요가 없어진다" 2) "당신이 작성하거나 오버라이드한 규칙들이 CSS 파일의 맨 밑이나 다른 파일에 있는 경우와는 다르게 매우 명확하다" 는 것을 의미합니다.

.sidebar {
    float: right;
    width: 33.33%;
    @include bp(mama-bear) {
        width: 25%;
    }
}

여기에 가면 더 많은 내용이 있습니다. 더불어 이름을 잘 짓는 것은 매우 중요합니다.

마지막에 Shame 파일을 사용합니다

글로벌 스타일 시트 맨 마지막에 _shame.scss파일을 임포트하세요.

@import "compass"

...

@import "shame"

만약 뭔가를 급히 수정해야 한다면, 여기에다 작성할 수 있습니다. 나중에 시간이 있을 때, 수정된 부분들을 정상적인 구조에 옮기면 됩니다. 더 보기

마지막 결과물은 당신에게 달려 있습니다

Sass는 당신의 능력을 제한하지 않습니다. Sass로 작성한 결과물이 잘못된 것은 당신이 잘못된 코드를 작성했다는 의미일 뿐입니다. Sass를 이용해 작성한 CSS파일이 이상하다면 Sass없이 작성해도 마찬가지일테니까요.

출처 : http://css-tricks.com/sass-style-guide/