'2015/01'에 해당되는 글 2건

  1. 2015.01.26 더 깨끗한 코드를 위한 Sass 믹스인 살펴보기
  2. 2015.01.13 Sass 스타일가이드

Written by John W. Long on August 28, 2011 Translated by Chuck Lee
이 글은 The Sass Way에 있는 글 Leveraging Sass mixins for cleaner code를 번역한 글로 많은 의역이 포함되어 있습니다.

의심의 여지없이, Sass에서 가장 강력하고 유용한 기능은, 작성된 코드를 재사용이 가능하도록 만들어주는 믹스인(mixin)입니다.

매크로 같은 믹스인

믹스인은 Sass의 매크로라고 할 수 있습니다. 만약 개발을 프로그래밍을 해본 경험이 있다면, 함수(functions), 프로시저나 메소드처럼 생각해도 괜찮습니다. 하지만 기술적으로는 이런 개념들과는 완전히 다르게 런타임으로 코드를 실행시키는 것이 아니고, 컴파일할 때 코드를 생성하는 목적으로 사용됩니다.

믹스인은 어떻게 작동하는가

Compass 프로젝트는 당신을 편하게 만들어줄 다양한 믹스인들로 구성되어 있습니다. CSS3부터 타이포그라피, 레이아웃, 이미지 가공등, 해당 기능을 방탄 CSS로 작성하기 쉽게 만들어줍니다. 우리는 Compass를 Sass의 표준 라이브러리로 생각하고 있습니다.

Compass에서 CSS3에 대한 지원은 가장 끝내주는 기능이라 할 수 있습니다. Compass는 아래 예제와 같이, 새로운 기능들을 모든 브라우저에서 사용할 수 있게 해주는 CSS3 믹스인들을 제공합니다.

예를 들면, border-radius믹스인은 border-radius를 간단하게 사용할 수 있게 해줍니다.

a.button {
    background: black;
    color: white;
    padding: 10px 20px;
    @include border-radius(5px);
}

이 코드의 결과물:

a.button {
    background: black;
    color: white;
    padding: 10px 20px;
    -moz-border-radius: 5px;
    -webkit-border-radius: 5px;
    -ms-border-radius: 5px;
    -o-border-radius: 5px;
    -khtml-border-radius: 5px;
    border-radius: 5px;
}

border-radius믹스인이 6줄의 코드로 변한 결과물을 볼 수 있습니다. 이 6줄은 모든 최신 웹브라우저에서 border-radius를 사용할 수 있게 해줍니다(만약 당신이 직접 작성한다면, 아마 Opera(-o)나 Konquerer(-khtml)를 지원하는 코드는 작성하지 않았을 수도 있을거에요. 하지만 Compass는 전부 무료로 작성해줍니다!)

위에서 사용된 @include는 Sass에게 믹스인을 사용하겠다고 말하는 것입니다. 이것은 border-radius라는 믹스인의 이름을 그대로 사용합니다. 괄호안에는 믹스인에게 전달하는 아규먼트를 사용합니다. border-radius믹스인은 하나의 아규먼트만 가집니다. 이 경우에는 5px이 아규먼트 입니다.

자기 코드 작성해보기

border-radius의 소스를 살펴보도록 합시다. 실제 Compass에 사용된 버전은 조금 더 복잡하지만, 개념 정림을 위해 단순화된 버전을 보여줄 것입니다. 이 정도면 자기 코드를 작성하기 위한 개념을 잡는 데는 충분합니다.

@mixin border-radius($radius) {
    -moz-border-radius: $radius;
    -webkit-border-radius: $radius;
    -ms-border-radius: $radius;
    border-radius: $radius;
}

@mixin이라는 선언으로 시작되고, 그 다음에는 믹스인의 이름이 나옵니다. 이 경우에는 border-radius가 되겠죠. 믹스인의 이름은 여백만 없다면 어떠한 문자 조합도 사용이 가능합니다. 그 다음에는 (...)의 형태로 괄호안에 아규먼트를 리스트로가 들어옵니다. 위에 나온 믹스인은 하나의 아규먼트인 $radius만 가집니다. 아규먼트는 콤마로 나눠질 수 있는 한도 내에서는 계속해서 사용될 수 있습니다.

