BEM 소개

BEM 구조가 뭐냐? 먼저 BEM은 Block, Element, Modifier의 약자다. 즉, 이 세가지로 구성된 이름을 짓는 것이다. 작성할 때는 Block__Element--Modifier 이런 식으로 작성하면 된다. __ 와 --로 구분을 해주는 것이다.

Block : block은 그 자체로 의미가 있는 독립적인 엔티티이다. 예를 들면 'header', 'container', 'menu' 이런 것들. 독립적인 엔티티이기 때문에 block 그 자체로 단독적으로 사용이 가능하다. Element : element는 독립적인 의미가 있는 건 아니지만 의미상 해당 block에 연결된 일부다. 예를 들면 'menu item', 'list item', 'header title' 이런 것들이다. 작성할 때는

.menu__item { ... }

이렇게 쓰면 된다. menu는 block이고 item은 element다. Modifier : modifier는 block이나 element의 속성을 담당하며, 모양이나 행동을 변경할 때 사용한다. button을 예로 들어보자.

.button {
    display: inline-block;
    border-radius: 3px;
    padding: 7px 12px;
    border: 1px solid #d5d5d5;
    background-image: linear-gradient(#eee, #ddd);
    font: 700 13px/18px Helvetica, arial;
}

.button--state-success {
    color: #fff;
    background: #569e3d linear-gradient(#79d858, #569e3d) repeat-x;
    border-color: #4a993e;
}

.button--state-danger {
    color: #900;
}

BEM을 사용하여 button이라는 block에 일반 버튼과 두가지 상태의 버튼의 스타일을 지정해줬다. block--modifier-value 구문을 사용했다.

나도 BEM 구조를 제대로 잘 사용하는 건 아니지만 여기까지만 이해해도 반은 이해했다고 생각한다.

BEM의 장점

BEM이 뭔지는 이제 알겠는데 그럼 왜 굳이 BEM을 사용해서 CLASS를 명명하는 것일까? 단점도 있겠지만 우선 장점부터 살펴보자면,

1. 재사용성과 유지보수 용이성 : 위에서도 언급했듯이 block은 독립적인 엔티티이기 때문에 block만 분리하여 사용이 가능하고 비슷한 디자인 패턴을 가진 요소들을 쉽게 구현하고 조합할 수 있다. 다양한 방식으로 독립적인 block을 구성하고 재사용하면 유지 관리해야 하는 CSS 코드의 양도 줄어든다.
2. 가독성 향상 : BEM은 명확한 네이밍 규칙을 제공하기 때문에 클래스명 자체가 해당 요소들의 역할과 관계를 쉽게 이해할 수 있다.
3. 스타일 충돌 최소화 : BEM은 스타일 충돌을 방지하기 위해 클래스명에 중첩을 많이 사용하여 전역 스타일을 오염시키지 않고 더 예측 가능하고 격리된 스타일을 적용할 수 있다.
4. SASS와의 조화 : SASS의 변수와 믹스인을 활용하면 스타일 코드가 더욱 의미 있게 구성이 된다. 그리고 SASS에서 요소를 쉽게 찾을 수 있다. SASS에는 부모참조자(&)라는 걸 쓸 수 있는데, BEM구조 사용으로 클래스 네임이 길어져도 부모참조자를 활용하면 .menu 라는 block 아래에 &__list, &__title 이런 식으로 작성을 할 수 있어 어떤 block의 요소인지 바로 알 수가 있다.

BEM의 단점

1. 클래스명의 길이 : 아무래도 네이밍 규칙 때문에 클래스명이 길어질 수밖에 없다. 그래서 HTML만 보면 좀 지저분해보일 수 있다. 그리고 CSS 파일에 작성할 때도 긴 클래스명을 반복해서 사용해야 하기 때문에 복잡해보일 수 있다.
2. 학습 곡선 : 처음에는 BEM의 네이밍 규칙과 구조에 익숙해지는 데에 시간이 걸릴 수 있다. 그리고 BEM 구조가 좀 복잡하게 느껴질 수도 있다는 생각도 든다. 계속 연습해보고 직접 해보는 방법밖에 없겠지만 익숙해지기까지 시간이 걸릴 수 있다.
3. 클래스명 중복 가능성 : 클래스명 중복을 방지하기 위해 중첩된 요소들을 포함한 복합 클래스명을 사용하는데 이런 구조로 인해 불필요한 클래스명이 추가될 수 있다.

참고할만 한 링크

BEM구조에 대해서 공부하면서 참고했던 링크들이다.

클래스 네임을 생각하는 데 도움을 줄 수 있는 링크 1 클래스 네임을 생각하는 데 도움을 줄 수 있는 링크 2 예시를 통한 BEM

마치며

진작 한번 정리를 해볼걸! BEM구조가 뭔지 이해하고 클론코딩할 때 사용했는데도 제대로 사용하지 못했다. 쓰다보니 헷갈리기도 하고 이게 맞나? 하는 생각이 들기도 하고 그랬던 기억이 난다. 지금 생각해보면 와 진짜 반만 이해했구나 싶은 생각도 들고..

다음에 또 내가 뭔가를 하게 된다면 그땐 제대로 활용하고 싶다.

위 문서에서는 HTML 태그를 직접적으로 선택하여 스타일을 적용하는 것에 대한 문제점을 다루고 있다. 동시에, 태그를 직접 타겟팅하기 보다는 클래스를 사용하기를 권장한다는 내용이기도 하다.

태그 이름에 스타일을 줄 수 있는데 왜 클래스를 사용해야 하냐고 질문할 수도 있는데 그에 대한 설명을 이제부터 할 예정이다.

HTML 태그는 불가지론적이다.

HTML 태그는 추상적인 개념이며 프로젝트의 맥락이나 사용 목적을 알지 못하며, 주로 의미론적인(semantic) 구조와 웹 접근성, 검색 엔진 최적화(SEO)를 위한 도구로 사용되어야 한다. 또한 외관을 결정하는 역할은 담당하지 않아야 한다.

<div class="element">
    <div>
        <h2>Title</h2>
        <p>Text</p>
        <p>Text</p>
        <ul>
            <li>List item</li>
            <li>List item</li>
        </ul>
        <div>
            <h2>Title</h2>
            <p>Text</p>
            ...
        </div>
    </div>
    <div>...</div>
</div>

위 HTML 문서를 예로, .element 의 자식인 div 내의 모든 p 태그의 텍스트를 파란색으로 설정하고 싶다면 아래처럼 css를 작성하면 된다.

.element > div p {
    color: blue;
}

우리는 불필요한 클래스를 추가하지 않고도 이렇게 직관적으로 작성하여 원하는 결과를 얻을 수 있다. 물론 이렇게 작성해도 큰 문제가 없다고 생각할 수 있다.

다음으로, 새로운 스타일을 적용시키기 위해 .element 의 자식인 div 내의 h2와 두개의 p를 래핑해야 하는 경우라면 아래처럼 작성할 수 있다.

.element > div > div p {
    color: blue;
}

점점 지저분해지고 있다. 그리고 .element의 자식인 div와 또 그 자식인 div가 어떤 부분인지 이해하기가 어려워지고 있다. 작은 규모의 프로젝트에서는 이렇게 작성하여도 문제가 발생하지 않을 수 있지만 DOM 구조의 변경이나 확장성을 고려했을 때 유지보수가 어렵고 재사용성에서도 기능이 떨어진다.

아래는 class를 활용하여 스타일을 적용한 예시이다.

//HTML
<div class="element">
    <div>
        <p>This is a paragraph.</p>
        <p class="blue-text">This is a blue paragraph.</p>
    </div>
    <div>
        <p>Another paragraph.</p>
    </div>
</div>

//CSS
.blue-text {
  color: blue;
}

'blue-text'라는 class를 원하는 위치에 추가하면 해당 텍스트가 파란색으로 적용이 된다.

이렇게 태그를 직접 타겟팅 하는 대신 class를 활용하여 스타일을 적용하면 유연성이 높아지고, 구조와 스타일 간의 연결이 유연해진다.

성능 문제

브라우저가 CSS 선택자를 해석할 때 오른쪽에 있는 선택자를 시작해서 왼쪽으로 이동하여 매칭되는 요소를 찾는데, 이 방식은 스타일 규칙을 적용할 때 중요한 역할을 한다.

예를 들면 아래와 같은 HTML 구조가 있을 때,

<div class="container">
    <div class="box">
        <p>This is a paragraph.</p>
    </div>
</div>

1. 태그 직접 타겟팅한 경우

.container div p {
    color: blue;
}

이 경우에 브라우저는 모든 'p'를 찾고, 그 다음 'div'태그를 찾아 '.container'내부에 있는지 확인을 한 후, '.container' 클래스가 적용된 요소를 찾는다.

2. class 사용한 경우

.blue-text p {
    color: blue;
}

이 경우엔 브라우저가 '.blue-text'클래스가 적용된 요소를 찾고, 그 다음 이들 요소 내부에서 'p'태그를 찾는다.

class를 사용했을 경우에 브라우저가 보다 더 직접적으로 해당 요소를 찾아내므로 작업을 더 효율적으로 수행할 수 있다.

예외 및 타협

물론 모든 요소에 클래스를 추가하려면 코드가 복잡해질 수 있다. 이 경우에는 필요한 요소에만 클래스를 추가하고, 전체적으로는 태그를 직접 타겟팅하거나 더 범용적인 스타일을 적용하는 접근방식을 선택할 수도 있다.

웹사이트 내에서 특정 상황에만 스타일을 변경해야 하는 경우도 있을 수 있다. 예를 들어, 사용자의 록읜 여부에 따라 다른 스타일을 적용해야 한다고 가정했을 때, 이런 경우에는 로그인 여부에 따라 클래스를 동적으로 추가하여 스타일을 변경할 수 있다.

요지는 CSS 방법론은 개발 과정을 효율적으로 만들어 주지만, 모든 상황에서 무조건 이 방법을 적용해! 라기 보다는 프로젝트의 특성과 요구사항을 고려하여 적절한 방식을 선택하는 것이 좋다는 것이다.

마치며

어느정도 인식도 하고 있고 대충 알고는 있던 내용이었는데 이렇게 정리하니 또 새롭게 느껴진다. 그리고 알고 있다고 생각했는데도 직접 글로 정리를 해보니 내가 잘 알고 있는 게 맞나? 하는 생각도 들고, 내가 아는 걸 남들이 볼 때도 알아들을 수 있게 설명하는 게 쉬운 일이 아니구나라는 생각도 들었다.

물론 내가 다시 보려고 정리한 글이긴 하지만, 다른 사람들이 볼 때도 과연 내가 정리한 글이 이해가 되기는 하는 걸까? 하는 마음으로 계속 정리를 했다.

처음 배울 때에는 태그를 타겟팅해서 스타일을 적용하는 방식으로 CSS를 작성하기도 했었는데 확실히 이 글을 본 뒤로는 웬만하면 class를 활용해서 스타일을 적용하려고 노력하고 있다. 글에서 설명한 대로 모든 요소에 class를 적용하려다 보니 코드가 지저분해지기도 하지만 확실히 어떤 HTML 구조에 대한 스타일을 적용하는 건지 바로 확인이 되는 게 제일 좋은 점이라고 생각한다.

웹 접근성 다음에 항상 같이 따라오는 말이 웹 표준인 것 같다. 그만큼 중요도가 높다는 의미 아닐까 생각한다.

웹 표준(Web Standards)이란?

어떤 웹 브라우저에서든 동일한 웹 페이지를 볼 수 있도록 의미에 맞는 요소들을 재정립 시키고 각각의 브라우저가 갖고 있던 독자적인 요소들을 배제시킴으로써 어느 브라우저에서든 사용하기 편리한 환경을 만들게 되었다.

다른 기종 혹은 플랫폼에 따라 달리 구현되는 기술을 동일하게 구현함과 동시에 어느 한쪽에 최적화되어 치우지지 않도록 공통요소를 사용하여 웹 페이지를 제작하는 기법을 의미한다.

표준화 단체인 W3C(World Wide Consortium)가 권고한 표준안에 따라 웹사이트를 작성할 때 이용하는 HTML, CSS, JavaScript 등에 대한 규정을 담고 있으며, 웹 표준의 궁극적인 목적은 웹 사이트에 접속한 사용자가 어떠한 운영체제나 브라우저를 사용하더라도 동일한 결과를 보이게 하는 것이다. 만약 각 브라우저에 맞게 사이트를 다시 만들어야 한다면 엄청난 시간과 비용이 낭비될 것이다.

웹 표준의 중요성

웹 표준을 준수하는 것은 웹 개발자와 디자이너, 사용자, 검색 엔진 등 다양한 이해관계에서 많은 이점을 제공한다.

1. 다양한 브라우저와 기기 호환성 : 웹 표준을 준수하면 웹 페이지가 다양한 웹 브라우저와 기기에서 일관된 형태로 제공될 수 있다.
2. 사용자 경험 향상 : 웹 표준을 준수하면 레이아웃, 디자인, 기능 등이 일관되어 사용자들에게 일관된 경험을 제공할 수 있어 사용자들이 콘텐츠에 더 쉽게 접근하고 상호작용하기가 쉬워진다.
3. 웹 접근성 향상 : 장애인과 고령자들도 웹에서 게시물들을 확인할 수 있도록 alt 속성 부분에 이미지의 설명을 넣음으로써 해당 메뉴를 읽어들일 수 있는 등 여러 사용자들에게 접근 가능한 형태로 제공될 수 있다.
4. 검색 엔진 최적화 (SEO) : 검색 엔진이 웹 페이지의 콘텐츠를 더 잘 이해하고 색인할 수 있어 검색 결과에서 더 높은 우선순위로 노출될 수 있다.
5. 유지보수 용이성 : 웹 표준을 준수하면 올바른 마크업 태그 사용으로 적절한 콘텐츠를 표현할 수 있고, 코드의 구조가 더 명확하고 읽기 쉬워진다. 다른 개발자들과의 협업과 유지보수에도 용이하다.
6. 장기적인 비용 절감 : 웹 표준을 준수하면 다양한 브라우저나 기기에서 디버깅이나 수정이 필요한 경우가 줄어들어 개발 및 유지보수 비용을 절감할 수 있다. 또한 검색 효율성을 증대시켜 홍보를 위한 비용을 들이지 않고도 검색의 효율성을 높일 수 있다.

마치며

왜 웹 표준과 웹 접근성이 붙어서 언급되는 건지 알 것 같다. 크로스브라우징도! 셋은 뗄레야 뗄 수가 없다. 웹 표준을 준수하지 않으면서 웹 접근성과 크로스브라우징의 개념에 접근할 수 없는 것이다. 마치 시침 가는 데 분침이 가는 것처럼 한 가지만 준수할 수는 없는 것이다.

그리고 세가지 개념 모두 다 비슷한 내용들이 계속 언급된다. 그만큼 서로 비슷하기 때문에 또 많은 사람들이 이 개념들을 헷갈려하고 혼동하는 건 아닐까 싶다. 물론 나도 그랬고.

아무튼 이번 기회에 셋의 개념을 확실히 짚고 갈 수 있어서 나 스스로에게도 유익한 시간이 되었다고 생각한다.

크로스브라우징(Cross Browsing)이 뭘까?

크로스 브라우징(Cross Browsing)은 웹 개발에서 중요한 개념으로, 다양한 웹 브라우저와 디바이스에서 웹 사이트나 웹 애플리케이션이 동일한 사용자 경험을 제공하는 것을 목표로 한다.

다른 웹 브라우저(ex:Chrome, Firefox, Safari, Edge 등)나 다양한 디바이스(데스크톱, 태블릿, 스마트폰 등)에서 웹 페이지가 일관된 모습과 동작을 보이도록 만드는 작업을 포함한다. 즉, 크로스 브라우징은 웹 페이지의 상호 호환성을 의미한다.

크로스 브라우징을 신경쓰지 않으면, 웹 페이지가 한 브라우저나 디바이스에서는 잘 작동하더라도 다른 브라우저나 디바이스에서는 레이아웃이 깨지거나 기능이 동작하지 않을 수 있다.

실제로, 가입되어 있는 여러 스터디 모임에서 크롬에서는 잘 되는데 사파리에서는 레이아웃이 뒤틀린다고 어떻게 하면 되냐는 질문글을 많이 보기도 했다. 이게 다 크로스 브라우징을 신경쓰지 않아서 생긴 문제라는 것을 지금은 나도 안다.

그럼 어떤 노력을 해야 할까?

1. 웹 표준 준수 : 웹 표준에 따라 코드를 작성하여 각 브라우저에서 일관된 동작을 유지한다.
2. 프리픽스 사용 : 벤더 프리픽스를 추가하여 브라우저별 호환성을 확보한다.
3. 미디어 쿼리 활용 : 미디어 쿼리를 사용해 다양한 화면 크기에 대응하는 반응형 디자인을 구현해 적절한 레이아웃을 제공한다.
4. 테스트와 디버깅 : 다양한 브라우저와 디바이스에서 테스트하며 크로스 브라우징 이슈를 해결할 수 있다. BrowserStack에서 다양한 브라우저와 디바이스에서의 웹 페이지를 테스트할 수 있다.
5. 유연한 레이아웃 : 고정된 픽셀값 대신 백분율로 레이아웃을 설정하여 화면 크기가 변경될 때 요소들이 자동으로 크기를 조정하게 해, 디바이스의 가로 너비에 따라 요소들이 유연하게 배치된다. 또한 flex와 grid를 활용하면 유연한 레이아웃을 구현하는 데 도움이 된다.
6. 웹 접근성 고려 : 웹 접근성 가이드라인을 따르면 모든 사용자가 웹 사이트에 접근하기 용이하다.
7. 폴리필 사용 : 폴리필은 브라우저에서 지원하지 않는 기능을 JavaScript로 구현하여 채워주는 방법이다. 이 방법으로 오래된 브라우저에서도 적절한 사용자 경험을 제공할 수 있다. Modernizr 프로젝트에서 제공하는 HTML5 관련 폴리필 정보를 참고할 수 있다.

참고할만 한 링크

1. Can I Use : 웹 기술의 브라우저 호환성 정보를 제공하는 사이트
2. MDN Web Docs : 웹 기술에 대한 최신 정보와 가이드를 제공하는 Mozilla 개발자 네트워크 문서
3. Google Web Fundamentals : Google에서 제공하는 웹 개발 가이드와 리소스

마치며

크로스브라우징은 웹 개발을 하면서 정말 필수적인 요소일 수밖에 없겠구나라는 걸 느꼈다. 그리고 IE 기술지원 종료가 발표됐을 때 왜 많은 개발자들이 그렇게 환호했는지도 좀 알 것 같다.

난 아직 반응형 웹을 따라서 만들어보는 것 말고는 제대로 신경써서 만들어본 적이 없어서 정확히 어떤 점이 불편하게 하는지는 아직 모르겠지만, IE의 종말에 이어 safari의 종말도 기다리는 사람들이 있는 걸 보니 얼마나 어마무시한 녀석인지 두렵기도 하다.

아무튼 역시 계속 테스트해보고 디버깅해보는 게 중요하겠구나 하는 생각이 든다.

PostCSS란?

공식 문서에서 "PostCSS는 JavaScript 기반 플러그인을 사용하는 소프트웨어 개발 도구로, CSS를 린트하고, 변수 및 믹스인을 지원하고, 향후 CSS 구문, 인라인 이미지 등을 변환할 수 있다."고 설명하고 있다. 그렇지만 SASS나 LESS같은 CSS 전처리기나 프레임워크와는 조금 다른 개념이다.

PostCSS는 Wikipedia, Twitter, Alibaba 및 Facebook, Github의 코드를 개발하기 위해 사용되었다. 그리고 npm 사용자들 간에 가장 선호되는 CSS 도구이기도 하다.

특징 및 개념

1. 플러그인 기반 아키텍처 : PostCSS는 플러그인을 사용하여 CSS 변환작업을 수행하는데, 각 플러그인은 특정한 기능을 하거나 CSS를 수정하는 데 사용될 수 있다. 이러한 플러그인을 조합하여 원하는 변환 과정을 정의할 수 있다.

   PostCSS에서 플러그인을 어떻게 활용하는지 몇 가지 예시를 가져왔다.

   • Autoprefixer : Autoprefixer는 PostCSS의 가장 유명한 플러그인 중 하나로, 벤더 접두사(Vendor Prefix. '-webkit-', '-moz-', '-ms-', '-o-')를 자동으로 추가해주는 역할을 한다. 다양한 브라우저에 호환되는 CSS를 작성하고 Autoprefixer를 사용하면, 해당 브라우저의 벤더 접두사를 자동으로 추가해 일관된 스타일을 유지할 수 있다.

   • CSS Next : CSS Next는 미래의 CSS문법을 사용할 수 있게 해주는 PostCSS 플러그인이다. CSS 변수나 그리드 레이아웃 같은 최신 CSS 기능을 사용하려면 브라우저의 지원을 기다리지 않고도 CSS Next 플러그인을 사용하여 미래의 문법을 현재 지원하는 문법으로 변환할 수 있다.

   • PostCSS Import : 이 플러그인은 CSS 파일 내에서 '@import' 구문을 사용하여 다른 CSS 파일을 포함할 수 있도록 해준다. 이를 통해 CSS 파일을 모듈화하고 관리할 수 있다.

     3가지 예시만 가져왔지만 더 다양하고 유용한 플러그인들이 많다. PostCSS Github Repository에서 확인할 수 있다.

2. 확장성 : PostCSS 플러그인은 독립적으로 개발되며, 필요한 플러그인을 선택하여 프로젝트에 추가할 수 있어 개발자들이 프로젝트의 요구 사항에 맞게 사용자 정의된 CSS 처리를 쉽게 구현할 수 있게 해준다.

3. CSS 변환 및 최적화 : 여러가지 플러그인을 사용하여 CSS를 변환하고 최적화하는 데 유용하다. 위에서 설명한 Autoprefixer를 사용해 벤더 접두사를 자동으로 추가하거나, CSS Minification이라는 플러그인을 사용하여 CSS 파일 크기를 줄일 수 있다.

4. CSS Next 및 미래의 CSS 문법 지원 : 가져온 3가지 예시에서도 한 번 언급했던 CSS Next를 통해 사용해 아직 표준으로 승인되지 않은 CSS 문법을 사용할 수 있으며, PostCSS가 해당 문법을 현재 브라우저에 지원하는 문법으로 변환해준다.

5. 유연한 사용 : PostCSS는 빌드 도구 (ex:Webpack, Gulp)와 통합하여 사용할 수 있다. 이를 통해 개발자들은 프로젝트의 빌드 과정에 PostCSS를 통합하여 자동으로 CSS 변환 및 최적화 작업을 수행할 수 있다.

PostCSS를 사용하면 좋은 점?

1. 유연성과 확장성 : PostCSS는 플러그인 기반 아키텍처를 사용하기 때문에 원하는 변환 작업을 쉽게 구성하고 조합할 수 있어 자유롭게 확장성을 갖춘 CSS 처리를 할 수 있다.
2. 미래 CSS 문법 지원 : 미래의 문법을 지원하는 플러그인을 통해 브라우저의 지원을 기다리지 않아도 되는 장점이 있다.
3. 코드 최적화 : 여러 최적화 플러그인을 제공하여 CSS 파일 크기를 줄이고, 자동으로 벤더 접두사를 추가하거나, 중복된 스타일을 제거하는 등의 작업을 수행해 성능을 향상시킬 수 있다.
4. 브라우저 호환성 관리 : Autoprefixer와 같은 플러그인을 사용하여 벤더 접두사를 자동으로 추가해주어 다양한 브라우저에서 일관된 스타일링을 유지할 수 있다.
5. 다양한 플러그인 생태계 : 다양한 플러그인이 개발되어 있어 CSS 전처리, 후처리, 변환 작업을 수행하는 등 원하는 기능을 쉽게 추가할 수 있다.

PostCSS의 단점?

1. 높은 진입 장벽 : PostCSS는 초기 설정 및 플러그인 관리 등이 필요한데, 특히 전처리기와 비교했을 때 초기 설정이나 기본 기능의 부재로 처음에는 복잡하다고 생각할 수 있다.
2. 초기 설정 및 플러그인 관리 : PostCSS를 사용하려면 프로젝트에 필요한 플러그인을 개별적으로 설치하고 설정해야 한다. 이로 인해 초기 설정 및 플러그인 관리가 번거로운 단점이 있다.
3. 플러그인의 퀄리티 차이 : 플러그인은 다양한 개발자가 만들기 때문에 플러그인의 품질과 업데이트 주기에 차이가 있을 수 있다. 때문에 업데이트가 되지 않거나 호환성 문제가 발생할 수도 있다.
4. 생태계의 다양성 : 생태계가 다양한 건 장점이기도 하고 단점이기도 하다. 많아서 원하는 기능을 쉽게 추가할 수도 있겠지만, 너무 많아서 어떤 플러그인을 사용해야 하는지 선택이 어렵고 시간이 오래 걸릴 수 있다.
5. 프레임워크의 부재 : PostCSS는 프레임워크와 직접 통합되지 않기 때문에 사용자가 개발 환경을 설정해야 한다. 이는 프레임워크가 이미 PostCSS를 기본으로 포함하는 경우보다 추가 설정이 필요할 수 있음을 의미한다.

참고할만 한 링크

1. PostCSS 플러그인 목록
2. 플러그인 예제 : Autoprefixer, CSSnano
3. 튜토리얼 및 가이드
   • 처음 시작하는 데 도움이 되는 튜토리얼
   • PostCSS에 대한 기본 개념 소개하는 글
4. PostCSS와 함께 사용되는 빌드 도구 관련 문서
   • Using PostCSS width Webpack : Webpack과 함께 PostCSS를 사용하는 방법에 대한 가이드
   • Gulp와 함께 사용하는 PostCSS : Gulp와 함께 PostCSS를 사용하는 방법을 설명하는 글

마치며

PostCSS의 특징과 장,단점에 대해 정리를 했는데 내가 생각할 때는 그래도 단점보다는 장점이 더 큰 도구인 것 같다는 생각이 든다. 특히 Autoprefixer를 사용해 브라우저의 호환성 관리를 하는 부분과 CSS Next를 통해 브라우저의 지원을 기다리지도 않아도 된다는 점이 매력적으로 느껴졌다.

그리고 정리하면서 옛날에 벤더프리픽스(Vendor Prefix)에 대해서도 잠깐 설명을 들었던 게 기억이 나서 이건 뭐지? 하면서 찾아봤다. 벤더프리픽스는 접두사를 추가하는 것을 의미하는 거였다. '-webkit-', '-moz-', '-ms-', '-o-' 같은 접두사가 벤더프리픽스다.

이렇게 글을 정리하다보니 내가 놓치고 있는 것들이 정말 많구나 하는 사실을 깨닫게 되었다. 더 열심히 하나씩 정리를 해서 이런 개념들을 확실히 짚고 넘어가야겠다.

웹에 대해서 공부하면서 웹 접근성이란 말을 정말 많이 들었다. 대충은 아는데 정확하게 설명해보라고 하면 "어.. 장애가 있는 분들이나.. 그런 거 상관없이 모든 사람이.. 어려움 없이 웹을 사용할 수 있도록 하는 거..?" 뭐 대충 요정도로만 대답할 수 있는 상태였다.

그러다 좀 자세히 알고 싶기도 하고 잘 알고 넘어가면 좋겠다 싶어서 블로그에 정리를 하려고 한다.

웹 접근성(Web Accessibility)이란 장애인, 고령자 등이 웹 사이트에서 제공하는 정보에 비장애인과 동등하게 접근하고 이해할 수 있도록 보장하는 것이다.

웹상에서 제공되는 텍스트와 이미지, 영상 등을 대신할 수 있는 설명을 텍스트로 제공하거나 음성정보를 문자로 대신하여 제공해야 한다. 또한 마우스를 사용할 수 없는 사용자를 위하여 키보드만으로도 모든 콘텐츠에 접근하여 이용할 수 있도록 해야 하며, 움직임이 느린 사용자를 위해 시간조절 기능을 제공해야 한다.

몇 가지 예시를 들어보자면,

인식의 용이성

1. 이미지 대체 텍스트 제공 : 대체 텍스트를 제공하여 내용을 이해할 수 있게 해야 한다. ex) "홈 버튼" 이미지에 대체 텍스트로 "홈으로 이동"을 제공. 하지만 꾸밈용으로 제공된 이미지의 경우에는 alt 속성을 빈 값으로 제공하여 불필요한 정보를 주지 않도록 해야 한다.
2. 멀티미디어 대체 수단 제공 : 멀티미디어 콘텐츠에는 자막, 원고 또는 수화 중 하나 이상을 제공해야 한다.
3. 명료성 : 콘텐츠는 색상만으로 내용을 구분하거나 인식하도록 제공된 콘텐츠(그래프, 차트, 지도 ,필수 입력항목 등)를 제공하지 않도록 해야 한다. 지시사항은 모양, 크기, 위치, 방향, 색, 소리 등에 관계없이 인식될 수 있어야 한다.
4. 텍스트 컨트라스트 유지 : 텍스트와 배경 간의 명도 대비는 4.5:1 (18pt 미만, 또는 굵은 14pt 미만의 일반 텍스트의 경우에 4.5:1, 18pt 이상 또는 굵은 14pt 이상의 텍스트의 경우 3:1) 이상이어야 한다. 명확한 대비를 유지하여 시력이 낮은 사람들이 텍스트를 더 쉽게 읽을 수 있게 해야 한다. 하지만 단순히 장식 목적으로만 사용한 텍스트, 로고 또는 상호와 같은 텍스트 이미지, 사용할 수 없음을 표시하기 위하여 명도 대비를 낮춘 회색의 컨트롤이나 입력 서식, 마우스나 키보드를 활용하여 초점을 받았을 때 색이나 명도 대비가 변하는 콘텐츠의 경우에는 예외사항으로 적용될 수 있다.
5. 자동 재생 금지 : 자동으로 소리가 재생되지 않는 콘텐츠를 사용해야 한다.
6. 콘텐츠 간의 구분 : 이웃한 콘텐츠는 테두리 또는 시각적인 구분선등 콘텐츠를 구분할 수 있도록 해야 한다.

