[CSS] CSS의 흐름

 

해당 포스팅은 맨 요즘 IT의 [역사로 알아보는 CSS가 어려워진 이유]를 기반으로 요약 정리되어 있습니다. 

 

선택자(Selector)와 선언(Declarations) 둘을 합쳐서 CSS Ruleset 이라고 부른다.

strong { color: red; text-decoration: underline }

CSS Rule이 가지고 있는 고유의 명시도(specificity)에 따라서 우선순위가 다르게 적용을 할 수 있도록 설계되어 있다. 

아래는 명시도에 관한 내용이다. 

https://css-tricks.com/a-specificity-battle/

A Specificity Battle! (and other trickery) | CSS-Tricks

Sass의 등장, 2006

Selector를 복잡하지 않게 만들고, CSS에서 반복하는 글자 크기가 색상들의 수정을 힘들게 하는 점을 해결하고, CSS를 확장하여 사용하기 위해 Sass가 만들어진다. Sass는 Nested한 Selector와 variable를 등록할 수 있는 추가적인 문법으로 작성하면 CSS로 변환을 시켜주는 pre-processor이다. 

 

HTML5와 CSS3, 시맨틱이 중요해지다

시맨틱이란 시각적으로 어떻게 보일지가 아니라 의미에 중점을 두는 것

e.g.) Class ="red" 보단 , Class="error" 가 더 시맨틱함

 

jQuery, Ajax의 보편화, 2008

프론트 개발에서 Ajax라는 혁신과 jQuery의 등장으로 백엔드에서 HTML이 아니라 JSON을 만들게 되었다. 이제는 HTML이 백엔드에 있는 게 아니라 HTML과 CSS를 함께 작성하고 데이터를 연동해서 출력하는 작업을 JS로 하는 방식으로 개발하게 된다.

 

웹 어플리케이션과 Framework, 2013

React를 비롯한 Web Framework가 만들어지면서 HTML을 작성하는 주체는 온전히 프론트의 영역이 된다. 그러면서 문서 기반이 아니라 컴포넌트 기반의 개발 방식이 자리를 잡게 된다. 

 

모듈과 컴포넌트 방식으로 개발

CSS의 가장 큰 문제점은 CSS가 Global Scope를 가지고 있다는 점과 Cascade의 Specificity이다. 

모든 문서에 일괄적으로 적용되기 위해서 만들어졌던 기능이 달느 컴포넌트 영역의 스타일을 수정할 수도 있다는 점이 문제가 되었다. CSS는 외부 변화에 의해 너무나 부서지기 쉽다.

 

위의 문제를 해결하기 위해 방법을 모색하게 됩니다.

CSS 방법론과 BEM, 2013

1)여러 명이 함께 작업을 할 때 공통적으로 사용할 수 있는 아키텍쳐

2)Cascade의 Specificity 관리

3)그러기 위한 이름 짓기 컨벤션 -> BEM

 

BEM .Block__Element--Modifier

OOCSS, ITCSS, SMACSS 등 여러 가지 방법론이 존재했지만 현재 방법론의 승자는 BEM이 되었다.

그래서 selector는 class 방식으로만 작성하고 네이밍 규칙은 BEM 방식으로 하는 것이 대세 룰이 되었다.

https://getbem.com/introduction/

BEM — Introduction

.header__nav {}
.header 
/*
구조도 표현하면서 종속 관계가 없다. 
specificity가 하나로 관리된다.
*/

 

Flexbox의 등장, 2013 

웹 문서가 아니라 웹 어플리케이션으로 발전하는 과정에서 레이아웃을 하기 위한 CSS 스펙에 대한 요구사항은 꾸준히 있어왔다. 2008년부터 만들기 시작했던 레이아웃을 하기 위한 스펙은 여러 번의 시행착오 끝에 2013년 정식 스펙으로 등장 

 2022년, Flexbox는 이제 모든 웹 레이아웃의 표준이다. ⭐매 우 중 요

 

IE11(비공식) 업데이트 중단, 2015

사실 IE가 죽어버리면서 윈도우에서 점유율이 높은 브라우저였기 때문에 이후 새로운 CSS의 스펙이 나오더라도 개발자들은 사용을 꺼려했다. CSS에 대한 프론트 개발자들의 관심이 예전보다 더 떨어지게 되는 원인이기도 했다. 

 

