CSS, 과거와 현재

프롤로그

• HTML의 탄생, 1991

  • 최초의 HTML은 말 그대로 마크업 기능만 가진 순수한 문서의 형태.
  • HTML이 보편화 되면서, 자연스럽게 문서를 꾸미고자 하는 요구가 생겨남.

• inline-style

  • HTML에 style이 추가되었고, 태그에 직접 style을 지정하는 Inline-style 방식으로 문서 커스텀이 가능해짐.
    • HTML이 컨텐츠와 서식을 모두 포함하는 구조가 됨.(HTML = 컨텐츠 + 서식)
  • 하지만, Inline-style 방식의 치명적인 단점이 대두 되면서 새로운 방식을 찾기 시작 → CSS가 탄생
    • 단점 1. 유지 보수의 어려움.
      • ex. 중복 서식이 너무 많아서 공통 영역 수정시 모두 바꿔야함.
    • 단점 2. 코드가 비대해지면서 가독성이 현저히 떨어짐.

      <span
        style="font-size: 12px; font-weight: 400; color: red; 
      margin-left: 30px; display: inline-block;"
      >
        타이틀
      </span>
      

      • Best Practice.
        1. inline-style 사용 지양!

CSS의 발전 흐름

• CSS1, 1996 : inline-style의 중복 제거

  • 1994 첫 등장 당시엔 css는 표준은 아니었음.

  • inline-style의 중복 제거.

  • 초기의 css는 태그를 만드는 형식. (현재의 styled-component와 유사. but CSS-in-JS가 아님)

    <!-- CSS를 통해 중복된 서식을 하나의 Rule로 만들어 -->
    <style>
      strong {
        color: red;
        text-decoration: underline;
      }
    </style>
    
    <!-- 태그로 활용 -->
    <strong>This is Red Underline Title</strong>
    

  • 관심사 분리가 가능해짐.

    • 기존의 HTML = 컨텐츠 + 서식의 구조에서, 문서와 서식이 분리가 됨.
      • Best Practice.
        1. inline-style 사용 지양!
        2. 컨텐츠, 서식을 분리해서 관리 할 것.

  • 단점. 복잡한 selector. 세분화 필요성이 대두됨.

    // CSS 아님. style 태그임. // page 1 #nav > li a {color: red} #nav > li a.selected {color: blue}
    // blue가 yellow로 바뀌면? 머리가 아파짐. strong{color: blue}
    

• SASS, 2006 : Selector의 세분화 & 변수화

  • selector의 세분화가 가능해짐.
  • 속성 값의 변수화가 가능해져서 관리에 용이해짐.

    // CSS 아님. style 태그임. #nav > li a { color: red &.selected {color: $primary} } strong{color:
    $primary}
    

• class의 대중화 : Ajax의 등장. HTML, CSS의 병렬 작업이 가능해짐

  • Ajax가 도입된 이후 개발업을 시작해서 이전의 작업 방식은 잘 모르지만, 이때 HTML의 편집권이 백엔드에서 퍼블리싱 단계로 넘어왔다고 함.
    • Ajax의 등장으로 UI 활용성이 크게 확장됨.
    • 그래서 퍼블리싱 직무가 확장되면서 프론트엔드 분야가 됨.
  • 병렬 작업이 가능해져서 복잡한 selector 보다 잘 네이밍된 class를 사용해서 CSS 작업은 간단히 하고, 차라리 HTML을 복잡하게 사용하자 가 트렌드가됨.
  • 즉, class 네이밍 컨벤션에 대한 많의 논의가 진행됨.
    • 이때부터 style 태그 사용이 아닌, CSS 사용이 주류가됨.

• Semantic class vs General Class

  • 대표적으로 논의가된 두 방식.

    • Semantic class : 의미론적 네이밍

    • General class : 시각적인 네이밍.

      // semantic class
      .error {
        color: red;
      }
      
      // general class
      .red {
        color: red;
      }
      

  • Semantic Win!

    • Best Practice.
      1. inline-style 사용 지양!
      2. 컨텐츠, 서식을 분리해서 관리 할 것.
      3. class 작성시 semantic class 로 작성 할 것.

• 웹 문서 → 웹 어플리케이션 : 웹 역할 확장

  • 이때까지 웹은 간단한 인터렉션(클릭, 데이터로드)은 있었지만, 대부분 웹 문서를 보여주는 것이 목적.
  • 웹 어플리케이션 기능, 디바이스, 브라우저 등의 환경의 다양화로 인해 많은 프레임워크가 생겨남.
  • 기존의 CSS에 많은 문제가 발생.
    • 문제점 1. 디바이스, 브라우저 환경에 따라 HTML을 복붙 했는데 CSS가 제대로 적용이 안됨.
    • 문제점 2. CSS를 수정했더니 엉뚱한 곳이 틀어짐.
    • 문제점 3. 에라 모르겠다 !important 쓰자.
    • 문제점 4. 미사용 코드를 찾는게 어려움.
    • 문제점 5. 위의 문제점 때문에 CSS를 도무지 재사용 할 수가 없다!
  • 위 문제의 결정적 원인 두가지
    • 원인 1. class는 프로젝트 전체로 선언되는 글로벌 스코프.
      • 이때까지만 해도 자동으로 key값을 생성해주는 lib or framework가 없었음.
    • 원인 2. CSS 고유의 우선 순위를 가짐.
      • 전역으로 class가 작성이 되다보니 도무지 우선순위를 찾을 수가 없다