운용의 용이성

1. 입력장치 접근성 : 모든 기능은 키보드만으로도 사용할 수 있어야 한며, 터치 기반 모바일 기기의 모든 컨트롤은 누르기 동작으로 제어할 수 있어야 한다. 또한 키보드에 의한 초점은 논리적인 순서로 이동해야 하며 시각적으로 구별할 수 있어야 한다.
2. 충분한 시간 제공 : 페이지 이동 시 시간 제한이 있는 콘텐츠는 응답시간을 조절할 수 있는 수단을 제공해야 한다.
3. ** 광과민성 발작 예방 ** : 사전 경고 없이 초당 3~50회 주기로 깜빡이거나 번쩍이는 콘텐츠를 제공하지 않아야 한다. 깜빡임이 심한 콘텐츠가 존재할 경우에는 정지할 수 있는 기능을 제공해야 한다.
4. 쉬운 내비게이션 : 콘텐츠의 반복되는 영역은 건너뛰기 링크를 제공하여 건너뛰기가 가능하도록 해야 한다. 또한 페이지, 프레임, 콘텐츠 블록에는 적절한 제목을 제공하고, 링크에는 용도와 목적을 이해할 수 있도록 링크 텍스트를 제공해야 한다.

이해의 용이성

1. 가독성 : 문서 타입에 맞는 기본언어를 명시해야 한다.
2. 예측 가능성 : 사용자가 의도하지 않은 기능 (새 창, 초점 변화 등)은 실행되지 않아야 한다. 입력 서식의 값을 변경하는 것만으로 다음 페이지로 이동하거나 현재 페이지가 새로고침 되는 경우를 피해야 한다.
3. 콘텐츠의 논리성 : 콘텐츠의 순서를 논리적으로 제공하여 전후 맥락을 이해할 수 있도록 해야 한다. 콘텐츠에 표를 추가할 경우 이해하기 쉽게 구성해야 한다. 표의 제목과 요약정보를 적절하게 제공하고, 제목 셀과 내용 셀을 구분해야 한다. 또한 복잡한 표를 제공시 headers, id 속성을 통해 제목 셀과 내용 셀을 연결해주어야 하며, 표의 정보를 이해하기 어려운 중첩표는 피하는 것이 좋다.
4. 입력 도움 : 입력 서식에는 대응하는 레이블을 제공해야 한다. 무슨 말이냐면, input, textarea, select 요소에 1:1 대응하는 label 요소 또는 title 속성을 제공해야 한다는 말이다. 그리고 입력 오류 발생 시에는 입력 오류를 정정할 수 있는 수단을 제공해야 한다.

