CSS의 미래

AI 요약

브라우저 업체들이 웹 기술의 상호 운용성을 높이는 Interop 프로젝트를 진행해 왔습니다. 글은 Interop 2027에 넣을 기능을 정하는 투표를 앞두고, 작성자가 우선순위를 높게 준 CSS 제안 10가지를 살펴봅니다. CSS Subgrid는 Firefox가 2019년에 구현한 뒤 다른 브라우저 지원이 더뎠지만, Interop 2023에 포함된 후 그해 말 주요 브라우저에서 널리 쓸 수 있게 된 사례로 소개합니다.

CSS 함수와 도형

CSS 함수 제안은 @function으로 함수를 정의하고 result로 반환값을 지정합니다. 예시에서는 색과 방향을 입력받아 투명해지는 선형 그라디언트를 만들고, sin()과 cos()로 각도와 거리를 좌표로 바꿔 요소를 이동합니다. 글을 쓴 시점에는 Chromium 브라우저에서 구현됐으며, Interop 2027에 포함되면 다른 브라우저 지원도 넓어질 가능성이 있다고 봅니다.

corner-shape는 둥근 사각형의 모서리를 스퀴클이나 베벨 같은 형태로 바꿉니다. clip-path나 마스크와 달리 실제 border-box 모양을 바꾸므로 테두리, 외곽선, 그림자도 모서리를 따라갑니다. 작성자는 게임이나 SF풍 화면을 만들 때 bevel을 자주 쓴다고 설명하며, Firefox와 Safari 지원이 없는 상태에서도 점진적 향상 방식으로 적용할 수 있다고 말합니다. 별도 제안인 border-shape는 직선, 호, 베지어 곡선으로 테두리 모양을 직접 그리고, 서로 다른 모양 사이를 애니메이션으로 전환하는 기능입니다.

위치와 애니메이션

Anchor Positioning Level 2는 앵커 요소에 붙인 요소가 기본 위치 대신 대체 위치로 이동했는지 컨테이너 쿼리로 확인합니다. 툴팁이 화면 위쪽 공간 부족으로 아래로 이동했을 때 꼬리 모양도 위치에 맞춰 바꾸는 용도로 설명합니다. CSS inherit() 제안은 부모에게서 상속한 값을 가져와 calc()로 가공합니다. 예를 들어 안쪽 요소의 border-radius를 부모 값에서 4px 줄일 수 있습니다. 다만 글 작성 시점에는 브라우저 구현이 없고, Interop 2027에 포함될지도 불확실하다고 밝힙니다.

스크롤 트리거 애니메이션은 특정 지점에 도달하면 정해진 시간 동안 키프레임 애니메이션을 실행합니다. 스크롤 진행률에 맞춰 재생하는 scroll-driven animations와는 용도가 다르며, 현재는 JavaScript의 IntersectionObserver로 구현할 수 있습니다. interpolate-size와 calc-size()는 auto 같은 키워드 크기와 숫자 크기 사이의 애니메이션을 지원합니다. 대표 사례는 높이가 0인 아코디언을 height: auto로 펼치는 동작입니다. 지원하지 않는 브라우저에선 @supports로 전환 효과를 감싸라고 안내합니다.

읽기 순서와 스크롤 상태

reading-flow는 Grid나 Flexbox에서 시각적 배치 순서에 맞춰 키보드 탭 순서를 정하는 기능입니다. reading-order를 쓰면 사용자 지정 순서도 지정할 수 있습니다. 반응형 화면에서 시각적 순서와 DOM 순서가 달라져 보조 기술 이용자의 탐색 순서가 어긋나는 문제를 다룹니다. gap decorations는 Grid의 행과 열 사이에 선을 그립니다. 빈 셀에 테두리를 줄 요소가 없어도 Grid 자체에 rule, row-rule, column-rule을 지정할 수 있습니다. scroll state container queries는 sticky 요소가 고정 상태인지, 스크롤 영역이 위나 아래 끝에 닿았는지 쿼리합니다. 이를 이용해 고정 헤더의 배경이나 스크롤 안내 그라디언트를 바꾸는 예를 듭니다.