• 대 CSS 방법론의 시대, 2013

  • 위 두 원인을 해결하기 위해 다양한 방식의 CSS 방법론이 대두됨.

  • CSS 방법론.

    • 방법론 1. BEM(Blcok, Element, Modifier), 2013

      • —, __를 이용해서 네이밍하는 방식.

        // header는 Block, naviagtion은 Element, navi-text는 Modifier
        .header__navigation--navi-text {
          color: red;
        }
        

      • 상기 방식처럼 네이밍을 요로쿰 조로쿰 하자 라는 주장이 많았지만, 근본적이 해결책이 되진 못함.
      • 길어지고 복잡해지는 naming

    • 방법론 2. CSS Module, 2015

      • 현재까지도 많이 사용되는 개념.

      • class 말미에 유일 구문을 자동 생성하고 css에 hash를 추가해서 css의 글로벌 스코프를 예방.

        // 프로젝트에서 선언한 클래스
        .header {
        	color: red;
        }
        
        // dom에서 생성된 클래스
        .header_hfoewi {
        	color: red:
        }
        

      • 단, 이때까지도 style은 CSS로 작업.

    • 방법론 3. CSS-in-JS : JS에서 다 해버리자!

      • React가 대세가 되면서 JS에서 다 해버리자는 욕구가 커짐.
        • 초기의 React에서는 당시의 style 방식의 작업이 번거로웠다고함.
      • Styled Component, 2016가 출시되며 현재까지 대세로 자리잡음.

중간 정리

• 현재까지 CSS 발전 방향성

  1. 복잡한 Selector → 간단한 Selector → No Selector.
  2. Global Scope → Local Scope.
  3. HTML과 CSS의 분리 → 컴포넌트로 결합.

• Best Practice.

  1. inline-style 사용 지양!
  2. 컨텐츠, 서식을 분리해서 관리 할 것.
  3. class 작성시 semantic class 로 작성 할 것.

대세에 반하는 이들의 등장

• Atomic CSS 방법론
  • 현재까지 CSS 발전 방향성
    1. 복잡한 Selector → 간단한 Selector → No Selector.
    2. Global Scope → Local Scope.
    3. HTML과 CSS의 분리 → 컴포넌트로 결합.
  • Best Practice. →진짜 최선이야?
    1. inline-style 사용 지양!
       1. inline-style이 정말 안좋은 건가? 어차피 컴포넌트 단위로 작업하는데?
    2. 컨텐츠, 서식을 분리해서 관리 할 것.
       1. JS로 몽땅 작업하면서 부터 콘텐츠와 서식의 관심사 분리, 덜 효율적으로 변하지 않았나?
    3. class 작성시 semantic class 로 작성 할 것.
       1. inline-style 쓰고, 관심사 분리 안되면 굳이 시멘틱 고집할 필요는 없지 않아?
  • 글로벌 스코프, 중복방지 이런거 프레임워크가 다 해준대! .bold, .hidden 이런 general class 방식을 모두 선언해놓고 레고처럼 조립해서 쓰자!

    .pt-3 .pt-0 self-start flex-wrap mb-1
    

  • 장점.
    • 의미 기반이 아니라서 클래스 명이 변경될 이유가 없음.
      • 프로그래머가 가장 힘들어하는 일? 이름짓기(49%) 해결.
      • 의미론적 이름짓기의 한계. 다른 프로젝트에선 동일한 기능의 컴포넌트 일지라도 클래스명이 다를 수 있음.
        • 같은 디자인이지만 A 프로젝트에선 주문 목록, B 프로젝트에선 사람 목록 일 경우 의미론적 이름짓기로는 완벽 호환되게 이름 짓는건 어려울 수 있음.
      • XX-title, YY-title, ZZ-title title만 수십개. 내가 잘 쓰고 있나?
    • 획일화된 디자인을 적용하기 쉬움.(디자인 시스템에 용이)
    • 생산성 향상. 즉, 페이지를 마구마구 찍어낼 수 있음.
    • 타 직무 팀원과의 협업에서 컨벤션을 맞추기 위한 노력이 줄어듦.
  • 대표적인 Atomic css lib : tailwind css
• Atomic CSS 이 대세가 될 수 없었던 이유 (주관적)
  • Best Practice에 반하는 올바르지 않은 방법이라는 인식.
    • 현재까지 개발환경을 생각하면 이 말이 맞음.
    • 하지만 지금은 개발 방식이 컴포넌트 단위가(angular, vue 까지도) 대세가 되면서 Atomic 방식이 좋을수도?
  • 지금까지는 서비스 보다는 솔루션이 우선이었던 업계 분위기.
    • 즉 디자인보다는 기능이 우선시 되었음.
    • 하지만 지금은 디자인이 상당히 중요한 위치로 올라서며 하나의 프로젝트 내에서도 다양한 디자인 요소들이 쓰이게 됨.
  • 리엑트에선 styled-component가 더 쓰기 편하다.
    • 하지만 다른 프로젝트에선 아닐수도? 실제로 CSS 2023 트렌드에선 tail wind가 1위이다.
• Atomic CSS의 미래
  • 여전히 남음 문제점.
    • css 속성을 하나하나 다 문서 찾아가며 언제 일하냐?
  • 많은 곳에서 atiomic css를 사용해 피그마 플러그인으로 html, css를 추출하는 작업이 진행중.
    • 퍼블리싱 작업을 프론트엔드가 하지 않게 되는 시대의 가능성 열림. 카카오테크 : https://tech.kakao.com/2022/05/24/on-demand-atomic-css-library-2/
  • React 18 서버 컴포넌트의 등장으로 클라이언트 사이드에서 수행되는 css-in-js의 트랜드가 어떤 방향으로 이동할지 눈여겨볼 필요가 있음.

ref

• state of css
• 카카오 기술 블로그
• 카카오 기술 블로그2