견고성

1. 문법준수 : 마크업 언어의 요소는 열고 닫음, 중첩 관계 및 속성 선언에 오류가 없어야 한다. ex) ```
2. 태그의 열고 닫음 오류 // 잘못된 사례

   

   abcdefg

// 올바른 사례

abcdefg

2. 태그의 중첩 오류 // 잘못된 사례

// 올바른 사례

3. 중복 선언된 속성 오류 // 잘못된 사례
   ...

// 올바른 사례

2. 웹 애플리케이션 접근성 : 콘텐츠에 포함된 웹 애플리케이션은 접근성이 있어야 한다. 웹 애플리케이션이 자체적인 접근성이 없고 사용자가 선택할 수 있는 대체 콘텐츠가 존재하지 않거나 적절하지 않게 제공한 경우 웹 접근성에 저해된다.

이렇게 다양한 예시들이 있다. 이러한 웹 접근성 표준지침을 준수한 우수 사이트에 대해 웹 접근성 수준을 인정하고 이를 상징하는 품질 마크를 부여하는 인증제도가 있다.

마치며

웹 접근성 지침에 대해 읽어보고 나름대로 정리를 해보았는데 정말 지켜야할 것들도 많고 신경써야 할 부분도 많다고 생각했다. 웹 접근성을 향상하기 위한 국가적인 노력이 계속되고 있지만 국내 대부분 사이트의 웹 접근성 수준은 매우 낮은 수준이라고 한다. 심지어 공공기관에서 조차도 웹 접근성이 선진국들에 비해 낮아 공공기관이 제공하는 중요 정보도 접근이 어려운 실태라고 홈페이지에서 설명하고 있다.

왜 그런걸까? 생각해봤는데 우선 우리나라는 약자에 대한 인식이 낮다고 생각하는 편인데 이런 게 한 몫하지 않을까 싶기도 하다. 그리고 인증 유효기간이 1년이어서 매년마다 갱신이 필요한데 이런 부분에서도 다 지키고 실행하기가 까다롭다고 생각하는 것도 있을 것 같다.

아무튼, 사지멀쩡하고 컴퓨터를 많이 사용하는 내가 사용할 때도 가끔 "와, 이거 이렇게 불편해서 어떡해?" 싶을 정도로 불편함을 주는 홈페이지들이 있었는데, 웹 접근성에 대해 글도 읽고 이미지 예시들을 보면서 마크업을 할 때 이런 부분들을 좀 신경써서 해야겠구나 생각하는 계기가 되었다.

그 중 더 좋은 CSS를 작성하기 위한 팁이라는 제목으로 작성된 글을 나중에 다시 보더라도 이해하기 쉽도록 정리하고자 한다.

1. 선택자 사용의 명확성

DRY원칙 (Don't Repeat Yourself)

말 그대로 반복을 피할 수 있으면 피하라는 말이다. 공통적으로 묶을 수 있는 부분이 있다면 공통 규칙을 작성하고, 추가적으로 필요한 규칙이 있다면 다른 클래스를 추가해 작성하는 것이 좋다.

직관적인 네이밍 사용하기

CSS 선택자의 이름을 직관적으로 작성하면 네이밍만 보고도 어떤 섹션의 코드인지, 무엇인지 이해가 빠르고 쉽다.

.p { 
    font-size: 20px;
}

.myButton { 
    width: 20px;
    height: 20px;
    border-radius: 6px;
} //camelCase

이렇게 작성하는 경우도 있지만 좋지 않은 코드로 보고 있다. 우선 P라는 선택자가 무엇을 가르키는 것인지 명확하지 않을 뿐더러 HTML에서 단락을 나타내는 태그이기 때문이다.

.myButton 같은 경우는 이렇게 작성하는 것을 카멜케이스라고 하는데 권장하지 않는 네이밍규칙이라고 설명하고 있다. 가독성이 떨어지고 대부분 HTML 요소의 속성들은 소문자와 하이픈(-)을 사용하여 네이밍을 하는데, 카멜케이스를 사용하면 HTML과의 일관성이 떨어져 유지보수에 용이하지 않은 이유로 권장하지 않고 있다.

2. CSS 파일 분리

인라인 스타일 (inline-style) 사용하지 않기

인라인 스타일(inline-style)은 HTML 요소 내에 직접 style 정보를 포함하여 작성하는 것을 말한다. 예를 들면,

<div style="font-size: 16px; color: red;">aaa</div>

이런 식으로 작성하는 것이다.

이런 방식으로 작성하는 것을 권장하지 않는 이유에는 여러가지가 있다.

첫 번째 이유는 유지보수가 어렵고 재사용이 힘들다는 점이다. 무슨 말이냐면, HTML 요소 내에 직접 스타일 정보를 포함하기 때문에 여러 요소에 동일한 스타일을 적용하려는 경우, 각 요소를 개별적으로 수정해야 하는 번거로움이 발생한다. 그리고 인라인 스타일은 한 요소에만 적용되기 때문에 다른 요소에도 적용을 시키려면 중복된 스타일을 계속해서 작성해줘야 하므로 재사용성 부분에서 기능이 떨어진다.

두 번째 이유로는 우선순위의 복잡함이 있다. 브라우저는 여러 스타일 규칙이 동일한 요소에 적용되는 경우, 우선순위를 판단하여 최종 스타일을 결정하는데 인라인 스타일은 !important를 제외하고 CSS의 다른 선택자보다 우선 순위가 높다. 그렇기 때문에 스타일의 충돌이 발생할 수 있고, 이 문제를 해결하기 위해 !important를 사용해야만 하는 문제가 발생할 수도 있다. (!important를 사용할 수밖에 없는 일도 있긴 하겠지만 웬만하면 !important 사용을 지양하는 것이 좋다.)

세 번째 이유는 가독성이 떨어진다는 점이다. 인라인 스타일이 어쨌든 간단한 스타일링을 할 때는 편리할 수는 있지만 HTML 코드 내에 섞여있기 때문에 코드가 길어지거나, 스타일 정보와 내용이 혼재되면 코드의 가독성이 떨어지고 코드를 이해하기 어려운 문제가 발생할 수 있다.

이러한 문제들을 해결하기 위한 방법으로 스타일 정보를 외부 CSS 파일로 분리하여 사용하는 방법이 있다.

!important 사용 지양하기

특정 요소에 긴급한 스타일 수정이 필요한 경우나, 스타일을 임시로 변경하고 테스트하는 경우에는 사용하면 간편하게 해결할 수 있는 장점이 있지만 왜 지양해야 하는지에 대해 나열해보려고 한다.

인라인 스타일에 대해 설명하면서 한 번 언급했지만, !important는 가장 높은 우선순위를 가진다. 때문에, !important를 남용하면 코드의 가독성과 유지보수가 어려워진다. !important를 사용한 스타일을 추적하기가 어려울 수 있기 때문이다. 그리고 스타일의 충돌이 발생할 수 있고, 스타일의 우선순위가 더 복잡해질 수 있다.

최대한 !important 사용을 피하고, 구체적인 선택자를 사용하여 스타일 충돌을 최소화하는 것이 가장 좋은 방법이다.

CSS 전처리기 활용하기

Sass나 Less 같은 CSS 전처리기는 일반적인 CSS 문법에 변수와 Nesting 규칙, mixin, 함수, 조건문과 반복문 등 추가적인 기능을 제공해주어 중복을 줄이고, 구조화된 스타일 규칙을 작성할 수 있어 가독성을 높여준다. 또한 스타일 시트를 여러 파일로 분할하고 모듈화하여 관리할 수 있어 더 효율적으로 작성하고 관리할 수 있도록 도와준다.

물론 전처리기를 사용하기 위해 추가 기능 및 문법을 익히는 데에 시간을 투자해야 한다는 단점이 있지만 전처리기를 활용하여 작업을 해본 결과 작업적인 부분에서도, 파일 관리 부분에서도 편리한 점이 훨씬 많았다.

3. 약어 사용

약식 속성은 여러 다른 CSS 속성을 축약하여 설정할 수 있는 방법으로, 코드 작성을 간결하게 만들고 코드의 가독성을 향상시킬 수 있으며 스타일을 빠르게 지정할 수 있게 해준다.

또한, 약식 속성은 특정한 스타일 속성들의 조합에 대해 미리 정의된 규칙에 따라 작동이 되는데 아래의 예시로 비교해볼 수 있다.

아래의 CSS는 약식 속성을 사용하지 않은 경우다.

.article-container {
    padding-top: 10px;
    padding-bottom: 20px;
    padding-left: 15px;
    padding-right: 15px;
    margin-top: 10px;
    margin-bottom: 10px;
    margin-left: 15px;
    margin-right: 15px;
    border-width: 1px;
    border-style: solid;
    border-color: black;
}

약식 속성을 사용한 CSS는 아래와 같다.

.article-container {
    padding : 10px 15px 20px 15px; // top, right, bottom, left;
    margin: 10px 15px; //top & bottom, left & right;
    border: 1px solid black; // width, style, color
}

이렇게 약식속성을 사용하면 코드가 간결해지고 편리한 점도 있지만, 사용상 주의할 점도 있다.

약식 속성을 사용하면 값이 지정되지 않은 부분에 기본 값이 적용되는 경우가 있을 수 있고, 기존에 설정한 스타일을 덮어쓰는 경우가 발생할 수도 있다. 예를 들면,

.article-container {
    font-weight: normal;
    font : italic bold 16px/1.5 Arial, sans-serif;
}

이렇게 작성했을 때 font-weight가 개별적으로 설정한 normal이 아니라 약식속성으로 설정된 bold로 덮어써진다는 말이다. 약식속성을 사용할 때에는 이런 점을 유의하여야 한다.

4. 명확한 주석 작성

명확한 의도와 설명을 가지고 작성된 주석은 유지보수 및 협업에 큰 도움을 줄 수 있다.

물론 지나치게 많은 주석은 가독성을 떨어트리고 코드를 복잡하게 만들고, 부적절하게 사용된 주석은 오히려 혼란을 야기할 수 있으니 적절하게 사용하는 것이 좋다.

제일 좋은 것은 주석 없이도 코드 자체만으로 명확하게 설명이 될 수 있게 작성하는 것이다.

그러나 주석을 작성해야 할 때에는 필요한 정보를 제공하고 의도와 기능을 명확하게 설명할 수 있도록 작성해야 한다.

* 작성하면서 느낀점

작성하다 보니 이걸 읽고 시작했는데도 직접 작업을 할 때 왜 이런 부분들을 고려하지 않았을까 싶은 부분들이 있었다. 특히 약어사용이 그랬다. padding이나 margin, border는 손에 익어서 그렇게 작성하는데, font 규칙을 작성할 때는 font-style, font-weight, font-size, line-height, font-family를 따로 적는 게 익숙하다 보니 생각을 아예 못 했던 것 같다.

다음에 작업할 때에는 이런 부분들도 좀더 생각해보고 작업을 해야겠다는 생각을 했다.