이러한 이유로 이후부터는 CSS의 스펙이나 CSS에서 문제를 해결하기 보다는 CSS의 문제점을 JS로 해결하려는 시도들이 생겨나기 시작했다.

 

 

[ CSS -> JS ]

CSS Modules, 2015

CSS의 Global Scope로 인해서 컴포넌트의 CSS 간의 구조와 범위가 일치하지 않는 문제를 JS를 통해서 해결하자는 움직임이 생겼다. 그 중 첫번째 도구인 CSS Modules 는 컴포넌트에서 CSS를 불러와서 컴포넌트에 적용이 될 수 있도록 컴파일해주는 도구였다. 

 

CSS in JS: styled-components, 2016

global scope와 specificity 문제는 CSS 구조상 해결할 수 없는 문제였고 JS를 통해서 CSS를 만들게 되면 새로운 CSS를 만들어낼 수 있지 않을까하는 시도에서 CSS in JS가 탄생하게 된다.

-> specificity문제의 원흉인 selector가 사라지게 되고 property와 value를 컴포넌트 구조에 맞게 작성하면 되게 됐다.

+ 2017 Emotion

TailwindCSS, 2017

JS가 아닌 CSS생태계에서 이를 해결하고자 하는 새로운 패러다임을 얘기하는 CSS프레임워크가 나타났다.

Utility- First라고 불리는 방식의 TailwindCSS 이다.

.mt10 { margin-top: 10px } 은 좋은 클래스인가? 

위처럼 클래스에 유틸리티한 이름을 붙여 개발하는 방식은 시맨틱한 방식이 중요한 패러다임이되면서 일종의 꼼수, 옳지 않은 방식으로 여겨졌기 때문에 가급적 피하게 되는 안티 패턴이었다. 

 

Atomic한 CSS는 모두 같은 specificity한 class로 구성되어 있으며 개발할 때에도 새롭게 CSS를 작성하지 않아도 됐기 때문에 더 이상 추가적인 CSS의 관리가 필요하지 않다는 큰 장점이 있다.

+ 무엇보다 이름을 짓지 않아도 된다. 또한 이미 만들어진 CSS는 서비스가 커지더라도 CSS의 양은 변화가 없기 때문에 대형 서비스일수록 CSS의 크기를 줄일 수 있다는 이점이 존재한다.

 

CSS Variables의 등장, 2017

Sass나 Less와 같은 PreProcessor의 등장 이유이기도 했던 CSS에 변수를 쓸 수 있는 기능이 IE11 제외 모든 브라우저에서 사용을 할 수 있게 됐다. -> 더이상 Sass를 써야할 이유가 사라졌음

 

복잡한 Selector는 CSS구조상 이제 필요가 없어졌고, CSS Variable은 이제 CSS의 기본 기능이 되었다. 

Auto prefixer 의 경우는 PostCSS가 대신할 수 있게 되었고 mixin과 같은 기능들은 CSS in JS에서 더욱 잘 지원할 수 있게 됐다. 

 

IE11의 방파제가 무너지면서 Grid Layout이나 CSS Variable과 같은 CSS의 새로운 스펙들의 사용빈도가 높아지고 있음

 

CSS in JS의 대유행, 2021

styled-component의 흥행과 react의 압도적인 점유율로 인해 CSS in JS는 새로운 강자를 찾는 중이다. 

런타임에 CSS를 생성한다는 문제점을 극복하기 위해서 Zero-Time CSS, Near Zero CSS와 같은 컨셉을 들고 나오는 중이다.

 

on-demand Atomic CSS ...2021.. ~

TailwindCSS는 미리 만들어둔 CSS만으로는 수치나 색상 입력에 한계가 있고, 이러한 부분들을 미리 설정해두는 방식으로는 한계가 있다는 지적을 받아왔다. 그래서 CSS를 미리 만들어 두는 방식이 아니라 AtomicCSS에 필요한 수치를 입력해두면 필요한 CSS를 자동으로 생성해두는 주문형(on-demand) Atomic CSS 패러다임으로 발전하고 있다.

 

 

 

all ref:

https://yozm.wishket.com/magazine/detail/1319/

역사로 알아보는 CSS가 어려워진 이유: ①웹 문서에서 웹 애플리케이션으로 | 요즘IT

https://yozm.wishket.com/magazine/detail/1326/

역사로 알아보는 CSS가 어려워진 이유: ②CSS in JS와 Atomic CSS | 요즘IT