웹 애플리케이션 개발에서 UI 작업은 생각보다 까다로운 작업이다.
분명 난이도는 높지 않은데 작업 공수가 많이 들어가다 보니 여기에 투자되는 시간이 비효율적인 편이다.
또한 UI 개발은 결과물을 빨리 낼수록 검증하는 시간을 줄일 수 있고 더 나은 제품을 만드는 결과로 이어진다.
이러한 이유로 여러 가지 CSS 방법론과 프레임워크 등이 생겨났고 그 CSS 패러다임 중 하나인 Atomic CSS라는게 있어서 기록한다.
1. CSS의 역사
HTML의 탄생, 1990
최초 웹은 문서를 공유하기 위해 만들어졌고 이 문서를 표현하기 위해 HTML이 만들어졌다.
HTML은 콘텐츠에 의미를 부여하는 태그를 붙여주어 서식을 꾸미는 방식으로 만들어졌다.
<h1>제목</h1>
<p>내용</p>inline-style
우베 문서가 보편화되면서 조금 더 다른 형태의 서식으로 꾸미기를 원했고 이를 위해서 style이라는 것이 추가 되었다.
이렇게 태그에 직접 style을 지정하는 방식을 inline-style이라고 한다.
inline-style의 문제점
inline-style은 중복 서식을 표현할 때 코드가 너무 비대해지면서 가독성도 떨어지고 유지 보수가 어렵다.
출처: https://stackoverflow.com/
CSS의 탄생. 1996
inline-style의 중복을 제거하는 방법에 대한 고민 끝에 나온 CSS.
CSS는 위의 이미지와 같이 중복해서 사용해야만 했던 inline-style을 별도로 선언하고 서식이 필요한 곳을 선택해서 반복 적용하는 방식이다.
<style>
strong {
color: red;
text-decoration: underline
}
</style>
<strong>This is Red Underline Title</strong>
<strong>Other Red Unerline</strong>
<strong>Underline Title 333<strong>컨텐츠와 서식 분리
CSS를 별도로 작성을 하게 되면서 자연스럽게 콘텐츠와 서식이 분리되었다.
이렇게 콘텐츠와 스타일을 분리하고 보니 콘텐츠와 서식을 꼭 1:1로 매칭을 하지 않고 하나의 콘텐츠에 여러가지 스타일을 선택적으로 적용할 수 있게 되었다.
/* style1.css */
<style>
strong {
color: red;
text-decoration: underline
}
</style>/* style2.css */
<style>
strong {
color: blue;
font-weight:bold
}
</style>이러한 장점으로 콘텐츠는 유지하고 디자인만 변경하는 테마형 솔루션의 형태로 발전 하게 되었다.
그러면서 유연하게 디자인을 적용할 수 있도록 HTLM을 잘 구조화 해서 작성 하고 HTML의 변화 없이 CSS 만으로 여러가지 스타일을 만드는 것이
중요해졌다.
Selector가 복잡해지며 나타난 Sass
이러한 배경으로 HTML을 수정하지 않고 CSS 만으로 디자인을 적용하다 보니 엘리먼트 하나하나 선택해서 스타일 적용하는 것은 쉬운일이 아니게 되었다. 원하는 요소를 찾고 수정하기 위해서는 복잡한 Selector를 써야했고 Selector 역시 세분화가 필요해졌다.
이런 이유로 Selector를 조금 더 쉽게 만들 수 있는 언어인 Sass와 같은 것들이 등장하였다.
/* css */
.container-03 {
width: 100%;
height: 100vh;
background: #72b565;
position: relative;
}
.container-03 .wrapper {
position: absolute;
left: 50%;
top: 50%;
transform: translate(-50%, -50%);
width: 235px;
height: 70px;
white-space: nowrap;
}Selector를 조금 더 쉽게
/* sass */
.container-03 {
width: 100%;
height: 100vh;
background: #72b565;
position: relative;
.wrapper {
position: absolute;
left: 50%;
top: 50%;
transform: translate(-50%, -50%);
width: 235px;
height: 70px;
white-space: nowrap;
}
}Ajax의 등장과 HTML 편집권의 변화
Ajax가 보편화 되면서 백엔드에서 HTML을 제외한 데이터만 전달할 수 있게 되면서 이제 HTML의 편집권은 프론트엔드로 내려오게 된다.
그렇게 HTML과 CSS를 동시에 편집을 할 수 있게 되면서 이제는 복잡하게 Selector를 쓸 필요가 없어졌다.
이제는 필요할 때 HTML을 수정할 수 있으니 CSS를 복잡하게 짜는 것보다 HTML에 신경 쓰는 편이 더 나아지게 된다.
그래서 이후에는 Selector를 어떻게 잘 쓰는지 보다 어떻게 class name을 더 잘 지을 수 있는지를 고민하는 식으로 흐름이 변하게 된다.
의미 있는 이름? 시각적인 이름?
복잡한 Selector 보다는 단순한 Class Selector를 사용하는 것이 보편화되면서 어떤 식으로 이름을 지을지 고민하기 시작했다.
class 이름을 짓는 방식에는 2가지.
- 의미 기반 => ex) .error, .title
- 시각 기반 => ex) .blue .bold
스타일 변경 시 CSS를 수정한다는 원칙에 의거하여 변경된 디자인에 맞게 CSS를 변경하다 보니 시각적인 이름으로 짓게 되는 경우
.blue{color: green}이런 이상한 형태가 만들어지게 된다.
그래서 유지 보수와 유연한 대응을 위해서는 class 이름을 의미 기반으로 짓는 게 더 유리하다는 것을 알게 된다.
시각적인 이름보다 시멘틱한 이름이 좋다.
그래야 변경에 유연하고 같은 콘텐츠에 다양한 스타일을 적용할 수 있게 된다.
웹 애플리케이션으로의 변화
웹이 발전을 하면서 웹은 더 이상 문서나 홈페이지 형태만 있는게 아니게 되었다.
구글 지도나 구글 오피스와 같은 웹 애플리케이션을 만들게 되고 CMS와 같은 데이터를 다루는 백오피스 등의 웹페이지의 요구사항이 커지면서 웹은 조금씩 애플리케이션의 형태로 발전을 하게 된다.
웹 페이지에 비해 비중은 낮지만 훨씬 더 고부가가치를 만들어 내기에 많은 개발자들에게는 웹 애플리케이션을 만드는 것이 더 중요해진다.
그러나 언급했다시피 CSS는 웹 문서를 잘 꾸미기 위해 설계되었다.
애플리케이션에서의 CSS..
이러한 특징을 가진 CSS는 웹 애플리케이션 개발 패러다임에서 과도기를 맞이하게 된다.
CSS는 애플리케이션을 만들기 위해 설계가 된 것이 아닌데 이미 JS는 Component와 Framework 기반의 개발 방식으로 변해가고 있었다.
당시에는 다른 것 보다 결정적인 2가지 설계상의 문제가 존재했다.
- 전역변수
a. 내가 수정한 코드가 모든 프로젝트에 영향을 준다.
b. 그래서 엉뚱한 곳에 문제가 발생하여 관리 비용이 증가한다.
c. 기존에 한 번 사용한 이름을 피해 가면서 작성해야 한다.
- 순서대로 적용되지 않음
a. HTML에서 지정한 class 순서가 아닌 CSS의 순서에 의해 서식 우선 순위가 결정된다.
b. 코드 순서도 있지만 무엇보다 Selector가 복잡할수록 서식이 나중에 적용된다.
c. 다른 서식을 덮어쓰기 위해 Selector를 더 복잡하게 작성해야 한다.
d. 이걸 간단한 Selector로 덮어쓰려면 !important를 적용해야 한다.
e. !important를 한 속성을 덮어쓰려면 복잡한 Selector에 !important 해야 한다.
해결 방법은?, 2013
처음부터 CSS를 작성하는 규칙을 만들어서 진행하면 되지 않을까? 하는 측면에서 여러가지 방법론들이 만들어지기 시작한다.
SMACSS, OOCSS, BEM, ITCSS, ATOMIC CSS, …
승자는 BEM.
하지만 이런 방법론은 CSS의 본질적인 문제를 해결해주지는 못했다.
이러면서 CSS 자체보다는 JS의 도움을 받는 식으로 해결 하고자 하는 움직임이 발생하게 된다.
CSS Modules, 2015
CSS의 문제점이었던 전역 변수를 막기 위해서 Component 단위에서 사용되는 CSS에 hash를 추가해 CSS가 전역으로 퍼지지 않도록 하는 방법이 만들어졌다.
CSS-in-JS
이후 React 진영이 대세가 되면서 React에서 Style을 다루는 불편함을 해소하기 위해 JS에서 HTML을 쓰기 위해 JSX를 만든 것 처럼 JS에서 Style을 쓰기 위한 방법으로 CSS-in-JS라는 방법이 등장한다.
CSS-in-JS의 시작. vjeux, 2014
CSS가 아니라 JS를 통해서 문제를 해결해 보자는 의견이 나오게 되고 이후 CSS-in-JS라는 방법으로 구체화 된다.
CSS-in-JS StyledComponent, 2016
이 방식의 대표 주자가 되는 StyledComponent가 탄생한다.
TailwindCSS, 2017
Best practices는 사실 제대로 동작하지 않는다며 Atomic CSS를 근간으로 하는 새로운 시각의 CSS Framework, TailwindCSS가 등장한다.
하지만 TailwindCSS는 현재까지도 호불호가 많이 갈리고 있다.
왜 그럴까?
먼저 AtomicCSS의 개념 이해가 필요하다
2. Atomic CSS?
- inline-style은 나쁜 것인가?
- 컨텐츠와 서식의 관점 분리가 가능한가?
- 진짜 시멘틱한 이름이 더 좋은 것인가?
컨텐츠와 서식을 분리하지 않는다면 어떻게 작성할까?
기존에 CSS가 만들어지고 초기 자연 발생했던 .bold .hidden .red .mt14 ... 과 같은 class를 만들어서 편하게 사용했던 경험들이 있었다.
이건 시멘틱 하지 못했기 때문에 일종의 편법으로 여겨졌지만 분명 편리했었다.
이 방식이 편리한 방식이라면 일부만 이러한 편법이 아니라 그냥 전부 다 이러한 방식으로 만들어버리면?
이게 Atomic CSS다.
의미 기반이 아닌 시각적 기능에 기반한 이름을 지은 변하지 않는 단일 클래스를 이용한다.
변하지 않는 CSS를 먼저 만들어두고 HTML에서 스타일을 작성한다.
의미 기반이 아닌 미리 만들어둔 시각적인 이름을 바탕으로 HTML에서 필요한 스타일을 적용하는 방식이 Atomic CSS 방법론이다.
지금까지의 원칙과는 정반대인데
왜 이렇게 작성하는 걸까?
의미론적으로 이름 짓기가 아주아주 어렵기 때문이다.
의미가 없는데도 의미를 부여해서 이름을 짓는건 더 어렵다.
하지만 주어진 디자인을 구현하기 위해서 우리는 이름들을 지어야 한다.
의미론적 이름 짓기 방식의 한계
.inner-main .wrap_cont .cp_more_wrap ...
다른 프로젝트에서는 다른 의미를 가진 컨텐츠들일테니 이렇게 만들어진 CSS들은 어떤 서식이라 해도 다른 프로젝트에서 재사용이 불가능하다.
또한 프로젝트 내에서 중복 사용할 수 없기 때문에 새로 이름을 지을 때는 기존 CSS를 피해가야 한다.
그렇지 않으면 결국 Selector를 조립해서 복잡하게 가야하는데 바로 Specificity 문제가 발생한다.
Traditional CSS vs Atomic CSS
Traditional CSS
짓기도 어려운 CSS를 계속 만들고 그 만들어 놓은 CSS를 피해야 하니 점점 복잡해져서 파일 크기만 커지고 재사용도 불가능하기 때문에 매번 계속 작성해야 하는 악순환이 발생한다.
Atomic CSS
시각적 기반의 쉬운 이름을 가지며 미리 만들어 두기 때문에 1번 외워두면 계속 재사용할 수 있어 일정 크기 이상 파일이 커지지 않는다.
무엇보다 class name 짓기 스트레스에서 해방이다
뿐만 아니라 누구나 동일한 형태의 코드 스타일을 작성하게 된다.
1. 협업에서 컨벤션을 맞추기 위한 노력이 줄어든다.
2. 컨벤션과 방법론의 역할을 한다.
하지만 이러한 Atomic CSS는 항상 논란의 대상이다.
주류가 되지 못한 Atomic CSS
왜 TailwindCSS는 AtomicCSS가 아니라 Utility-First라고 이름 지었을까?
Functional CSS는 뭐가 다른 걸까? 왜 같은 방법에 이렇게 이름이 많을까?
사실 Atomic CSS는 TailwindCSS의 시초가 아니다.
앞서 설명했듯 편리함으로 인해서 꾸준히 제기 되었으나 CSS는 언제나 시멘틱한 방법이 옳다는 식으로 발전해왔다.
그래서 처음에는 FunctionalCSS, 그 다음은 Atomic CSS라는 이름으로, 이제는 Utility-First라는 이름으로 기존과 다른 방식이라고 인식 전환을 하고 있으나 번번히 올바르지 않은 방식으로 거론 되었고 소수의 사람들만 사용하는 방식이 되었다.
Atomic CSS를 싫어하는 이유
- HTML에 스타일 코드가 반복되는 것은 어떻게 해결할건지?
- 의미론적 구분이 없으면 전체적인 컨텐츠 파악이 어렵다.
- 컨텐츠와 서식의 분리를 할 수 없는데 다양한 테마 서식 적용은 어떻게 할 건지?
- HTML이 너무 지저분해지고 코드의 가독성을 잃는다는 문제
- HTML 기반의 문서에다가 전부 AtomicCSS를 붙일 건지?
- CSS를 쓰지 않으면 CSS를 더 모르게 된다는 문제
- CSS가 문제가 있는 것은 맞는데 CSS를 잘하면 해결되는 문제가 아닌지?
하지만 이제는?
이제는 CSS가 시멘틱할 필요가 없다.
Component 기반 개발 시대인 지금, Web Framework의 컴포넌트가 시멘틱과 중복 방지 역할을 대신 해주고 있기 때문이다.
지금 시대는 하나의 컨텐츠에 여러 가지 디자인을 할 필요성이 줄어들었다.
디자인이 곧 아이덴티티인 시대이기 떄문에 더 이상 컨텐츠와 서식을 분리할 필요가 없어졌다.
발전하는 AtomicCSS
뿐만 아니라 AtomicCSS는 계속 발전하고 있었다.
FUnctionalCSS -> AtomicCSS -> Utility First -> on-demand AtomicCSS