글은 LLM의 학습 데이터가 오래된 CSS에 치우칠 수 있으므로 개발자가 최신 기능을 알고 에이전트에게 활용을 지시해야 한다고 주장합니다. 소개한 기능 가운데 여러 개는 아직 모든 브라우저에서 쓸 수 없지만, 점진적 향상 방식으로 지금 적용할 수 있다고 설명합니다.

Hacker News 반응

• @FDEUp — 새로운 CSS 기능을 폭넓게 지원하는 것은 좋습니다. 기본적인 사이트 기능을 새로운 CSS 기능에 의존하게 만드는 것은 나쁩니다.
• @herpdyderp — 브라우저가 협력한다고 강조하면서 소개한 기능은 전부 Chrome 전용인 점이 조금 이상합니다. 잠재적인 미래를 미리 보여주는 글이라면 이해하겠습니다.
  • @paulhebert — 글은 브라우저들이 특정 표준을 함께 지원하도록 하는 Interop 프로그램에 관한 내용입니다. 무엇을 넣을지는 우리도 투표할 수 있습니다.
• @lioeters — CSS에 함수가 정말 필요한가요? CSS가 튜링 완전해진 뒤로 이미 그 길에 들어선 것 같기도 합니다. JavaScript와 더 잘 통합해 이런 우회를 없애면 안 되나요?
  • @afavour — JavaScript를 쓰려면 가상 머신과 스크립트 파싱 등 많은 과정이 필요합니다. 페이지 내용을 표시하기 전에 그걸 요구하면 퇴보입니다.
  • @lioeters — CSS도 기능을 계속 추가하면 많은 것을 요구하지 않나요? 선언형 언어가 기능을 계속 더하다가 어색한 문법으로 함수를 쓰게 되는 모습은 프로그래밍을 YAML로 하는 것 같습니다.
• @lopsotronic — CSS inherit()를 오래 기다렸습니다. 다만 이 기능과 CSS 함수는 꽤 큰 복잡성을 불러올 수 있다는 점도 인정합니다. Anchor Positioning은 정말 유용할 것 같고 부담도 덜해 보입니다.
• @jamienk — CSS에는 여전히 트리 셰이킹이 없습니다. 오래된 CSS 파일이 비대해지는 원인인데, 다들 포기한 것 같습니다.
  • @afavour — CSS Modules라면 가능할 것 같습니다. 일반 CSS에서는 클래스나 ID를 어디서 쓸지 알 수 없어 사실상 어렵습니다.
• @alberth — 제안된 기능은 CSS를 불필요하게 복잡하게 만들거나 JavaScript처럼 보이게 합니다. 특히 함수가 그렇습니다.
  • @mattkenefick — 함수는 CSS에 어울리지 않는다고 생각합니다. 추가된다면 실망할 것 같습니다.
• @afavour — 저는 CSS를 즐겨 쓰는 소수 중 하나입니다. CSS Modules를 쓰고 변수를 팔레트로 선언해 다크 모드에 맞춰 바꾸는 등, 몇 년 전과 사용 방식이 달라졌고 실제로 쓰기 좋습니다.
  • @paczki — 현대 CSS를 쓰는 즐거움이 큽니다. JavaScript로 작성했던 상당 부분을 CSS로 바꾸고 있습니다. 다만 새 기능을 쓰기까지 기다리는 시간이 불만입니다.
• @koolala — 글에서 빠진 반응형 iframe 표준도 기대됩니다. 웹 컴포넌트 없이 iframe을 구성 요소처럼 조합해 사이트를 만들 수 있게 될 것입니다.
• @markasoftware — 프런트엔드는 사용자를 직접 만나는 부분이라 바이브 코딩으로 만들 대상 가운데 가장 적합하지 않다고 생각합니다. 랜딩 페이지가 Claude가 30초 만에 만든 것처럼 보이면 사용자는 제품의 나머지도 그렇게 만들었다고 생각할 수 있습니다.

원문: Josh W Comeau / 번역·요약: Trawling