모던 HTML/CSS의 덜 알려진 기능들

• 최근 웹사이트 성능 저하의 주요 원인은 과도한 JavaScript 사용과 추적 스크립트이며, 많은 경우 HTML/CSS만으로도 충분히 대체 가능함
• CSS 네스팅, 상대 색상, 새로운 뷰포트 단위(lvh, svh, dvh) 등 최근 추가된 기능들은 과거 JS나 전처리기에 의존했던 작업을 간단히 해결할 수 있게 함
• CSS는 단순한 스타일 도구가 아니라 애니메이션, 입력 검증, 다크 모드 테마, 아코디언 메뉴까지 구현 가능한 강력한 언어임
• 성능 측면에서도 CSS는 GPU 가속과 별도 스레드에서 동작해 애니메이션과 전환 효과에서 JS보다 매끄럽고 효율적임
• 글쓴이는 CSS를 단순한 실용 도구를 넘어 표현과 예술의 수단으로 강조하며, 웹 개발자들이 현대 CSS의 잠재력을 더 활용하길 권장함

---

서론: 웹의 복잡성, 그리고 새로운 시도

• 많은 웹사이트가 JavaScript 프레임워크의 과도한 사용으로 성능 저하와 복잡성을 겪음
  • React 앱은 로딩에 몇 초가 걸리고, NextJS는 하이드레이션 오류를 발생시킴
  • node_modules 폴더는 수 기가바이트의 용량을 차지함
• JavaScript 없이도 HTML과 CSS만으로 강력한 기능을 구현할 수 있음
  • 전자상거래 사이트의 복잡한 장바구니나 대시보드 외에는 JavaScript가 필수적이지 않을 수 있음
• 이 글은 CSS의 최신 기능을 소개하며, 개발자들이 JavaScript에만 의존하지 않고도 다양한 가능성을 탐구하도록 유도함

CSS에 대한 오해와 인식

CSS는 정말 어렵고 불편한가?

• CSS에 대한 부정적 인식은 기본 학습 부족에서 비롯됨
  • 많은 개발자가 CSS 기초를 건너뛰고 JavaScript나 TypeScript에 집중함
  • CSS는 단순한 스타일링 도구가 아닌, 도메인 특화 언어로 강력한 기능 제공
• CSS는 플렉스박스(flexbox) 와 같은 도구로 복잡한 레이아웃을 쉽게 구현 가능
  • 예: display: flex와 justify-content: center로 div 중앙 정렬이 간단함
  • 브라우저 개발자 도구는 플렉스박스 속성을 시각적으로 조정할 수 있는 위젯 제공
• 한 쪽(예: JS)만 깊게 파고 CSS를 소홀히 하면 당연히 부담이 커짐

CSS 작성의 고통, 그리고 변화

• 예전에는 CSS가 썩 편하지 않았기에 Sass, Tailwind와 같은 도구가 등장함
  • 예: .post > .buttons .like:hover처럼 긴 선택자 체인을 관리해야 함
• 최근에는 품질 개선 기능(네스팅 등)이 추가되어 기본 CSS만으로도 쾌적하게 개발 가능해짐
  • CSS 중첩(nesting) 은 관련 스타일을 한 곳에 모아 가독성을 높임
    • 예: .post { & > .buttons { .like { &:hover { ... } } } }
    • 부모-자식 관계가 명확해져 짧고 간단한 클래스명 사용 가능