그 다음에 믹스인의 정의는 {...}안에 들어옵니다. 믹스인에는 어떤 CSS속성이라도 사용할 수 있습니다. 여러 속성들과 선택자들을 조합해서 선언할 수 있는 것이지요.

이 경우에는, border-radius 믹스인은 모든 주요 브라우저에서 사용 가능한 형태의 border-radius 속성을 포함하고 있습니다.

$radius아규먼트나 변수는 CSS속성에 값으로 설정되고는 합니다. 이 테크닉을 사용하면 믹스인에 하나의 값만 전달하더라도 결과물에서는 4번 반복되어 나타나게 할 수 있습니다. 또한 실수로 특정 브라우저에만 잘못된 값을 사용하는 경우도 방지할 수 있으며, 타이핑 양도 많이 줄여줍니다.

디폴트 아규먼트

$radius아규먼트에 디폴트 값을 추가해서 이 믹스인을 업그레이드 할 수도 있습니다. 이렇게 말이죠:

@mixin border-radius($radius: 5px) {
    ...
}

이렇게 하면 $radius아규먼트는 optional이 됩니다. 그러면 이렇게도 사용할 수 있게 되죠:

@include border-radius;

선언할 때 사용된 디폴트 값이 결과물로 나오게 됩니다. 이 경우에는 위에서 선언했던 것 처럼 5px이 되겠네요.

꽤 유용할 것으로 판단되는 또 다른 트릭은 믹스인을 위한 디폴트 값으로 사용될 변수를 선언언한 후에 사용하는 것입니다:

$default-border-radius: 5px !default;
@mixin border-radius($radius: $default-border-radius) {
 ...
}

이렇게 하면 프로젝트끼리 코드를 공유해야 할 경우에 특히 유용합니다. 글로벌 변수로 디폴트 값을 선언하고 필요할 때만 값을 오버라이드 하면 되니까요.

키워드 아규먼트

마지막으로 설명할 믹스인 기능은 Sass 3.1에서 새롭게 소개된 키워드 아규먼트입니다. 키워드 아규먼트는 믹스인이 여러개의 야규먼트를 받아야 할 때 특히 유용합니다. 만약 아규먼트들에 디폴트 값이 설정되어 있으면, 다른 아규먼트들의 값을 전달하지 않더라도 아규먼트의 이름을 이용해서 특정 아규먼트 값만 전달할 수 있습니다.

@if구문을 이용해서, 더 발전된 버전의 border-radius믹스인을 만들 수 있습니다:

@mixin border-radius($radius: 5px, $moz: true, $webkit: true, $ms: true) {
    @if $moz    { -moz-border-radius:    $radius; }
    @if $webkit { -webkit-border-radius: $radius; }
    @if $ms      { -ms-border-radius:     $radius; }
    border-radius: $radius;
}

위의 코드는 $moz, $webkit, $ms값에 따라 Firefox, Safari, Internet Explorer를 위한 코드를 출력해줍니다. 모든 아규먼트에 디폴트값이 설정되어 있는 경우에 이렇게 하면 Internet Explorer를 위한 코드만 날려버릴 수 있습니다:

@include border-radius($ms: false);

이렇게 하면 아래처럼 이름을 사용하지 않고 모든 아규먼트 값을 넣어줘야 할 때보다 훨씬 간편하지요:

@include border-radius(5px, true, true, true);

키워드 아규먼트를 사용하면, 믹스인을 호출할 때 선언했을 때와 다른 순서로 아규먼트를 사용해도 상관없습니다.:

@include border-radius($ms: false, $radius: 10px);

결론

여기까지가 Sass 믹스인에 대한 대략적인 내용입니다. 당신이 코드를 짤 때 더 나은 아이디어를 적용시킬 수 있으려면 잘 만들어진 Sass프로젝트, Compass의 소스코드를 살펴보는 것을 권장합니다. 훌륭한 기술들을 배울 수 있는 200개도 넘는 믹스인이 포함되어 있습니다. 또한 Compass Doc에는 "View Source"링크가 제공되기 때문에 믹스인이 정확하게 어떻게 작동하는지 살펴볼 수 있습니다. Compass의 border-radius부터 어떻게 구현되었는지 시작해보는 것은 어떨까요.

저작자 표시 비영리 변경 금지
신고
Posted by 2bchuck

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/


저작자 표시 비영리 변경 금지
신고
Posted by 2bchuck


티스토리 툴바