• 상대 색상(relative colors) 은 색상 조정을 쉽게 함
  • hsl(from #123456 h s calc(l + 10))로 밝기 조정 가능
  • color-mix()로 두 색상을 혼합하여 동적 색상 생성
• 미디어 쿼리 범위 문법은 (width <= 768px)처럼 직관적인 조건 설정 가능
• lh 단위는 줄 높이에 맞춘 스타일링을 지원
• scrollbar-gutter 속성은 스크롤바로 인한 레이아웃 이동 문제를 해결
• Baseline은 주요 브라우저에서 기능 호환성을 보장
  • 신규 기능(newly available) 은 최신 브라우저에서 작동
  • 널리 지원(widely available) 은 2.5년 전 브라우저까지 지원
  • 예: CSS 중첩은 2023년 12월부터 모든 브라우저에서 지원됨

왜 CSS/HTML만으로 개발하는가?

• 일부 사용자는 JavaScript를 기본적으로 비활성화함(보안, 개인정보 보호 등 이유)
• 순수 CSS/HTML만으로 웹사이트를 제공하면, 이런 사용자도 사이트 이용 가능성 높음
• 개발 및 사용자 입장에서 CSS/HTML만 사용할 때 속도, 접근성, CPU/배터리 사용 면에서의 이점이 큼
  • CSS 애니메이션은 컴포지터 스레드에서 실행되어 CPU 부담 감소
  • JavaScript는 이벤트 루프를 통해 실행되며, 약간의 지연 발생 가능
• 접근성과 사용 편의성 향상
  • 버튼 호버 효과, 토스트 애니메이션, 입력 검증 등은 CSS로 간단히 구현 가능

CSS의 실질적 예시와 주요 기능들

@starting-style로 자연스러운 시작 애니메이션 구현

• 이전에는 요소 등장 애니메이션 구현에 keyframes, JS 트리거 등 복잡한 구조 필요
• @starting-style 도입으로 시작 상태 지정이 간단해짐. 요소의 초기 상태 애니메이션(예: 페이드인)을 쉽게 구현
  • transition: opacity 1s; @starting-style { opacity: 0; }로 설정
  • 별도의 @keyframes나 JavaScript 없이도 동작
• 단순히 transition과 함께 초기 상태만 명시하면 애니메이션 자연 적용됨
  • 예: 토스트 메시지의 투명도와 위치 전환을 부드럽게 처리

다크/라이트 모드 손쉬운 테마 설정

• color-scheme: light dark는 사용자 선호에 따라 테마 자동 전환
• light-dark(#000, #FFF) 함수는 밝은/어두운 모드에 맞는 색상 지정
• 라디오 버튼과 :has 선택자로 사용자 테마 선택 지원
  • JavaScript 없이 CSS만으로 테마 전환 가능
  • JavaScript로 테마 저장/로드를 선택적으로 추가 가능

라디오/체크박스와 :has, :checked 등으로 커스텀 UI 생성

• 탭, 아코디언, 토글 등 복잡한 인터랙션도 JavaScript 없이 구현 가능
• 라디오 버튼은 :checked와 :has로 커스텀 스타일링
  • 예: label:has(input:checked)로 선택된 버튼 스타일 지정
  • opacity: 0으로 입력 요소를 숨기되, 화면 판독기 접근성 유지
• details 요소는 FAQ와 같은 아코디언 메뉴 구현에 적합
  • name 속성으로 단일 열림 상태 제어 가능
  • [open] 상태에 따라 애니메이션 추가 가능

입력 검증과 상태 반영

• pattern, required 등 HTML 속성과 CSS 가상 클래스(:valid, :invalid, :user-valid 등) 조합으로 실시간 검증 및 시각적 피드백 제공
• 입력 필드에 대한 outline/border 스타일 변경 등 사용자 경험 향상
• HTML의 pattern 속성으로 입력 필드 유효성 검증
  • 예: \w{3,16}으로 3~16자의 알파벳/숫자/밑줄 허용
• CSS의 :valid와 :invalid로 유효성에 따라 스타일링
  • :user-valid와 :user-invalid는 사용자가 입력한 후에만 스타일 적용
• :has 선택자로 입력 상태에 따라 다른 요소 스타일링 가능
• 일부 경우(예: 복잡한 입력 조건)는 JS가 필요하지만, 대부분은 CSS/HTML로 충분

뷰포트 단위의 올바른 사용법

• vw/vh 단위는 모바일에서 주소(네비게이션) 바 등장/숨김에 따라 정확성 이슈 발생
• lvh/svh/dvh(largest/smallest/dynamic viewport height) 등 신형 뷰포트 단위 사용 권장
  • lvh: 전체 화면용 (예: 전체 배경)
  • svh: 항상 화면에 보여야 하는 버튼, 링크 등에 활용
  • dvh: 스크롤 등 변화에 따라 유동적으로 크기 할당
• 키보드 오버레이는 interactive-widget 속성이나 VirtualKeyboard API로 처리
  • <meta name="viewport" content="width=device-width, interactive-widget=resizes-content">
  • Chromium 기반 브라우저에서는 navigator.virtualKeyboard.overlaysContent = true

CSS 위시리스트(아쉽거나 바라는 기능)

• 재사용 가능한 블록: 클래스 내 다른 클래스 적용 (예: @apply border)
• 결합된 미디어 쿼리 선택자: @media와 클래스 선택자 결합
• nth-child 변수: span { --nth: nth-child(); }로 동적 스타일링
• nth-letter 선택자: 특정 글자 스타일링 (예: p::nth-letter(2))
• 단위 제거: calc(100vw / 1px)로 단위 없는 값 생성
• image() 함수: 대체 색상과 이미지 조각 지원
• body 내 style 태그: 공식 표준 지원으로 FOUC 문제 완화

마무리: CSS, 그리고 웹의 예술성

• CSS는 단순한 도구가 아닌, 창의적 표현 수단
• AI 도구나 빌드 체인(린터, 최소화 도구)은 창의성을 제한할 수 있음
• CSS는 성능, 접근성, 예술적 표현을 동시에 충족
• 이 글은 약 49kB의 JavaScript 없는 HTML/CSS로 작성됨
  • 모든 인터랙티브 위젯과 시각 요소는 수작업으로 구현
  • 예: CSS 클릭 게임은 CSS의 프로그래밍 언어적 가능성 증명

[duqduqduq]

풀스택이었는데 아무래도 커리어가 위로 올라갈 수록 FE를 할 기회가 없어지니 한 10년 간 손 안데다가 최근 어느 기업 강의할 일이 있어서 간략히 소개나 할 겸 봤는데 정말 놀랍게 변했더군요. scss까지 겸하면 더 꿀이던데요. 근데 이 css의 영역은 참 묘합니다. 배우는 건 쉬운데 인정받을 만큼 잘 쓰는 건 개인의 심미적 센스와 창의력에 의해 갈린다고 생각합니다. 사용성과 디자인을 더 중요하게 보는 웹 시대에 퍼블리셔의 가치가 더 높게 평가되비 못하는 거 같아 안타깝습니다.

[ahwjdekf]

이번에 웹개발 기술 맛보기 취미활동으로 기초1도 없이 맨땅에 헤딩식으로 nextjs, authjs, tailwind, shadcn 이용해서 기본 게시판 만들어봤는데 ... 최대 학습 난이도는 css 였네요.

[GN⁺]

Hacker News 의견

• 나는 이번에 CSS에 추가된 네스팅 기능이 고마움, 하지만 전체적으로 보면 CSS는 정말 이상하고, 개인적으로는 형편없는 언어라고 생각함, 내가 제대로 쓰지 못하는 탓일 수도 있겠지만, 너무 복잡하고 지저분해서 마치 알 수 없는 룬 문자를 여기저기 옮겨 보는 느낌임, 스타일링과 레이아웃 시스템이 섞여 있는데, 상속과 포함 관계가 달라서 더 헷갈림, 스타일링과 레이아웃을 합친 것은 오류였다고 생각함, 이미 근본적으로 망가진 시스템에 기능만 추가하는 것이 해결책이 될 수 없다고 느낌

  • 나도 지난 10년간 CSS로 밥 벌어먹었지만, CSS는 언어 자체가 설계된 것이 아니라 그때그때 확장되어온 느낌임, 기존 속성 위에 새로운 모듈만 붙여놓아서 서로 충돌하거나 살짝 달라지는 바람에 디버깅이 어려워짐, 박스 모델과 flex 레이아웃이 다르게 동작하는 것, gap 속성이 flex와 grid에서 다르게 작동하는 것을 예로 들 수 있음 (링크), 레이아웃을 한번 만들면 실질적으로 거의 고정됨, 복잡한 네이티브 또는 JS 기반 캡슐화 없이는 유연하게 바꾸기 힘듦, 그러다 보면 예기치 않게 폰트 두께가 변하거나 모바일 메뉴가 데스크탑에도 뜨는 문제가 생김
  • 나는 동의하지 않음, CSS에 대해 부정적인 의견을 주로 보는 이유는, 사람들이 제대로 배우거나 특히 cascade(계단식)를 이해하지 못했기 때문이라고 생각함, 예전에 CSS 스펙을 깊이 파고든 적이 있는데, 마크업의 의미와 스타일을 분리한다는 목적에는 꽤 잘 설계된 언어라고 생각하게 되었음
  • 스타일링과 레이아웃을 분리하는 것은 불가능하다고 생각함, UI 개발을 해본 사람이라면 두 요소가 본질적으로 엮여 있고 상호 의존적이라는 것을 느낌, 예를 들어 텍스트 길이나 사이즈, 오버플로우, margin, padding 등이 서로 영향을 줌, 어떤 요소의 보더나 스페이싱을 바꾸면 내부 콘텐츠의 공간도 바뀜, 둘을 완전히 분리할 수 없음
  • CSS의 진짜 문제는 Cascading(계단식)이라고 생각함, 그리고 대부분의 현대 프론트엔드 개발이 오히려 이 cascade를 막기 위해 돌아감, UI 컴포넌트화가 그 예시임, 레이아웃은 또 별개의 문제인데, 호환성 때문에 더 복잡해짐, 만약 모든 레이아웃이 기본적으로 flexbox나 grid로만 작동하고 inline과 non-inline을 한 컨테이너에 섞지 않는다면 훨씬 나을 것임, React Native가 딱 그런 방식으로 동작함, React Native에서 스타일은 cascade되지 않아서 관리가 훨씬 수월함
  • 이 모든 말이 맞음, 하지만 현재 우리가 가진 건 이것임, 더 개념적으로 일관된 모델을 만들고 CSS로 트랜스파일할 수 있지 않을까라는 생각을 해봤음, container queries나 calc 등으로 더 정돈된 레이아웃 시스템을 수학적으로 구현할 수도 있을 것 같음, 현재 프리프로세서 언어들은 CSS에 이미 미완성인 개념 위에 또 미완성된 기능만 붙여넣는 셈이라 오히려 더 혼란스러움

• CSS의 최악은, 많은 사람들이 제대로 배우지도 않고 하루 정도 강제로 써봤다가 강한 의견을 내는 거라고 생각함

  • 나도 그런 '하루'가 있었음, 팟캐스트 앱을 만들며 떠다니는 푸터를 만들려고 했는데, (1) 항상 아래에 위치하고 (2) 항상 보이고 (3) 콘텐츠를 가리지 않으면서 (4) 별도 해킹 없이 구현하고 싶었음, 근데 이게 CSS로 불가능하다는 걸 알게 됨, 정말 좋은 시스템임
  • 나는 20년 전에 CSS를 배웠음, 내 결론은 Cascading 때문에 CSS를 Crappy Style Sheets로 이름 바꿔야 한다는 생각임, 여러 사람이 협업하면 "여기서 이거 바꾸면 저쪽에서 엉뚱한 게 깨지는" 현상이 기본임, 규칙을 오버라이드하는 복잡한 룰이 특징인데, 베이스가 그거면 안 좋음, 복잡하게 타겟팅하는 방법이 점점 더 복잡해져서 결국 .foo > .bar:nth-child(2n) ~ .baz 같은 코드가 됨, 그렇게 하면 또 동료의 코드가 깨짐, 간단한 레이아웃 하나에도 머리가 아픔, 그나마 최근엔 많이 나아졌지만, 애초에 이런 cascade 중심 구조가 문제라고 생각함, 문법 등 다른 비판은 사소함, 실용적이고 쉽게 쓸 수 있으면 문법은 허용 가능한데 CSS는 아니었음, 웹 레이아웃 만드는 게 직업이 되면 안 된다고 생각함
  • "많은 사람들이 CSS를 배우지 않고 쓴다"는 말에 대해, 모든 20가지 이상의 스펙을 다 배워야만 쓸 자격이 있냐는 건 너무한 접근임, 사람들이 툴을 쓰면서 문제를 겪으면 툴에 문제가 있는지 봐야지, 사람을 탓해서는 안 됨, 톱을 조심해서 쓰라고 강요하는 대신에 안전장치를 다는 게 맞음

• 나는 이 글에서 "일부 사용자는 JavaScript를 원하지 않는다"는 근거는 크게 와닿지 않음, 나도 Arch 유저고 각종 스크립팅과 크롤링에 열성적인 사람이지만, "NoScript" 환경에 집중하는 게 딱히 중요하게 느껴지지 않음, 이는 아주 소수 취향이라 대체로 무시해도 된다는 생각임, "10%가 IE6 쓴다"던 시대와 비슷한 느낌임, 그래도 CSS가 더 우수하다는 수많은 다른 이유가 있다고 봄, 어쨌든 이건 주요 쟁점은 아니지만, 흐름 자체가 이런 느낌이라는 의견임

  • 나는 CSS 선언형으로 몇 줄에 할 수 있는 일을, JS 명령형으로 하면 수십 줄이 되고 더 많은 이상 동작, 프레임워크 호환성 문제, 인터랙티브 시간 지연이 발생함, NoScript 환경은 덤일 뿐임, 사실 마음속으로는 DSSSL이 그리움
  • 본문에서 JavaScript를 꺼리는 사용자는 곁다리로 언급되지만, 대부분의 글은 CSS 기능 자체를 보여주는 데 초점을 둠, 동기 중에 성능도 있지만, CSS 기술을 소개하는 게 훨씬 생산적인 접근이라고 봄
  • 나는 NoScript 환경으로 평소에 인터넷을 쓰고 있음, JS가 필요한 사이트만 예외로 허용함, 성능·배터리·보안에도 꽤 좋음, 일주일 이상 NoScript로 살아본 적이 있나? 나도 써보기 전엔 마찬가지 의견이었음, 참고로 나는 이 블로그 포스트의 저자임
  • 나는 NoScript 사용자층이 그리 유의미하거나 타깃이 될 필요는 없다고 생각함, 하지만 글쓴이가 아니라 짧게 언급한 부분에서 말하진 않았지만, 코드를 적게, 그리고 브라우저 플랫폼에 더 많이 기대는 것이 엄청난 가치를 준다고 생각함, 브라우저로 최대한 하게 두는 것이 정말 큰 효율임
  • "일부 사용자는 JavaScript를 원하지 않는다"는 주장에 거의 대부분의 사용자는 원하지 않는다고 생각함

• 네스팅이 이제 공식 표준이 되었는지 몰랐음, 최근까지도 제안 단계였다고 생각함, CSS는 이상한 점도 많지만, 자바스크립트처럼 점점 더 괜찮은 언어로 발전하는 흐름이 느껴짐, Flexbox, :has 셀렉터, 네스팅 덕분에 예전부터 겪었던 여러 고통 지점들이 많이 해소됨

• 위시리스트에 있던 CSS 기능 두 가지가 이미 스펙에 존재함

  • n-th child 변수는 sibling-index()와 sibling-count()로 구현 가능 (MDN 설명)
  • 재사용 가능한 블록은 @function과 @mixin 초안 스펙에 있음 (스펙 초안, CSS Tricks 설명)
  • 둘 다 이미 Chrome에 구현되어 활용 가능함

• CSS 문법은 형편없다고 생각함, 나는 10~15개 언어를 다루지만 CSS가 가장 읽고 이해하기 어려움, x86 어셈블리보다도 더 난해함, CSS는 렌더러를 위한 미리 토큰화된 입력이지만, 토큰도 아니고 사람이 쓰기엔 이상함, RFC의 ASN.1처럼 "이렇게 하면 안 된다"는 반면교사로 써야 할 것 같음

  • 그 언어들 중에 선언형 혹은 도메인 특화 언어가 몇이나 있는지 궁금함, CSS와 어셈블리를 비교하는 건 적합하지 않음, CSS는 선언형이고 어셈블리는 그 반대임, 대다수 프론트엔드 개발자도 명령형 언어에서 CSS로 전환할 때 처음엔 힘들어하지만 익숙해지면 나아짐, CSS 용어와 개념은 대부분 컴퓨터가 아니라 디자인/출판 업계에 뿌리를 두고 있음, 많은 개발자가 CSS를 명시적 명령 집합처럼 접근하는데, CSS는 서로 영향을 주는 특이한 방식임, 한 속성이 전체 레이아웃 알고리즘을 바꾸기도 함 (CSS 레이아웃 알고리즘 입문)
  • "15개 언어를 다룬다" 하더라도 CSS는 아는 데 정말 어렵다고 생각함, 프로그래밍 언어는 많이 써봐도 정말 '안다'고 할 수 있는 수준에 이르려면 엄청난 실전 경험이 필요함 (설명적 깊이의 착각 위키), CSS를 이해하는 가장 좋은 방법은 렌더링 결과를 직접 보고 평가하는 것임, 나는 수십 년간 그렇게 써옴
  • 나도 CSS가 HTML/CSS/JS 3종 세트 중에 제일 별로라고 느낌
  • "CSS가 미리 토큰화된 입력"이라는 게 무슨 의미인지 좀 더 구체적으로 듣고 싶음
  • "font-size: 12px" 같은 코드는 충분히 사람이 읽기 어렵지 않은데 왜 힘들다고 느끼는지 이해가 안 됨, 내게는 정말 단순함

• 라디오 탭 예제가 접근성 측면에서 괜찮은지 궁금함, WAI-ARIA 기준에 따라 aria-selected, tabindex, aria-controls 속성은 탭이 바뀔 때 JS로 업데이트해야 하는 걸로 아는데 확실하지 않음, 접근성은 종종 뒷전이 됨, HTML/CSS만 쓰면 알아서 접근성이 보장된다고 착각하기도 함, 접근법을 선택할 때 한 번 더 고려해야 할 점임

  • 내가 알기로는 이 라디오 탭은 키보드 네비게이션, 스크린리더와도 잘 작동하고, WAI-ARIA 예제의 탭-컨텐츠 이동 플로우를 따름 (WAI-ARIA 예제), 접근성에 대한 배경지식은 없지만 최대한 확인하고 있음, 여러 접근성 도구로 테스트도 직접 해봄
  • 원문에서 저자는 접근성 관련 내용을 여러 번 언급하며, 심지어 브라우저 버그도 우회해서 처리하려고 노력했음 (관련 각주)
  • 이 블로그 글 자체의 접근성(특히 대비)이 너무 안 좋아서, 내가 장애인 단체에서 웹 개발자로 일하면서 볼 때 참고 자료로 삼긴 어렵다고 생각함

• JS 없이도 이런 인터랙티브 효과 구현이 가능함 (예시 페이지)

  • • 떨어지는 종이조각 애니메이션
  • • 닫기 기능이 있는 알림 창
  • • 알림을 닫으면 종이조각도 함께 사라짐
  • • 탭 동작도 됨(하지만 해당 예시에서는 서버 리로드가 필요)
  • • JS를 추가하면 애니메이션이 더 부드럽고 풍부해짐

• 10년차 웹 개발자로서, 이런 글이 우리의 확신을 뒤흔들 필요가 있다고 느낌, 제목은 별로여서 읽을 뻔했다는 생각이 듦, 참고로 CSS만으로 맵 렌더링은 안 됨

  • CSS+SVG를 활용하면 맵 렌더링 가능함, 물론 내비게이션 같은 부가 기능은 따로 구현 필요함

• Vega라는 이름 때문에 편견이 있을 수도 있지만, 이 사이트 정말 마음에 듦, 전체적인 디자인도 좋고, 이 페이지의 내용도 정말 훌륭함, 앞으로 웹 개발하는 사람들에게 꼭 링크를 공유할 예정임, arrupted도 아주 좋아하는데, 예전에 멋진 결과물을 만들기도 했음, 그래서 이번에 익숙한 도메인을 메인에서 보게 되어 반가움